Using Crowdin

[obensource]

Purpose

Our group needs to be brought up to speed on what's been discussed with @Andrulko and our WG members who were present at our meeting with Crowdin on 02/26/18.

WG members: Please provide any thoughts or feedback you have here concerning using Crowdin and we'll get things rolling. 🙌

Meeting Recap

i18n WG members in attendance

• @zeke
• @vanessayuenn
• @sotayamashita
• @obensource

@Andrulko gave us a setup overview, and demoed Crowdin's repo integration & l10n features.

Crowdin Integration Features

• Syncing a repo with Crowdin via their Github integration process
• Syncing and managing l10n project resources directly with the Crowdin CLI interface

Crowdin l10n Features

• In-context translation for web apps
  • Translation can be done by selecting an app's text in the UI, and live translating it directly.
• Proofreading & voting of translations
  • Translations can be proofread and/or voted on by project peers before being approved.

Electron use cases we can learn from

• API translation: The Electron i18n repo pulls markdown files in from their API docs for translation.
• A crowdin.yaml file is maintained to map source files to their translation location.
• Crowdin uses a yaml file as well to map to the source and target resources it needs to manage. In theory you should be able to manage that with git, however at this point in time it must be generated and added within a Crowdin project itself.
• l10n project resources live under a directory labeled by their associated ISO standard locale code.

Upstream vs. downstream bottleneck

One important discussion we began to consider was the tradeoff between having to accept translations as PRs for verification–or hopefully keeping that responsibility effectively downstream by requesting that translators maintain at least one peer verification for every translation to be published. This should be painless in Crowdin by ensuring translators follow their 'edit & proofreading' model.

The security tradeoff in the codebase comes with a trust that the translations will be fine, and we can simply merge them as they come in–bypassing the GH PR process entirely.

[Andrulko]

Awesome! I kept March 6th in my mind, can't wait when we'll start the integration together shortly 🎉 If necessary, as promised, we can do another quick session to setup CLI together

[obensource]

@zeke I also had these notes about some of the setup you've done to communicate changes between Crowdin / electron/i18n / website, but though I think I know what they mean–I can't recall their full context now. Maybe you could further explain them (I hope they're enough to reference for you)?

 - poll us and resume translation to accept changes
 - yaml file on the electron website, polls

Also feel free to elaborate on and correct any of the notes above. Thanks! 😎

[RichardLitt]

Would be a good idea to add in safeguards now in case there are infractions. I would propose a three-strike action for larger issues (minor, good-faith poor translations just plain happen). After that, we should stop using that specific translator. It would be up to both this group and the localization group to formally censure for each strike.

This way, we all know what is going to happen if there are issues, so we don't have to spend a lot of time worrying about it.

[obensource]

@RichardLitt I agree that we should approach this up front so we can help safeguard the translation process and avoid being 'caught off guard'. Is there a precedent for the three-strike action anywhere? It seems fair, but I'm relatively new to open source mediation and am genuinely curious. This is definitely a unique context for it. :)

[obensource]

@RichardLitt this will also be absolutely crucial if/when we decide to 'open the translation floodgates' and continuously integrate Crowdin updates into our i18n module directly.

[Andrulko]

In Crowdin, any translator can report abusive translation: http://recordit.co/iCwXSyvIKT

As a project manager, you can view all abuse reports via the project settings... Reports tab. You can make final decision whether the person should be blocked and/or existing translations removed

Hope you'll find it useful :)

[obensource]

@zeke nice labeling! Rad! :D

[zeke]

Gonna go ahead and close this as we're well on our way. If there are unaddressed topics in this issue, feel free to open more specific followup issues.