@algernon Thanks; that’s very useful :)

@Jelv @Liberapay Thanks :)

@cybeardjm Thanks! :)

PS. Assuming that’s just for the translations. They don’t have an internationalisation or localisation framework last I checked.

hello @aral you really are lucky because floss community have a great tool to handle a smooth translation workflow between devs and translators: weblate. You can self host it yourself, or be welcomes on hosted.weblate.org or other communities like Fedora, Codeberg, etc.
One thing to remember, weblate will either commit directly on your git repo or open pull requests. It means you let it handle all translation files so that your life is made easy with no conflict:)
@goofy

the real question is the file format you will use.
Documentation and website are well handled in asciidoc and then translated in gettext files using the great po4a. All translation platforms handle it well.
But translating UI or libraries, especially in javascript is challenging. Take the time to make your choice, use an existing standard well supported, and do the best with it, please do not invent a new one. Languages have a lot of traps for devs, you may want to delegate this.
@goofy

@jibec Thank you for sharing your experience and for the tips; appreciate it :)

@goofy

since your code is already on codeberg and that codeberg already provides weblate, what leaded you to ask this question? Any worries or issues with weblate? Or maybe you simply did not know weblate instance exists on codeberg?
@goofy

@jibec @goofy Just doing my research, like I always do ;)

@desikn
@Codeberg has a Weblate Instance now: https://translate.codeberg.org/

I used Weblate before as a contributor and it works well. Not sure if it is the best.

@davidak @desikn @Codeberg Oh, that’s good to know :) Thank you!

@RyunoKi Thanks; that’s very helpful, appreciate it :)

Oh and I just remembered some projects using https://crowdin.com/

@RyunoKi Merci :)

You're welcome.

I've got some experience in both areas.

Even if it is not a requirement I tend to start with some basic i18n support (often some sort of keys + JSON files) to have an easier transition period.
Business folks tend to prefer Excel, though.

Otherwise it's just so laboursome to collect all those places where i18n would be required 😞

@martijn Thanks, Martijn, appreciate you sharing your experience. Just out of curiosity (having only poked it a bit today) what is it about Weblate that makes you hate it?

Most other tools have similar hotkeys, a reasonable amount doesn't or didn't work in weblate. It's UI has different margins everywhere and in very bright. It generated broken po files earlier, but I was told that that was fixed.

… My gut feeling is that a lightweight framework like Lisan or Rosetta combinated with the ECMAScript Internationalisation API might feel right for Kitten.

(Or perhaps it’s best not to build in support and leave that as a project-level decision folks can make if they want to. I’ll start implementing internationalisation/localisation in Domain and see how it goes and which bits, if any, feel like they should be in the platform instead of the app. That’s basically been my approach so far.)

I'm using https://github.com/projectfluent/fluent-web in Capyloon and it's pretty good.

@fabrice Thanks, was looking at it earlier but it did seem rather heavyweight. Will take another look :)