Translate Fider to other languages

[goenning]

Source: https://feedback.fider.io/posts/8/translate-fider-to-other-languages-internationalization-i18n

Fider is currently available only on English and our the long term goal is to internationalise it. Being an open source project, we hope to engage with the global community to help us translate it to every existing language ❤

But before we get there, there's a long path we need to trail to make our strings translatable. The goal of this issue is to track the Plan and Development of this feature. Join us with ideas, feedback and code contributions!

Definitions

1) The language is defined per tenant/site and is not based on current browser language (Accept-Language HTTP Header); 2) The user submitted content WILL NOT be translated; 3) If a string is not translated, it'll default to English. So it's perfectly possible for some sites to have a mixed Non-English/English text for languages that are not 100% translated; We should show the percentage of completion for each language when user is selecting a language; 4) The browser should only download the strings for the required language. 5) The strings that are stored in JSON/XML/TXT/whatever must be available to both Go and React.

Questions:

1) Which languages to start with? I (@goenning) can translate it to English and Brazilian Portuguese 2) How can we support RTL languages? Is it hard? 3) Which platform to use? GitHub? Crowdin? What other? 4) Which format to store the strings? JSON? 5) How do we introduce breaking changes to existing strings? Say we have: { key: "NOT_FOUND_MESSAGE", value: "The page is not found." } and this has been translated to every language. What if we change text to This page does not exist.? How do "deprecate other" strings that have already been translated. 6) Any Go+React package that can help us on this? It doesn't seem to be hard to implement, but other packages might give us some inspiration. 7) Do we need different validation per language? E.g.: Latin alphabet we should validate that titles must have at least 10 chars. But on Chinese/Japanese, maybe 2 or 3 is enough. (ref: #614)

If anyone has experience with a multilingual platform, please share your thoughts and suggestions!

[lkraider]

Hello,

I would recommend centering the message interchange format on gettext mo/po files, it is the de-facto standard, and multiple cloud based translation collaboration tools work off of that.

For the specific language tools, then trace the ones that can convert bidirectionally from their own format, if any, or work directly with gettext.

For JS React (that have the mentioned features) I've looked into:

i18next: https://www.i18next.com/ https://github.com/i18next/i18next-gettext-converter

Lingui: https://lingui.js.org https://lingui.js.org/ref/conf.html#po

[Sven65]

I am available to do some translation into Swedish

[peterver]

@goenning I am available to do translations to dutch :) in case needed

[peterver]

@goenning @lkraider I would suggest it also be possible to have english as the default fallback/source language, so that any translation strings that aren't translated in a specific language fallback to the english version ( to have at least something display on the screen ).

[peterver]

@goenning in regards to platform, I've used Lingohub in the past which is pretty ok. They've got a free tier for open source projects ( all the way down their pricing page ). Check it out if you have time :)

Lingohub

[goenning]

I need to read more about gettext, that's looks very interesting, thanks for sharing!

About the platform, I have used Crowdin before and liked it, but I'm open to other options. A lot of platforms actually seems to be very similar.

I was actually hoping that I could use just GitHub Pull Requests, but I guess that'll make translators life much harder, specially for those that are not familiar with git.

[peterver]

@goenning Lingohub has an api that you could use to automate a lot of this in regards to build/deployment process https://lingohub.com/documentation/developers/api-v1/

[Amoenus]

I like https://www.transifex.com/ (has a fairly active community) and https://poeditor.com/ as translation platforms. I will be able to provide translations in Latvian and Russian when you'll settle on a platform to use.

[balbuzar]

This could be an idea : https://github.com/nicksnyder/go-i18n It's easier to use than poedit / gettext (I can help for french translation)

[matbrgz]

Fluent could be a better way https://projectfluent.org/

Help in pt-br translate.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Aikatsui]

Ping @goenning

Crowdin Pricing less spicy than lingohub pricing, transifex pricing and no bad according to my experience or you can try cheap https://poeditor.com/pricing/

[francispeixoto]

I can offer help in french. Quebec has very strict laws concerning the use of the french language in the workplace, so providing this language would open up a very large market in the tech sector.

[perzeuss]

Questions:

1. Which languages to start with? I (@goenning) can translate it to English and Brazilian Portuguese
2. How can we support RTL languages? Is it hard?
3. Which platform to use? GitHub? Crowdin? What other?
4. Which format to store the strings? JSON?
5. How do we introduce breaking changes to existing strings? Say we have: { key: "NOT_FOUND_MESSAGE", value: "The page is not found." } and this has been translated to every language. What if we change text to This page does not exist.? How do "deprecate other" strings that have already been translated.
6. Any Go+React package that can help us on this? It doesn't seem to be hard to implement, but other packages might give us some inspiration.
7. Do we need different validation per language? E.g.: Latin alphabet we should validate that titles must have at least 10 chars. But on Chinese/Japanese, maybe 2 or 3 is enough. (ref: #614)

If anyone has experience with a multilingual platform, please share your thoughts and suggestions!

1. I think this is the wrong question. Languages come by contribution, there is no need to wait for a specific language to be supported. When fider can support localization via language files, it can support every language. However, I'd contribute the whole translation to german.
2. Almost every localization lib supports RTL out of the box, so It's not hard to implement them. Also I don't see any reason why the fider UI cannot handle RTL support.
3. I can recommend https://poeditor.com it's free for open source projects. Benefit here is, that https://poeditor.com can export the translations in the github repo, so there is no need to manual commit changes. However, I'd recommend to support custom languages by scanning a directory for localization files and validation rules which can be created post release. Also the platform supports plural (via additional term) and gender specific translations (via context)
4. JSON is completely sufficient, however https://poeditor.com can export the translated text into almost every common file type
5. Most of the crowd-translate platforms allow you to mark strings to signalize that they need to be re-translated or that the translation is not good enough
6. I can recommend https://www.i18next.com/ which has a great community and a library for react. For Go I've found https://github.com/nimbusec-oss/go-i18n but I dont think it's hard to write package to parse these localization files. In case we want to use https://github.com/nicksnyder/go-i18n we can write a small util to convert the https://poeditor.com export to the required format. That could also be done via github actions, but I'd recommend using https://www.i18next.com/
7. This is a problem, when you hard code validation rules. I'd try to make validation rules configurable by UI. As an alternative I suggest, is a folder with regexp per language which would allow contribution to this validation rules per language without knowledge of go/react

@goenning The missing localization support makes fider unusable for me. Currently we're thinking about developing our own solution. I'm willing to contribute to this project, but it seems that you are no longer maintaining this repo..

[gonimar]

Ping @goenning

Crowdin Pricing less spicy than lingohub pricing, transifex pricing and no bad according to my experience or you can try cheap https://poeditor.com/pricing/

How about https://crowdin.com/pricing#open-source-plans

We support the open source community. If you're building awesome non-profit projects that could use the power of Crowdin, we're happy to help with this free option. Make your content multilingual to reach a global audience.

[Aikatsui]

@goenning another suggestion, weblate free for libre projects** or possible to self-host and many projects use it

2. The user submitted content WILL NOT be translated;

https://github.com/getfider/fider/issues/859 suitable for it or https://libretranslate.com/ https://github.com/uav4geo/LibreTranslate Free and Open Source Machine Translation API.

[PeterTakahashi]

How about adding react-i18next and making it into another language like this source code? https://github.com/getfider/fider/pull/950

[sayuri-gi]

@goenning can you add sinhala (si) language?

[goenning]

I decided to go with Crowdin as they are free for open source and had the best translator experience + placeholder/tags validation and QA process.

All the languages are available at https://crowdin.com/project/fider/settings#translations and I'm hoping to merge the initial translations for Portuguese and French this week or the next.

@sayuri-gi also added Sinhala :+1:

[goenning]

Last PR was merged. So if you’re interested on using Fider in another language, please help us translate it on https://crowdin.com/project/fider

Thanks

[mipapo]

@goenning Just a question regarding the german translation. Do you want the "du" ("you") in german (so more personal) or "sie" so more "appreciation and respect". I would vote for a "du" (you)

[goenning]

@mipapo I don’t have a preference, go with what you think it’s best. For what it’s worth, Discourse seems to use Du a lot more than Sie

https://github.com/discourse/discourse/blob/main/config/locales/client.de.yml

[mipapo]

@goenning Awesome - already started - I will do some mor translations today/tomorrow

[perzeuss]

@goenning Just a question regarding the german translation. Do you want the "du" ("you") in german (so more personal) or "sie" so more "appreciation and respect". I would vote for a "du" (you)

It's common to have two languages for that: German (Du) and German (Sie). Which one you prefer depends on your audience.