1. With the new funding site, we need to integrate it better with krita.org so it is not just a banner on the top

Blender.org has a big blue button in the top menu -- it's visible, but it doesn't look that cluttered.

1. the homepage is a bit crammed right now with all the sections. We probably need to give more room for each thing and also highlight a few features

I agree

1. decide what we might want to do with the shop long term

The shop is still bringing in money, so I'd like to keep it going. The USB drives are surprisingly popular.

1. decide what we might want to do with the artist interviews. We haven't done any in a while

Maybe do a call for participation a couple of times. Irina is trying to get people to submit interviews, but is not getting a lot of response.

1. do a better job at how we communicate donations. Right now the page defaults to going to the one-time donations...then only goes to the funding site if you click the "monthly donations" option

We can also put the one-time donation form on the fund.krita.org website, and then make the button go there directly?

1. maybe see if we can consolidate some of the sections on the About area. We have so many...https://krita.org/en/about/history/

I wouldn't know how to do that... Though I'd like to get rid of the roadmap page, it's never accurate.

1. show more artwork through various sections

Not many ideas on the design, but would say I don't quite like how localization is done with the current front page and download page, which is with a fixed template and translating each sentence or paragraph with gettext. It limits what we can do with the localized version of the page.

I don't mean that we would redesign the whole page when localizing, but there are stuff that works better when you have more control of the page. Take for example the text "Krita is a professional FREE and open source painting program" uses capitalization as a form of emphasis. If I want to translate it faithfully into Chinese, the proper way to do it is to use bold instead, because there is no capitalization in the language, which I cannot do because I don't get to control the markup. Also, localization doesn't simply mean translation. Sometimes this includes adapting the content to the target audience. For example, on the Simplified Chinese front page, @tysontan basically has to (ab)use the text for the box to give a more practical introduction to Simplified Chinese visitors.

the homepage is a bit crammed right now with all the sections. We probably need to give more room for each thing and also highlight a few features

I think the front page seems a bit lacking in content. I wouldn't mind a bit more text, and some short feature introduction would be nice. I don't actually find the current front page crammed (there's barely any information?), but the images can be smaller and less padding below the splash image might be a good idea too. (But do note that I am bad at web design so don't take my opinion too heavily.)

By the way, in the past I mentioned on IRC that viewing the site with JavaScript disabled is broken, this is how it looks:

Can we make it a normal img tag with src linking to the banner directly? I don't see the point of having it lazy-loaded.

@alvinhochun - Yes, we could do some changes to that.

It sounds like based on IRC, there is a push to move a lot (or maybe all) of krita.org away from using WordPress and into a static site generator. With this change, it sounds like a lot of the language localization issues will be easier to manage. Most of the site is pretty static anyway being marketing or informational, so moving most of it should be fine. The only thing we might want to think about is things like news posts being kept in a blog format with WordPress. We will need to see how people feel about doing news posts in a static site generator instead of WordPress. It won't be too hard, but the process will be different and will require people to build the GIT project locally to see their changes and pushing it out via GIT. Of course we will need a build system on KDE to actually rebuild the changes.

Potential Solution
@woltherav mentioned potentially moving to Hugo as the solution. https://gohugo.io/ I see it has features like "drafts" and "publish dates" as features, so that could work. We will need to play around with how we are going to migrate certain functionality like the email list signup. Also not sure if we will need some extra caching functionality like we have in the WordPress site. In terms of pages, there are a TON of pages that are news posts. I am not sure if we want to migrate all of those, or how we want to handle that. Previously we had a migration tool moving all that from Joomla to WordPress, so we didn't have to do a ton of work.

Tech upgrades
If we move this over, I would like to also upgrade a bit of the libraries we use for the site. For example, I would rather not use jQuery for javascript. We are also using a pretty old Bootstrap version (3.1.1), so we might want to decide if we want to use another framework. Upgrading to the newest version of bootstrap will reduce the amount of HTML we will have to rewrite. We might want to start using the "webp" image format more now too as it is widely supported and smaller file sizes.

Discussion/next steps
I would say we need to discuss the following a bit to make sure it is ok with people

1. Are we ok moving krita.org to use a static site generator
2. Are people ok creating news posts in this format instead of a bit more easily (like in WordPress) @rempt

If we are ok with that, we probably just need to start a new project on invent.kde.org and play around with Hugo a bit and see what it can do. I am sure we will have questions and discussion points as we try to see if Hugo can do everything we need.

Currently on a 1080P monitor and above, the header image is cropped in a weird way.

I can really appreciate more vertical space for the header image.

Since the current W:H ratio is almost 4:1, it is really difficult for me to come up with a usable composition. It doesn't help that the crop line goes higher on the left, leaving even less space for the character.

For example, if we can get rid of the blue wedge under the picture, replace it with a gradient bleeding into the News widget's background, there will be more room to breath.

@tysontan - that is a good idea. I think when we originally came up with this design, we were trying to cram a lot of things "above the fold". I think if we revise the homepage, we can give each area more space...and be ok with a bit of scrolling. We can give this "hero" image more space if/when we redo this.

Good afternoon,
I am new to open source projet, and it's my first time contributing... but for me, the first thing to do is to check if all translation are up to date.
For instance, French translation is totally not up to date. The "get involved" page have some link down (include Developers link) , and you can even find the link to the chat IRC page.
I would like to help to update French translation, but a don't know how to do this.

I am also open to help on the code if my skills follow. :)

Alps.

Hello all,

This is very basic and not too different from the current layout but sort of a general idea

• limit to 4-5 "things" for less clutter, everything else in header
• highlight features
• keep everything else mentioned in consideration, as well as making sure current resources are accessible

1. kiki primary "color/value/positive space"

important note: more vertical space for the image

2. header + donations (referenced blender.org for placement, but would a third color that contrasts the blue of the homepage work better than one that matches the download button? like pink)

Also in header:

• Features
• Download
• Learn
• About
• Get involved
• shop (6)
• language picking menu, maybe mention translating krita as a last option on the desktop menu?

3. download button

4. news and features

4.5 features (opportunity to show community artwork, "sneak peak" for full features page, potential to add ALT tags to images?)

• question: should the wiki count as a "feature?" or stay in the header?

4.7 news

• News
• Interviews as news? (new question: would the News feed look better represented with more pictures than text on the homepage?

It might make sense if interviews are included, and if feature update news is represented with artwork, but would need more scrolling on mobile.)

5 - ish community focus reminder to get involved

• linking to KA is one option, or the Get involved page, community and involvement is tough because certain people prefer certain platforms, or ways of getting involved, what would be most important on the homepage?

6. Misc notes
7. keep shop in tab bar for now
8. Trying to include more artwork, maybe through the news feed?

Also possible suggestion for about page tabs?

• COMBINE history + release history
• License
• Krita Foundation
• Press
• REMOVE Contact: Similar to "get involved" and "Krita foundation" (formal contact) maybe emphasize button to krita-artists.org on "Get involved page" and , if it would help with calls of participation etc, homepage?
• REMOVE Roadmap if it is not useful/accurate - maybe emphasize a project roadmap on donation page(s) or news updates?
• Mascot
• FAQ

More administration-ish questions and ideas from the thread

• Trade-offs of static site generator vs current setup (really not sure at all)
• whats a better way to handle localization template?
• How to localize best for certain regions and handle translations?
• How to handle donations page?
• What to do with shop long term (might be a separate project than overall design?)

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

For the administrative questions, one of the big advantages of the static site generator is it will make doing translations a lot easier. right now it is pretty confusing with multiple different processes depending on what a translator wants to edit. Some changes need a PO file, some changes need to be done directly in WordPress that saves to the database, and other translations need to be done in the PHP template files if we make large changes.

For a progress update for me, I finally am getting the Hugo framework figured out better (static site generator). There are some things that Hugo does that are pretty weird and confusing from a file organization which is why it was taking a while. I think it will work though. We might have to make a few compromises, but I think it will be better overall and make it easier to make changes.

I have a fair amount of the technical stuff figured out. I need to start stubbing out more pages now and building it out. There are so many pages and translations, it is going to be a slog trying to replace and update everything.

When I get a bit farther, I will throw something up on invent.kde.org. I will also write a pretty detailed readme about how to get the project going. It mostly just needs to the Hugo command line tool downloaded which generates the site.

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

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?

You can define alias in Hugo to keep the old URL working ;) This is what we used in kde.org also if you have a repo available maybe I or @phunh could take a look at it and give some feedback

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.

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

@ognarb - When I get a bit farther with moving the content over I can post a WIP version for the GIT repository. I want to at least bring all the various posts and pages into the new site as markdown in the various languages.

After that there will be a lot of discussion of the content organization and design of everything. Also need to change where we point to a lot of image/video files. There was discussion of moving a lot of the large things to cd.kde.org instead of storing them all in the GIT repository.

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

I think we have the content organization issue figured out.

@rempt - As I am organizing the pages on the new krita.org site, I am running into a situation where we need to figure out how to organize the donation/funding pages. Right now we have the top banner going directly to fund.krita.org, and the "Donate" navigation link going to other pages that talk about what the donations go toward, monthly subscriptions, contracting, and individual donation options

I wonder if it would be better to organize all the donations/sponsors/funding stuff and put it all on fund.krita.org. It seems a bit disjointed right now having some information on krita.org, and other information on fund.krita.org

@ognarb - I wonder if the fund.krita.org site has any way of doing single time payments. Having one source to manage donations would be better long term than having two separate services. Originally we were using Mollie for subscriptions, but that isn't the case going forward. this might need more discussion about how we want to manage this.

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 threw up a website on my github account to show what I have done so far.

https://scottpetrovic.github.io/krita-hugo/

@ognarb, @phunh - I think I have the translations setup so the i18n stuff will work, but I am not sure if I did it correctly. If you could take a look at my repository and give any feedback, that would be great... https://invent.kde.org/scottpetrovic/krita-marketing-site-hugo

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

@tysontan - Does this leave more space for your artwork on the homepage. I am wanting to give it more space instead of putting the KDE logo and other stuff. Maybe it is a better crop now.

I need to do a lot more work making a lot of the other pages translatable. Once I know the pattern I am using is ok, I can do more of 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.

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

Mollie is being unreasonable with its UBO requirements -- they want an accountant to sign of on the form, but Dutch accounts have collectively decided they are not going to do that, and my negotiations with them are not going well.

We're using Stripe for payments through liberapay and Braintree for fund.krita.org. It might be good to use Braintree for the one-off donations form as well, though they don't support as many payment methods as Mollie does.

@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

@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

When this project gets a bit closer, we will eventually need to start hooking this project up to the translation pipeline. We could probably put this whole site on dev.krita.org as that really isn't being used and would be good for testing and developing. I am sure we can make tweaks as we find out more things.

Next for me is figuring out what we want to do for one-time payments and getting that plugged in. Maybe we can make that translatable too.

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

@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

To help clarify this statement you said "no translation for your project in the system yet." Does that mean that the other language translations will be all stored and managed in a different repository? If that is the case, I can always just move the existing translation files from my project to the new system.

Would it be better for now to just remove all the translated content in the "content" folder? It is in GIT, so it will be easy to retrieve later

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

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

What I did and worked quite well:

• content -> contains all the content in English (name: content/path/file.md )+ the old translated files that there manually translated back them and didn't want to put into scripty (name: content/path/file.<lang>.md)

• content-trans -> entirely managed by scripty and hugo-i18n. name: content-trans/<lang>/path/file.md

This is a structure I would recommend

I did some changes based off the feedback.

@ognarb - I like the idea of separating out the translated content with what is managed by an external process. I can make a note in the readme that everything in this folder is managed externally and will be overwritten if you don't use that. Then provide a link to the i18n page where they can see how to do the translations.

@phunh - Thanks for the clarification. I think I understand it a bit better now. I actually removed all the older (2020 and earlier) news posts from what will be translated in the English area. That way we don't need to even exclude anything. That might simplify it a bit from having a glob for include, and a glob for exclude.

Here is what the config looks like now.
https://invent.kde.org/scottpetrovic/krita-marketing-site-hugo/-/blob/master/config.yaml

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

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.

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

For building and testing, is there a guide? I am not too great at python to know the steps to run this. I have Python 3.10 installed and pip3. I looked through the readme for the project, but mostly just see that there is supposed to be a "hugoi18n" command I can run.
https://invent.kde.org/websites/hugo-i18n

I think I am getting close, but not sure. I added the hugoi18n folder to my environment variables after cloning the repository. I can now access a "hugoi18n" command from the terminal. When I go to my krita site root directory and run "hugo18n --help", I get some comments on what commands I can run so I think it is installed right. I then run "hugoi18n extract -h pot" but get an error. Here is the error. Not sure if this is useful.

Traceback (most recent call last):
  File "C:\Users\scott\AppData\Local\Programs\Python\Python310\Scripts\hugoi18n-script.py", line 33, in <module>
    sys.exit(load_entry_point('hugoi18n==0.5.2', 'console_scripts', 'hugoi18n')())
  File "C:\Users\scott\AppData\Local\Programs\Python\Python310\lib\site-packages\hugoi18n-0.5.2-py3.10.egg\hugoi18n\command_line.py", line 52, in main
    args.func(args)
  File "C:\Users\scott\AppData\Local\Programs\Python\Python310\lib\site-packages\hugoi18n-0.5.2-py3.10.egg\hugoi18n\command_line.py", line 66, in extract
    package = os.environ['PACKAGE']
  File "C:\Users\scott\AppData\Local\Programs\Python\Python310\lib\os.py", line 679, in __getitem__
    raise KeyError(key) from None
KeyError: 'PACKAGE'

I see there is a PACKAGE and FILENAME environment variable mentioned in the readme, but I am not sure if/what I need to set that to

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

For some reason the excludedFiles section is not excluding the news posts though. It is including all the news posts for 2022 with the glob, but not the following exludeFiles statement.

Here is my updated config file. I also put all the content back into the "content" folder instead of breaking it apart.
https://invent.kde.org/scottpetrovic/krita-marketing-site-hugo/-/blob/master/config.yaml

It looks like it the hugoi18n command is extracting all the images as well. I guess that is ok, but wasn't sure.

@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 - I am right on master and it says it is 0.5.2 on the setup.cfg file.

Again, the extraction command works. The issue was the "excludedFiles" section in the site config was not excluding anything with the extract process. Everything was being added with the glob line

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

extract successfully ignores files if I change it to this...

• 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

I can also just change all the i18n configuration paths to use \ for the separators. That seems to work too. I did that for now on my Windows machine.
https://invent.kde.org/scottpetrovic/krita-marketing-site-hugo/-/blob/master/config.yaml

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

hugoi18n fetch languages

A languages folder is created, but then the process errors out with the following:

Traceback (most recent call last):
  File "C:\Users\scott\AppData\Local\Programs\Python\Python310\Scripts\hugoi18n-script.py", line 33, in <module>
    sys.exit(load_entry_point('hugoi18n==0.5.2', 'console_scripts', 'hugoi18n')())
  File "C:\Users\scott\AppData\Local\Programs\Python\Python310\lib\site-packages\hugoi18n-0.5.2-py3.10.egg\hugoi18n\command_line.py", line 52, in main
    args.func(args)
  File "C:\Users\scott\AppData\Local\Programs\Python\Python310\lib\site-packages\hugoi18n-0.5.2-py3.10.egg\hugoi18n\command_line.py", line 200, in fetch
    fetch_langs(hugo_langs, args.as_file, args.dest)
  File "C:\Users\scott\AppData\Local\Programs\Python\Python310\lib\site-packages\hugoi18n-0.5.2-py3.10.egg\hugoi18n\command_line.py", line 231, in fetch_langs
    subprocess.check_output(['svn', 'export', svn_path, f'{output}@'], stderr=subprocess.PIPE)
  File "C:\Users\scott\AppData\Local\Programs\Python\Python310\lib\subprocess.py", line 420, in check_output
    return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
  File "C:\Users\scott\AppData\Local\Programs\Python\Python310\lib\subprocess.py", line 501, in run
    with Popen(*popenargs, **kwargs) as process:
  File "C:\Users\scott\AppData\Local\Programs\Python\Python310\lib\subprocess.py", line 969, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "C:\Users\scott\AppData\Local\Programs\Python\Python310\lib\subprocess.py", line 1438, in _execute_child
    hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
FileNotFoundError: [WinError 2] The system cannot find the file specified

It says file not found, but not sure what file it is even looking for. I did create a FILENAME environment variable, but that didn't seem to make a difference.

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.

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

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

I did some translations on the POT file, then I tried calling the command "i18nhugo compile pot" file to continue to the next step. A locale folder was created, and created a single folder called release_notes.pot. Inside of that has a LC_MESSAGES in it that is empty.

• 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

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

2. Alright. I got it going with those instructions. 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.

The generate step seems to work too. I did a "git status" to see what was all different after it finished. The generate step updates the config with the translations as well as the translations in the content folder.

I think we are all good unless you think of anything else. Testing the site on linux is good too for me. I found a couple other minor issues with pathing and case sensitivity with how I built the site.

Thanks for all the assistance understanding this.

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. There was one idea of using Braintree of doing one time payments. I started going down this route and @bcooksley brought up we might not want to go this route.
2. There was another idea of using something like Stripe to do one-time payments. Is this still an option @rempt?
3. It looks like Blender is using a PayPal option that is outside the normal fund site... https://www.blender.org/about/donations/

Once we get this resolved, I can get a fresh version of the new site up and do a bit more reviewing. I might post something on krita-artists to get their feedback before we start hooking it up to a build system or translation system.

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.

I think we are all good unless you think of anything else. Testing the site on linux is good too for me. I found a couple other minor issues with pathing and case sensitivity with how I built the site.

I might look more into your project when I have more time. For now if you say it's good then it's good for me too.

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.

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

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.

donorbox.org looks like a good option, too

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

@rempt - Do you want to create a Donorbox account at some point for the foundation and play around with it? I spent a short amount of time looking at the site integration portion, which seems straightforward. It also seems to handle monthly subscriptions if for some reason braintree has issues in the future.

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.

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

1. Takes care of the one-time payments transactions
2. Has a form in WordPress where the donation text and options are configured (options like what payment types we support)
3. The donation records are saved anonymously to a database
4. The fund.krita.org site uses this transaction data to help determine how many donations we get per month (via a WordPress REST API call)
5. When donations are made, an email gets sent out to people thanking them. This email form is configured in WordPress

It is going to be a lot of work if I have to recreate all of this functionality manually. All the code to do these things are built into the WordPress plugin. I wonder if we can stand up a fresh WordPress site that just deals with one-time payments? With a fresh install, we could install the Mollie plugin again and configure it like we currently have it. If someone wants to do a one-time donation, we can link them to that site. We can limit the scope of the site to just deal with one-time payments.

@bcooksley - Does this seem approach seem convoluted for getting one-time payments going for the new krita.org? I would like a solution that works pretty well out of the box without a ton of custom coding. This was my first stab at thinking what we could do.

The cleanest solution would be to put everything in the fund.krita.org site. That uses Braintree though. I think that site uses the Django framework. There is a Mollie plugin for that, but it says it is deprecated which worries me... https://github.com/peeb/django-mollie-ideal/tree/choices_refactor. I am also not very comfortable with Django, so my preference is going to be what I know best.

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.

For the new website:

I'm fine with fund.krita.org not counting the one-time donations: we only did that initially to jump-start the development fund. I can get the statistics for the weekly update from the mollie dashboard.

We also don't need the database of transactions that the mollie plugin gave us, because that just duplicates the customer list I can see in the mollie dashboard.

Pretty much the only thing we need is a form that allows one-time donations in two places: right after download and on the donations page -- and if that's easier with braintree than with mollie, then braintree is fine.

Even plain paypal would be fine: the sepa payments can also be done by a bank transfer from anywhere.

Blender redirect donations to fund.blender.org, with a link to one-time donations: https://www.blender.org/about/donations/ -- this first again plugs the development fund (I'm not sure whether that's a good idea...) and then offers bank transfer and a simple paypal donation button.

I think a form is better than a button that redirects to paypal though, because then you can have a prepared amount and make it as simple as possible to donate. (Paypal does have embeddable forms, right?)

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.

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.

That being said, if the database part of it is no longer needed then i'd suggest a static form (using Mollie if it is possible).

If we ever needed to perform analysis on the donations data then I could add another database to a private section of metrics.kde.org (that is where the KDE.org donations data will be going once we finish setting up Donorbox)

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

Ideally, I'd also want a static form that talks to mollie.

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 created a "shortcode" so we can insert the one-time-donation into various areas when we write content. On the current krita.org, there is extra information we have to fill out like name and email...but that isn't actually required at all for Mollie. That is there because it gets saved to the WordPress database. All we really need is the amount at this point...so that is what I am doing. This is what it will look like...

There is also an API key for Mollie that we probably don't want to store in source control. People could do malicious things with it if they know what the key.

When they click donate, the page will take them to a Mollie payment gateway that they can choose their payment method and do the transaction. That looks like this...

Once they do the donation, there is a redirect URL that Mollie takes us back to Krita.org. This will be the thank you page. I think there is going to be some transaction ID in case someone has questions about it. I am not sure what the Mollie dashboard looks like, so maybe this extra transaction ID thing isn't even needed. This is what I have the thank you page looking like now.

Let me know your thoughts, or if all this direction sounds alright.

One thing that I am still thinking about is translations. The krita.org site is translatable, but the Mollie payment gateway only supports specific languages based of this article.
https://help.mollie.com/hc/en-us/articles/115000715405-Is-the-Mollie-dashboard-available-in-multiple-languages-#:~:text=The%20languages%20we%20currently%20support,German%2C%20French%2C%20and%20Spanish.

If someone wants to do a one-time donation in Chinese for example, there is a good chance they are not going to be able to complete it.

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

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

@rempt - Good to hear.

@bcooksley - This is a string that will need to be populated on a PHP page. It is a static key, so it is always the same. There is only one API key. Is there something that can inject the API key into the file during the build process before or after hugo generates all the final webpage files?

This is where the API key needs to be swapped out in the code...
https://invent.kde.org/scottpetrovic/krita-marketing-site-hugo/-/blob/master/themes/krita-org-theme/static/php/mollie-one-time-donation.php#L17

I have a bit more work left between finishing this, making some of the theme files translatable, and adding some more news posts since I originally started this. At that point we can look at getting some type of build going and hooking it into our our normal i18n translation process.

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

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

Are we going to use the Hugo pipeline for this website? In that case, we can use the scripts/custom_generation.py script to put the key read from some env. variable into the php file.

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

@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 need to use some type of hugo pipeline since the whole site is built with Hugo. I just wasn't sure if there was some way to swap a token or something where that API key is. It sounds like that could be doable.

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

I am not sure what all is involved for getting a new hugo environment build going for testing. We could probably start it at any point. I have some work left with the translation strings, but I could always slowly add some of that stuff while the build is being set up.

Should I create an infrastructure request with getting this started?

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

As for getting the site started, @bcooksley please help.

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.

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/

If anyone has any feedback about things on the site that don't look right, or improvements, let me know. I cannot promise I am going to do everything as I am just one person, but it will be good to know what things that I might not know about.

Todo items

1. I need to make more pages/templates translatable
2. KDE infrastructure is going to be moving away from Jenkins for a different build system. A different build system will be in place before we launch
3. with new build system, we can get the one-time payments with the API key actually hooked up correctly
4. I need to add more polish/juice to make it better
5. I need to create a template for the "help krita out" that appears on various posts and pages". Right now it looks pretty ugly and not formatted

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.

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?

On top of that, I have 2 concerns about the multi-language support: 1) It doesn't auto-detect my browser's language and change accordingly; 2) The Language droplist locate at the bottom of the website, and it is tiny. By comparison, the way our current website handles language is ideal.

A few days ago, I proposed on the mail list to draw a few new pictures for "Tools You Need To Grow as an Artist" block, so that they fit the topic better. Do you like the idea?

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

It looks like from what I can tell that parts (1) and (2) have been completed, but part (3) is still missing based on the current contents of custom_generation.py.

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

For the design placement, we can certainly move it around. When I originally started adding it at the bottom, I was still understanding how to get it to technically work. I just moved it to the top.

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

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

Btw can I ask why we don't want to use Hugo modules, as in https://invent.kde.org/websites/krita-org/-/commit/3feed7a303011359477c9e7f882f152bec4eb392#note_566368? I'm thinking about apply our kde-hugo module to this website, it's not only about theming but also about other components that can be re-used, such as the site organization, the search functionality, the menu bar, the language selector, etc., and reusing instead of reimplementing would make our websites more maintainable. To do that, we would need to make use of Hugo modules, so I'm asking here whether we want to do that or not.

Some points with Krita integration:

• The site needs to serve the RSS feed at /en/feed/, as well as other locales for the news box on the welcome screen to work.
• The update checker used for Windows and macOS checks the /en/feed/ feed and looks for the latest post with the category matching "Official Release" exactly, then looks for a version number in the title.

These seems to be missing on the current dev site. We should set this up on the new site so that the existing Krita releases out there will still be able to get the info they need.

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

For the hugo modules, I wasn't aware of any reason we actually needed them. The only that was added previously was making bootstrap a scss file. That doesn't have any value since it is a library that should never have to be edited anyway. It seemed like adding a hugo dependency to the project just for that was not worth it.

If we need the kde-hugo module to make the site work, we can add it. In terms of reasoning of why I don't want it, it mostly centers around making the website building and editing as easy as possible. Most of the people that write posts are not web developer types, so I am trying to make sure things are as easy as possible for people. I don't want to this site to turn into the krita funding site which pretty much no one can build and run except Carl.

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

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

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

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

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

I also see some things that can be improved. I'll probably just make MRs directly.

Should we set defaultContentLanguageInSubdir: true so that English pages live under /en/ like on the old site? It would make language detection redirection easier. I guess we can reuse the detection and redirection setup for docs.krita.org with some tweaks, can't we? (Though I recall it does not remember if the user manually switched language.)

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

This link was internal team link and was not public, but I moved the discussion to a public place you can see the feedback thread here - https://krita-artists.org/t/new-krita-org-website-feedback/

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

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

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.

Ok let me see what I can do.

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.

I would suggest we keep using "en", for our convenience.

In T14731#284109, @phunh wrote:

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.

Ack.

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

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

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

I would really appreciate some way to support this. For example, if I reworded something in the translated UI of Krita, I would like to add an extra section in the release post and release notes to mention that for reference.

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.

As for line numbers in YAML files, that's not supported by the YAML parser yet. We will have it after the parser library has it.

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.

I would really appreciate some way to support this. For example, if I reworded something in the translated UI of Krita, I would like to add an extra section in the release post and release notes to mention that for reference.

So we, and the KDE l10n system, try to keep the English and other languages' versions always in sync, i.e. when the English version changes, translators can see the changes and provide updated translations. To do what you want, I think we'll need to break that synchronization. What I'm having in mind is like this:

• Currently this website is made to work similarly to other KDE's Hugo websites, let's call it the method of implicit translations: for components that are i12ized (i.e. content files, i18n strings, site title, description, menu listed in the i18n config section), no other languages' versions are needed in the repo, all are (re)generated at build time from the English version and PO files committed to the po folder by KDE l10n system. There's another method of explicit translations: when the KDE l10n system runs, PO files are not committed to the po folder but used together with the English version to generate other languages' versions, which are then committed to the repo. At build time we don't generate those anymore and just build with what we have in the repo. Firstly, we need to switch to this second method;
• Now let's say you have translated a content file (e.g. a release post named "krita-5.100.md") and you want to add an extra section to it, for your language only. You'll need to specify in the config file:

i18n:
  ...
  content:
    ...
    news:
      ...
      files:
        ...
        - path: content/en/posts/2022/krita-5.100.md
          no_sync: [zh-hk, zh-tw] # this is a list, other languages can opt out of sync too
        ...
      ...
    ...
  ...

And then you can edit the version in your language (content/zh-hk/posts/2022/krita-5.100.md or content/zh-tw/posts/2022/krita-5.100.md) in any way you want, but from this point on, hugo-i18n will not touch the version in your language anymore (i.e. when generating other languages' versions for the file, it sees that your language is in the no_sync list, so it won't regenerate your language's version).

How do you think about that?