Planning issue for translation/internationalization/localization systems

[jywarren]

We have some basic internationalization/localization via the i18n gem, but need to think through how to improve it, and ALSO come up with a streamlined workflow to recruit and integrate new translations on an ongoing basis. This is a planning issue for this set of projects.

---

Translation systems

Our translation files are spread over lots of files and folders in https://github.com/publiclab/plots2/tree/master/config/locales

I'm inclined to make them all one big file, or at least consolidate them some. One folder with key/value would be SO AWESOME! I wasn't sure why our implementation fragmented everything across so many folders. I think we could do this in Transifex.

Discussion of alternative platforms via @ebarry :

• LocalApp: https://www.localeapp.com/projects/9741/translations/5689967
• https://crowdin.com/ (github integration)
• https://poeditor.com/ (github integration)

Ongoing translation workflow

We need a workflow to regularly go from Transifex (or something similar) back into the translation files.

Transifex has GitHub integration: https://docs.transifex.com/integrations/github/ and awesome ability to auto-sync in TravisCI: https://docs.transifex.com/integrations/github/#integrating-the-client-with-travis-ci

This would grab new translations each time we accepted a pull request, and register new texts that need translation!

Outreach

For actually doing the translations, I'm hesitant to make a huge # of translation issues in the same repository, even if they are first-timer type issues. I think we could maybe get more contributors to translate outside the GitHub interface (which is most welcoming to coders).

I think we'll need a good outreach game to actually recruit people to do translations! Maybe, we could tweet them out? We could show a random phrase at the bottom of the site each time the site is loaded, that needs translation?

---

If we happen to find alternatives (especially open source ones) that's great, but we can stick with Transifex if there's no big reason to switch.

The ideal might be that with fewer files, we could copy in new changes from either another service like Transifex periodically (monthly?), or from files in another repository (although this doesn't make it more accessible by going outside the GitHub interface)

We might even try to automate the import and run it periodically. But it could be a regular task manually too.

Translation prompts

Anywhere we display translated text using the t('some_string_here') helper, we ought to display a little globe icon with a tooltip saying Needs translation? Click to help translate this text. or something (ideally in the browser-configured language!)

Translating content

We'll need to think about how to translate both regular site content (wiki pages + notes) and ALSO features, which are used around the site for things like the static footer, explanatory text, etc.

Perhaps there should be a language type on revisions, and we could make it possible to track translated revisions alongside regular ones. Or perhaps a translated node, linked to the main node?

Compare https://publiclab.org/barnraising to https://publiclab.org/wiki/barnraising-guangzhou-china for an example of 2 versions of a page in 2 languages.

Features

Some parts of site content -- like the footer and front page -- are run in nodes, as database content. Let's think of a way to have features like frontpage-en vs frontpage-zh and frontpage-es

Helpers for translation

@siaw23 points out, and I agree, that translation is tough for newcomers submitting new code. The current format is something like:

<%= t('some_string_here') %>

...where some_string_here is the key to some string of text.

I propose a new helper, maybe called translate(), which looks for translations, but if none are present, displays the key text itself. That way, we can create new interfaces that include text, without first having to do translation for them -- they'll have the fallback text. So:

<%= translate('Click here to begin') %>

which initially would have only the default english, but via the prompts (above) would encourage community translation efforts.

Scanning for translation opportunities

Finally, we might have a script which scans for uses of the new helper (from above) that don't have entries in the default translation file, and copies them in.

---

This is a lot. Just kicking off some discussion and we can start to move things into separate issues soon! Love to hear peoples' input!

[jywarren]

I've broken out the "move translations" issue into a multiple-use issue good for newcomers! #3515

[grvsachdeva]

Hi @jywarren @ebarry , I went through the details of the project and done some research at my end.

I saw that Transifex is being considered right now for integration, but that was paid. There are two more methods which I am considering:
1. Using Copycopter gem
In this, the web interface would be hosted as a separate application and can be hosted via Heroku too as it only requires one dyno to run.

Although, the project is Abandoned some time back but, it can do our work. For details, check here - https://github.com/copycopter/copycopter-server

2. i18n backend
It is one of the solutions which offers control of the system in our hand. Please check details here- http://railscasts.com/episodes/256-i18n-backends?autoplay=true

I prefer the second option as with that we wouldn't have to depend on other services and also can use the interface of our preference. Let me know if you like any of the above methods or Transifex is final choice.

Thanks!

[jywarren]

In the second option, what backend would we use? Not flat yml files? How would people edit them then? Is it possible to use Transifex or another management system to organize the crowdsourcing of translations, so we could kind of quickly get people plugged int translating short strings? Thanks Gaurav!

…

On Tue, Jan 8, 2019 at 12:06 PM Gaurav Sachdeva ***@***.***> wrote: Hi @jywarren <https://github.com/jywarren> @ebarry <https://github.com/ebarry> , I went through the details of the project and done some research at my end. I saw that Transifex is being considered right now for integration, but what I that was paid. There are two more methods which I am considering: *1. Using Copycopter gem* In this, the web interface would be hosted as a separate application and can be hosted via Heroku too as it only requires one dyno to run. Although, the project is Abandoned some time back but, it can do our work. For details, check here - https://github.com/copycopter/copycopter-server *2. i18n backend* It is one of the solutions which offers control of the system in our hand. Please check details here- http://railscasts.com/episodes/256-i18n-backends?autoplay=true I prefer the second option as with that we wouldn't have to depend on other services and also can use the interface of our preference. Thanks! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3262 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABfJxCFjiXi--yuxth72FonC-0JWW7Nks5vBM_1gaJpZM4WOefY> .

[grvsachdeva]

@jywarren

In the second option, what backend would we use? Not flat yml files? How
would people edit them then?

In this option, translations can be stored in Redis as a key-value pair. We can use yml files just to provide fallback translation, so we can only have en.yml and others stored in DB. People would be interacting with DB only, just like editing/adding a comment.

Is it possible to use Transifex or another management system to organize
the crowdsourcing of translations, so we could kind of quickly get people
plugged int translating short strings?

I think, Transifex provides translation services too, but again that services would be paid on top of paid Transifex subscription.

I highly recommed watching this http://railscasts.com/episodes/256-i18n-backends?autoplay=true episode for clarity of second method. It's related to our need.

Thanks!