Back

Some interesting tidbits from my initial research:

There are the popular i18n frameworks (i18next, etc.) and then some really small ones like Lisan, Rosettta, etc.

And some tie in with localisation services (e.g., i18next and Locize) to enable continuous translations.

Not sure what level of support to add for what in Kitten yet but going to have a play with a number of them to see how they feel…

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

Oh, and thank you all for your suggestions and for sharing your experiences :)

@algernon Thanks; that’s very useful :)

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

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

@aral
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 ;)

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

@RyunoKi Merci :)

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

@aral
If you look beyond translation, keep an eye out on currency and date formatting as well as LTR and RTL support (can switch inline!).

Writing mode top to bottom isn't that common (even in Japan) from what locals told me.

Say, look at some Arabic (Al Jazeera?) And Japanese sites. Study how they apply HTML and CSS :)

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

@aral Probably on the heavier side, yes. But very flexible to allow high quality l10n and easy to use.

@Changaco @fabrice Thanks; that’s really helpful :)

@nemobis @Changaco @aral They moved all gecko (ie. Firefox) l10n to Fluent, so I would say it's here to stay.