In T14731#284093, @alvinhochun wrote:

From a quick look, I see an issue with the handling of Chinese -- the old site has historically used the language code zh for Simplified Chinese, however the code is zh_CN in KDE's i18n system, which seems to result in both zh and zh-cn being available on the language dropdown. Personally I would prefer changing the new site to canonically use zh-cn for Simplified Chinese (though you should weigh @tysontan's opinion over mine). If we do this we probably need redirects to point old links from /zh/ to /zh-cn/.

There is a lot of content that needs to be translated still in the i18n folder before it is finished. I need to turn the text into translation strings and put into the i18n folder files. @kamathraghavendra and probably some other people want to revise some of the text we have. There is a krita artist discussion on it a bit that is started.. I didn't want to make translators do that if we are going to be changing it.

https://krita-artists.org/t/need-help-in-writing-polishing-and-editing-content-of-new-krita-org-website/52003/5

From a quick look, I see an issue with the handling of Chinese -- the old site has historically used the language code zh for Simplified Chinese, however the code is zh_CN in KDE's i18n system, which seems to result in both zh and zh-cn being available on the language dropdown. Personally I would prefer changing the new site to canonically use zh-cn for Simplified Chinese (though you should weigh @tysontan's opinion over mine). If we do this we probably need redirects to point old links from /zh/ to /zh-cn/.

@phunh - If you think these tools or modules can be helpful, we can add it back in and see how it goes. I mostly would ask that you would update the readme with the new dependency so people will know how to get the build working. I like to say what it is, and where to get it.

@scottpetrovic ok that's fair point. I just want to make use of components in kde-hugo that we have implemented and improved over time, so we don't need to do again for this website, but nothing will break without it.

@alvinhochun - It doesn't appear that Hugo can make the URL look exactly how the WordPress one does it. Based off this article (https://discourse.gohugo.io/t/how-do-you-render-an-rss-feed-on-folder-route/40705/5), it sounds like we are going to have to create some type of redirect to go to the Hugo location.

@phunh - I just removed the "strings" portion for the translations, so we should be good there. Good catch.

Some points with Krita integration:

@scottpetrovic if strings are gonna be updated during that discussion, then I'd suggest we remove "strings" from this line.

@tysontan - I just added the extra script commands to do that last generation. I was originally waiting a bit for that PO folder to be created before I added that step. There are a lot of languages that show up now on the dev site after I added that. I had to add a scrollbar so the languages didn't go off the page.

As noted by @phunh the necessary steps to make the website properly multi-language haven't been completed yet.

I have 100% translated the PO files for dev.krita.org to Simplified Chinese, but it doesn't seem the website is using them. Is the translation not working at this moment?

To make i18n work, we need to:

• Tell Scripty which branch it should work with, by doing something similar to this;
• Add a Messages.sh file (like this) to tell Scripty how to extract strings;
• Add commands to our custom_generation.py script to do the generation of files in other languages, like lines 3, 5, and 6 in this file (line 4 is not required, but might be used to always get the latest hugo-i18n).

The last step should only be done after a po folder has been created in the repo (by Scripty), otherwise the generation will fail because it hasn't yet handled the case when the folder does not exist. Also, the generation step is done at each build, so even though updates to other languages might appear on the website, you won't see those updates in the repo.

For a progress update

1. Website repository has moved to a websites project in invent: https://invent.kde.org/websites/krita-org
2. A Jenkins build pipeline has been set up which runs every commit on the main branch: https://binary-factory.kde.org/job/Website_dev-krita-org/
3. The build runs and publishes the changes to https://dev.krita.org/

I would suggest as a starting point that we move Scott's repository to websites/dev-krita-org and then go from there to get a Binary Factory job in place.

@scottpetrovic before the build process, the key can be assigned to some environment variable as Ben suggested, please work with him on this. During the build, when your script runs, we make it read that environment variable into textToReplace. I guess the rest of the script is already fine.

@phunh - I added a scripts folder and put something in there. I am not sure exactly how the python script needs to be written for the build system to swap out the variables. Here is what I have so far...
https://invent.kde.org/scottpetrovic/krita-marketing-site-hugo/-/blob/master/scripts/custom_generation.py

@scottpetrovic Hugo does not process files in static folder (and even if the php file is in another folder, it's still not trivial to make Hugo substitute the variable in that php file), so we need to use something else. If you take a look at the Hugo pipeline template which as Ben said will be used for this Krita website, you can see the second stage named "Process data" where a Python script at scripts/custom_generation.py is run, and this is how we do different processing tasks for different Hugo websites. So my idea is to create that script file in your project and use that script to put the key into the php file. I think that suits your need here.

@phunh - That is correct. I tried to extract the key and put it in the hugo config, but hugo doesn't want to substitute the variables like it does with other contents. Like you were saying, it must ignore the static PHP folder and just do a copy/paste action when building or publishing. In general, Hugo doesn't seem to like PHP files. That is why I put it in the static folder to avoid any Hugo processing.

We will be using the Hugo Pipeline (or it's Gitlab equivalent) for this yes.

@bcooksley I guess what @scottpetrovic wants is basically putting the key as the argument in the line he linked to (am I correct Scott?). And since that php file is in static folder, Hugo does not touch it.

@scottpetrovic As long as Hugo can populate it from a environment variable then it shouldn't be a problem - we can inject those from the outside (especially easy once on Gitlab CI).

@rempt - Good to hear.

Regarding the API key, is this something that requires interactive code running on the server side?

Oh, this looks good! I think the translation issue is something we just will have to accept.

I am starting to work on the Mollie one-time payment option. Most of the work is just seeing how I want it to look and flow. This is kind of what I have right now.

I can always export the donation data from the mollie website -- and I've never really felt like doing an analysis :-)

It's definitely not ideal to be running two different applications to service this, especially when one of them (the Dev Fund app) is essentially bespoke code.
From a migration perspective we'd probably be better to strip down the existing Krita.org site instead of setting up an entirely new instance.

Oh -- the IDEAL (that's specifically Dutch) payments through mollie _do_ make a difference. There have been about fifty of them since we started using mollie, and they tend to be large -- in the order of 100 euros a time.

I guess I was a bit confused. The reason I was worried and thought we might have to replace the mollie form on the current website with a braintree form was their unreasonable demand to have the UBO form signed by an accountant. That turned out not be the problem.

After our IRC meeting this morning, it sounds like we are going to stick with Mollie for one-time payments. There were previously some issues with accounting which have all been cleared up. I started to look at what we currently do with our Mollie one-time payments. This is all the functionality that I can think of that we currently use

For Chinese Users, there is a QQ-Group: 735285940

In https://donorbox.zendesk.com/hc/en-us/categories/360002194912-Payment-Options it looks like donorbox also supports IDEAL, which I think stripe by itself doesn't -- which is why I was interested.

We could try donorbox. The service seems like it mainly goes through Stripe. I then started wondering why not just use Stripe, but it seems Donorbox has an extra layer of tools/usability to help manage non-profits that Stripe does not... https://stripe.com/en-ee/customers/donorbox

donorbox.org looks like a good option, too

My only concern around Braintree related to the issues that we had with the KDE e..V obtaining a Braintree account and what this indicated in terms of future support expectations from Braintree/PayPal.

@bcooksley - I brought up Braintree a bit ago when I was trying to build out the code to handle the payments coming through. You mentioned there was some concern with Braintree and we might want to think about another platform. Was it something related to their unwillingness to work with KDE? We are trying to decide what one-time payment option to use for a new krita.org.

Mollie still provides the largest selection of payment options. I would prefer braintree to stripe, because braintree pretty much is credit-card only, as far as I can see from here.

In T14731#278462, @scottpetrovic wrote:

Usually when I have worked with POT/PO files before, I would create a POT file to generate a PO file...not rename a POT file. POT files were usually the source file that all other languages would use to generate. This workflow just does it slightly different with the rename.

So it's true that POT is for templates, and PO is for files containing translations. However, it seems that when making translations, you didn't use any CAT tool but edited the POT file directly, thus your file stayed as release_note.pot. The renaming is not a part of our workflow, it only requires files to have the .po extension, and doesn't care about how files got that extension. POT/PO files are merely text files anyway, POs might have translations, POTs don't, so when you have a POT already containing translations, just change the extension.

The main topic I need to figure out right now for the new krita.org is how we want to handle one time payments to the Krita foundation. Currently any payments that are monthly or subscription-based are all taken care of on fund.krita.org. The fund website does not do one-time payments. Krita.org currently uses Mollie as the one time payment processor. It seems like this is not the preferred system we want to use in the future - so we want to do something different.

1. It is release_note.pot. That was a typo on my end. Sorry.

• After translating, you have to rename the file to release_note.po (change .pot to .po). This is how POT/PO file works. Btw please confirm that the name of your POT file is actually release_note.pot, not release_notes.pot, otherwise I would need to investigate what’s going wrong here;
• Then you have to put your PO file(s) into a subfolder of the folder that you will run compilation on. The name of this subfolder should be the code of the translations’ language. This is the directory structure that our i18n system uses in case of multiple translation catalogs (which is the PO_DIR procedure in hugo-i18n terminology), so hugo-i18n expects that structure as well. For example, you will run compilation on a pos folder, and you made translations to German, then you need to put PO file(s) into pos/de folder, then run hugoi18n compile pos.

@phunh - I installed linux mint and am trying again. I am not sure exactly what I am supposed to do after I extract the POT files.

• With your current config, FILENAME should not be set;
• Your project doesn’t exist in the i18n system on the SVN server, there’s no point in running the fetch step and that’s why I suggested you to translate yourself some strings in those POT files so that you can have PO files. The error is either due to PO files being nonexistent on SVN, or the path string is not compatible with Windows;
• Yes actually we need the gettext system from GNU but on Linux it’s always there so I never thought about putting it in the dependency list;
• You can install gettext on Windows as well but I agree it should be better if you can use Linux instead of Windows for this. I have fixed the path string handling but only for the config, there are path strings outside of the config and they might still make errors occur on your Windows.

I am also trying to run the compile step, but am getting another error with the "msgfmt command not being found". Are there other dependencies this process needs to work. Maybe it would be better if I just try to use a linux distro instead of trying to get it working on Windows.

@phunh - I am trying to run the next fetch step, but it keeps failing for some reason. After creating the POT files with the extract command, I do a command like

@scottpetrovic nice to know it works, at least the extraction. Now I’d suggest that you translate some strings in one or some of those POT files, then run the compilation and generation steps to see how dest files are produced.
On another note, I think it might be unnecessary to include all release notes. Maybe including only the latest one (and ones in the future) is enough?

@phunh - I pulled the latest and it appears to still not excluding quite right on Windows. Looking at the output log while it is extracting, the difference is on the last folder separator.

So I see that you are running this on Windows, and path strings don't match, that's the reason. I've pushed a fix for hugo-i18n, please update yours and try to run it again.

@phunh - I am right on master and it says it is 0.5.2 on the setup.cfg file.

@scottpetrovic could you check the version of hugo-i18n you are using? Please use the latest one which is 0.5.2. I can extract it fine.

@phunh - thanks for the assistance with this and got it running. I ran the extract command to see what all would be extracted from the hugo site.

@scottpetrovic you need to set PACKAGE, maybe let’s set it to something unique, like “web-atirk-gro”, so you will recognize where it’s used. And let’s just ignore FILENAME for now.

@phunh - ahh ok. I can make the config look like how it was without the separate translation folder. I can also add in the exclusion for the individual posts. I will eventually have to add more posts to it as Krita has created new content after I originally extracted these posts.

With the commit https://invent.kde.org/scottpetrovic/krita-marketing-site-hugo/-/commit/b25ee98341410558ab2ca59a077e8080ef0d94b8 I think things are made to be more complicated unnecessarily. Other projects are fine with the structure Carl suggested, but I have the impression that what he meant to solve in that suggestion is different from what you are expecting to achieve. The project structure until that commit was fine AFAICT, the commit only made configs and the project structure not fit together anymore while still left your expectation unsatisfied. I think it would be best now if you can just run the hugo-i18n commands to see for yourself how they would work with your project in our i18n system.

@scottpetrovic config entries for news posts before 2022 should be removed, there’s no arguing about that. What the exclude glob is for are the news posts in 2022 that are already there. The reason to exclude them is the same as the reason to not include posts in folders of previous years. If you don’t exclude those 2022 posts, as you include content/posts/2022/*, everything in that folder is included, including them. What makes you think that content/posts/2022/* would only include newer posts?

I did some changes based off the feedback.

For kde.org we have some files that there already translated:

@scottpetrovic by "the system" I mean "the KDE i18n system" which consists of Scripty and PO files on the SVN server. And it seems that I caused some confusion by using the word "translation" to talk about different things, sorry about that. So let us agree on the terminology and talk about how the KDE i18n system works, using an example of the file content/en/posts/2022/krita-5-0-2.md and your current configs:

• Let's call that English file the source file;
• Scripty will extract strings from that source file into a www_www.pot file (the name you specified in the config) and put that POT file to SVN. This is the extraction step;
• Translators will work on that POT file, producing www_www.po files, and put those PO files to SVN. Let's just call POT/PO files... POT/PO files;
• At the generation step, you may use a custom script, but for simplicity, let's say Scripty does this step: it gathers all www_www.po files of different languages from SVN, and for a language <lang>, it combines the www_www.po file of that language with the source file to create a file at content/<lang>/posts/2022/krita-5-0-2.md, let's call this file the dest file. This file will then be committed to your repo.

Now the issue, and what I tried to say in my comment in your commit, is that for some languages, the dest file already exists, but there's no POT/PO file on SVN yet, so when you hook this project to our i18n system, our translators will get the POT file for the first time, then the translations they produce will overwrite existing dest files. IMO we should just keep existing dest files as they are, and the way to do that is to not include the source file in the first place. Remember we are still in the context of the example. Now expand the context to all existing source files in the "posts" directory, I hope you see what I want to say, I think there's little value in making them translatable since they are old anyway. But of course that's just my opinion, please do it the way you find suitable.
If you exclude existing source files from i18n then translated content in the "content" folder are safe there, they will not be overwritten and of course there's no need to remove them.

@phunh - Ohh, yeah. So we only need the base english pages and content that need to be translated. I just updated that config to only include the english content

@scottpetrovic I just made a comment in your commit, please take a look.

@phunh - Thank you so much for looking at this. I wasn't sure about the recursive nature of the globs, but that verified it. Here is the updated config file...
https://invent.kde.org/scottpetrovic/krita-marketing-site-hugo/-/blob/master/config.yaml

@scottpetrovic so I have taken a closer look at your repo, here are some feedbacks:

• For the i18n config section:
  • There is no contents, it must be content;
  • Globs are not recursive. That glob should be at least "content/en/*" and it would only expand to paths of files right inside "content/en", not ones in its subfolders. You will need to include more globs or files if you want files in other folders to be translated;
  • Your project also has i18n strings, menu items, and site title. If you want to have them translated, you need others: [strings, menu, title];
  • English content files and their translations seem to be separated, so you might want to have genToOtherDir: true, too;
  • srcDir: content/en and genDir: content should be added as well, so that translations are generated at the correct location in your project.
• For the i18n of posts: you can exclude files that are included by other patterns in the content section. For example, you might want to include all posts in (the rest of) 2022, but exclude existing posts until now, so you can write:

i18n:
  content:
    www_www:
      ... # files
      globs:
      - content/en/posts/2022/*
      - ... # other globs
      excludedFiles:
      - content/en/posts/2022/interview-with-simon-rollins.md
      - content/en/posts/2022/krita-5-0-2.md
      - content/en/posts/2022/krita-in-2021-and-2022.md
      - content/en/posts/2022/multiple-perspective.md
      - content/en/posts/2022/new-video-by-ramon-the-recorder-docker.md
      - ... # other files
      excludedGlobs:
      - ... # globs to exclude if you want
    ... # other domains
  ... # other configs

Please read more about how the tooling works at https://invent.kde.org/websites/hugo-i18n

@rempt - We need to eventually think about what to do with the Mollie stuff...or an alternative. I haven't hooked up any one time payment things in the new site. If we want to go a different direction like Stripe, I could start looking into that.

@scottpetrovic you can try to run the script to

• extract and check whether strings that should be extracted are correctly extracted. This is to create translation templates for translators to work on;
• fetch translations, generate, and check whether generated files are good. From translations fetched from the SVN server, the script will generate files in other languages. One way to check if they are good is to use Git, after the generation is done, to check whether there's any change in those files.

I threw up a website on my github account to show what I have done so far.

I don't think fund.krita.org has that ability -- blender also still has a separate single time donation page. The donate link in the top menu goes to fund.blender.org, which has a link to https://www.blender.org/about/donations/. In any case, we will keep needing the single-time donation option for after the downloads. (We might have to change that to using braintree or stripe after the summer, since Mollie is messing around with UBO declarations.)

I think we have the content organization issue figured out.

Ah, I was too late reading my mail. Seems a solution is already there?

@phunh - yes. that could work with the permalink configuration option. Maybe for now I will put all the posts in year folders. If we can figure out how to make them work - great. If not, that is probably ok too.

It might even be possible to set the permalinks config field for the whole posts section, similarly to what was done on plasma-mobile-org. You can read more about that here.

In T14731#276953, @scottpetrovic wrote:

@rempt - I am starting to add all the old posts to this new hugo site. I am noticing we have 700+ posts as they go back through 2014. Seeing 700+ files in one folder is a bit difficult overwhelming to sift through and work with. It isn't as obvious in WordPress since it is a paginated table that shows new posts at the top.

I was thinking we could organize the posts by year to keep it better organized and easier to manage. This does have the downside of breaking old links because the URL is different -- which is probably going to happen anyway. is this alright?

@rempt - I am starting to add all the old posts to this new hugo site. I am noticing we have 700+ posts as they go back through 2014. Seeing 700+ files in one folder is a bit difficult overwhelming to sift through and work with. It isn't as obvious in WordPress since it is a paginated table that shows new posts at the top.

@weoxm - Thanks for the feedback. I like a lot of your ideas for the design aspect. We might be able to consolidate a bit of our pages too. The website might be a bit too verbose in places.