The banner has been added (by Harald Sitter I think).

For docs-kdenlive-org (as well as digikam-doc), I think removing the po folder would help. We are still seeing updates made to that po folder because files already in that folder before it's added to .gitignore are already tracked by Git, so Git continues tracking them. No new files have been added after the folder was added to .gitignore. So if the folder is removed, Git will not add any file in that folder.

In T14731#284267, @alvinhochun wrote:

Yes PO files might get big but I don't see any problem with that (so far, for various Hugo websites of ours). The risks of mistranslations, I can also say, are minimal as this website is for promo, not documentation or anything technical which I consider to be more probable to have same strings used in different contexts. In case some occur, there might be some technical difficulties in implementing context support in hugo-i18n, but I think we can work around that if it's necessary.

Understood. I will try to work with that.

One thing though, regarding strings extracted from the YAML file (krita-org.po), I think they really ought to have context. Those extracted from config.yaml (the menu items) can use the link URL, while those from i18n/en.yaml can use the translation id.

(krita-org.po is also missing line numbers to the YAML file, would be nice if they can be added.)

I think we should not add context to a large number of messages, since a context change makes the message fuzzy, we don't want translators to have more unnecessary works. We should not add context by default either, because that's just excessive: the case of having same messages used in different contexts is not regular, so we should just deal with it when it occurs. And actually, regarding implementing context support in hugo-i18n, what might be difficult is to do that for messages extracted from content files. For YAML files, that's not a big issue: we can make hugo-i18n support a "context" field in the params array of a menu item or in the declaration of an i18n string (we already support an arbitrary comment for an i18n string in the same way). So don't worry too much about that. When you find such a case, you tell me, I'll do it.

In T14731#284105, @tysontan wrote:

Since zh_CN is the standard code for Simplified Chinese, I think it makes sense to do that. The same thing goes to en_US for en too.

In T14731#284074, @scottpetrovic wrote:

@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.

In T14731#284093, @alvinhochun wrote:

Then I have some questions regarding i18n:

• The extracted krita-org.po seems to contain various strings from config.yaml and i18n/en.yaml, but I see that these strings can also be translated in config.yaml directly or with i18n/<language>.yaml. Which method should be preferred?

You don't translate any YAML file, only translate PO files.

• I see all text of most pages are lumped into several .po files. I don't know the typical translation workflow of other websites, but this seems a bit scary to me. (I guess I expected one .po file per page or post?) When we make long posts wouldn't that bloat the .po files? What are the risks of mistranslations from the same strings used in different context?

Yes PO files might get big but I don't see any problem with that (so far, for various Hugo websites of ours). The risks of mistranslations, I can also say, are minimal as this website is for promo, not documentation or anything technical which I consider to be more probable to have same strings used in different contexts. In case some occur, there might be some technical difficulties in implementing context support in hugo-i18n, but I think we can work around that if it's necessary.

• If I need custom text or layout for certain pages or posts in my language, I can put the custom translated markdown file in, say, content/zh-tw to bypass the .po i18n system, right?

If your markdown file is not i12ized (internationalized) (i.e. not included in the i18n section of the config file), then yes. Otherwise, currently, no, it will be overwritten by what hugo-i18n can get from KDE l10n system.

@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.

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

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.

@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.

@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.

@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.

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.

• 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.

• 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.

@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?

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.

@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.

@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.

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?

@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.

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

@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

@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.

In this MR, I have added pieces of info into app pages:

• Links to bug list and localization pages for apps with bug_database and identifier fields, respectively, specified in KDE Projects API. So, many apps will have these links shown on their pages on apps.k.o;
• Links to API docs, community wiki, userbase wiki for apps with respective fields specified in Hugo data. Since there seems to be no structure to connect between an app ID and corresponding pages on the two wikis, and since the new api.k.o contains mostly frameworks and libraries' API with apps' API in the legacy group, these data fields need to be set manually and thus now almost only utils apps have these links on their pages on apps.k.o.

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.

• Pages being statically generated resolves points 1 and 5;
• Getting CI artifacts and repositories is apparently the way to go if we want to systematically obtain updated app data. Anyway, with recent efforts, the build time is considerably reduced;
• appstsreamcli convert has been replaced by the py-appstream package which can be updated when we want to get more kinds of data;
• The staticweb image has been used to build the website, instead of the `suse-qt515 one.

Should we add these pieces of info into the same section where we are now showing links to Windows versions? With some text modification, of course, so that it doesn't mention only Windows ones?

Not only AppStream download button but other ones have all been redesigned to be visually uniform, less redundant, more familiar to users, and support l10n better, with this MR. You can see the discussion related to the MR here.

The redesign has finished. Let's close this.

KDiskFree and KDE Wallet Manager are listed on utils.k.o, they are also in the utilities group on Invent, but their desktop files list only "System" as their main category, so now they show up on only https://apps.kde.org/system. Should their desktop files also list "Utilities" in the "Categories" field?

Update: all, except the archiving step, are done for games.k.o:

• "How to play" sections are shown for games having the data. These sections can also be translated;
• Accessing games.k.o pages will redirect to corresponding parts on apps.k.o, except games.k.o/old and its subpages which are left untouched.

In T10827#271310, @felixernst wrote:

I haven't done a lot of webpage work but from what I can tell this seems like a solid plan.

So as I can see, the 3 websites that are equivalent to categories of our apps, edu.k.o, multimedia.k.o, and utils.k.o, are still alive and really outdated, even though we already have some other plans for them. The other category-equivalent one, games.k.o, although has been ported to Jekyll, I think can still be improved.

The website has been refreshed and is ready to be extracted by Scripty.

In T14791#261713, @Guilhermems wrote:

Which one of these files (https://collaborate.kde.org/f/60621) is supposed to go on the press kit pages? The ZIP file?