Localize Flarum via Crowdin (GitHub integration empowered i18n)

Andrulko

Hi everyone,

This is Andriy from Crowdin, a localization management platform.

I've stumbled upon the i18n tutorial below:
https://flarum.org/docs/extend/i18n.html#how-flarum-translates

The one should have quite good development skills, even volunteer who simply wishes to help with localization. You should know YAML / JSON syntax and single mistake can break whole file...

After reading tutorial, I've decided to prepare a basic demo project to illustrate how Crowdin can handle community translations 😀 Steps were the following:

1) The repo lang-english was forked to my GitHub account: https://github.com/Andrulko/lang-english
2) The demo project was created in Crowdin: https://crowdin.com/project/flarum-demo-project
3) Using GitHub integration, repository along with all branches was connected. The following configuration was defined: crowdin.yml
4) Existing Ukrainian translations were imported to the project.

That's it, community can start working on translations. Crowdin will automatically open a PR in GitHub with the latest translations: https://github.com/Andrulko/lang-english/pulls

Translators don't need to know YAML or JSON syntax. They will type simple texts and system will automatically surround certain translations with double quotes or escape special characters. No problems working with plural forms too. ICU syntax is natively supported (with nice preview), so you can translate plurals/genders easy:
https://support.crowdin.com/icu-message-syntax/

Any changes made for English files on GitHub will be automatically synchronized with Crowdin, so translators will get notifications about new strings within app/email/Slack.

You are welcome to submit any translations for the project to see how it works live!

At the same time, there is something about files hierarchy and I'm not sure how to solve it. At the moment, integration creates translated files with .fr.yml / .uk.yml endings. Will that that work for Flarum? Please see below:
Andrulko/lang-english1/commits/3b24663e954c0eeedc6ad4e12ecda587a503d51b

It is also worth mentioning that Crowdin is free for OSS and doesn't have any limitations on this plan. We strive to make localization as easy as possible for everyone, so truly hope the idea above sounds good! I'll be happy to offer any further assistance with setup and answer any questions in this topic!

tankerkiller125

Andrulko I believe that Flarum has already setup a testing group for a translation service (don't know if it's Crowdin or one of the other group translations services) It's currently not a public group though, if you browse around the forums you'll see that several of our users have a translator group tag, these users are in that translation test group.

Andrulko

tankerkiller125 Thanks a lot for the information! I will try contacting them as well. Probably, we can continue discussion in the topic or I'll re-create it under testing group (if I get an invite 😃)

tankerkiller125

Andrulko @luceos I believe is currently in charge of that project, I could be wrong though

matteocontrini

It's Lokalise: https://discuss.flarum.org/d/21360-dev-diary-beta-11/30

And there's also a similar project for Weblate: https://discuss.flarum.org/d/20807-simplify-translation-process-with-weblate

luceos

We're in the process of supporting translations officially. This is quite a responsibility for the core team to carry, as such it hasn't yet been published nor fully activated due to the lack of human coordination (we're opening up a vacancy for that shortly).

The stack we're using is one repository that reads lang-english and any registered extension repository to disk, then pushes all english language files to lokalise. Translators can use Lokalise to translate Flarum and any extension. These changes are automatically read, stored to this repository and subsplit into their own locale specific core and extension language packs. All of this is automated using GitHub actions and Lokalise. The project can be found on GitHub: https://github.com/flarum-lang/translations, all translation packs are part of the same namespace: https://github.com/flarum-lang

Andrulko

Hey @luceos, thanks a lot for all the info! Apologies, I wasn't aware that you've started an official i18n effort. Congrats!

Anyway, please remember about Crowdin ✌ We're ready to support any other projects of yours and will assist on each setup stage.

Wishing you a smooth localization start,

luceos

Andrulko I am against vendor lock in and if we see good reason to move to an alternative, we now have at least one to consider 👍️

Thanks for reaching out to use by the way, that's a great way of showing you care for open source.

Andrulko

luceos That's great to hear! Just in case, I have forked the actual repository with languages and connected it with the same demo project:
https://crowdin.com/project/flarum-demo-project

Existing translations were also automatically imported. At least now you have a way to compare UX and sync logic 🙂

Let's stay connected, if anything - just ping me please 👍

rob006

luceos I am against vendor lock in

So why did you choose Lokalise? As far as I can see, this is proprietary, closed-source and paid service - pretty good candidate for vendor lock in.

[deleted]

rob006

Is there a free plan?
Yes. Free plan includes up to 500 hosted keys (strings). Translation history, API or mobile SDK are only available on paid plans.

luceos

rob006 where the translation keys are translated doesn't really matter now, we simply sync with it. We can start syncing with any other tool would there be a need.

Lokalise has put us on a free paid plan by the way.

rob006

[deleted] This is not enough even for core + official extensions (over 600 string), not mention community extensions (over 1500 strings).

rob006

luceos The current solution seems to be pretty coupled with localise. And since you don't store translations authorship in the repository, changing translation service will mean losing contributions statistics (unless there is an API for that and you will be able to import them to new service).

Andrulko

@rob006 True, YAML files cannot store such data as authorship, unfortunately. Translations import when you connect GitHub repo works automatically though, thus translations which existed in translations repository were imported to the project:
https://crowdin.com/project/flarum-demo-project

This question is usually resolved by exporting statistics from TMS and publishing it on a separate page of website, also you can create CONTRIBUTORS.md in GitHub repository where statistics will be published. To make it easier & automated, Crowdin has API for that:
https://support.crowdin.com/api/export-top-members-report/
https://support.crowdin.com/api/download-top-members-report/
https://support.crowdin.com/api/v2/#operation/api.projects.reports.post (API v2)
https://support.crowdin.com/api/v2/#operation/api.projects.reports.download.get (API v2)

It should definitely encourage volunteers to be more active + you can run weekly/monthly competitions like "Translator of the Week", "Translator of the Month" etc.

Shortly, it will be possible for project managers to set goals for translators (e.g. "Translate 10,000 words to get Flarum mug", translate 5,000 words to get a badge in Forum) + in-Crowdin achievements will appear, so it might be a good addition to translators' CV 😉

I'm more than sure that reports generation is available in Localise too, hopefully you'll find my tips useful!

If anything, I'm monitoring the thread and will be happy to answer other questions.

rob006

Andrulko Weblate saves translator as commit author, so you can see who and when translated/changed particular line. So even if Weblate instance disappear, you still have a full authorship info in git repository. And you can unleash power of git blame 😛.

https://github.com/rob006-software/flarum-translations/blame/master/translations/fof/pl/fof-subscribed.json

Andrulko

I think it will require you to connect your GitHub account with Weblate (shouldn't it be Localise? 😀 ) before starting translation? Our connector works in a bit different way - for privacy & security reasons, all commits / PRs are generated from a name of GitHub account that was used for setting up the integration in Crowdin.

Also, Crowdin generates one commit per file per language (i.e. 2 files and 4 languages = 8 commits). For example:
Andrulko/translations1

It is still possible to determine who is the author of translation, but only within the platform 🙄

Potentially, it's something that might be added to the roadmap but we need to be sure that such approach will fit every team perfectly.

P.S. Just realized that you are hosting translation repository under your GitHub account, so that's expected to see Weblate 😊

rob006

Andrulko I think it will require you to connect your GitHub account with Weblate (shouldn't it be Localise? 😀 ) before starting translation?

It uses name and email from Weblate account for author field of commit. If you have the same email address connected with your GitHub account, GitHub will recognize these commits as yours and display them in your contributions graph.

But over all there is no direct integration with GitHub - Weblate uses native Git features, so this repo could be hosted anywhere.

Andrulko

rob006 Well, that's interesting approach. Thanks for sharing! Not sure if that will work for private projects and repositories but it's definitely helpful for public projects & contributions graph in GitHub. In Crowdin, all actions made for public projects will be listed under account's Activity feed. Like this one:
https://crowdin.com/profile/Andrulko/activity

matteocontrini

Andrulko it's just a git feature, when you create a commit you can pass a "custom" author for that commit. The only problem I can see is privacy, because users must be aware that their email might become public.

(actually, another thing to consider is that changes by different users cannot be grouped in a single commit if you want to preserve authorship)