Meta: Translation Project for IPFS GUIs

[lidel]

Current State

It's alive! https://github.com/ipfs/i18n

• Thank you all for help and smoke-testing the setup! ❤️
• Crowdsourcing translations from IPFS Community
• Everyone can join using github account!
• Missing language? Join and request it via Transifex
• I moved docs and reading material to a dedicated project at https://github.com/ipfs/i18n ✨
  • Feel free to improve it with best practices and resources useful for others

Dear future reader:

If you have trouble with i18n framework, translation site, locale format or want to add project to Transifex please fill an issue here.

---

(Original issue below)

Background

Click to expand

In the past it was a mixed bag: different services, missing locales, no common corpus/dictionary to support crowdsourcing efforts.

• WebUI
  • Old WebUI and the ipfs.io website: https://www.transifex.com/ipfs/public/
    • created by a community member, but @lidel now has admin rights as well
  • New WebU (translation in progress: feat: i18n ipfs-webui#772 done)
• Companion (i18n): https://crowdin.com/project/ipfs-companion
  • right now under @lidel's private account, needs to be migrated
    done: Add Transifex for Crowdsourcing Translations ipfs-companion#566
• Desktop has no translation set up yet
• Other things with translations
  • http://js.ipfs.io
  • In future CLI interfaces of go-ipfs and other shell tools could add support for $LC_ALL

Milestones

Manual

• all GUI apps support translation and ship with English as plain text locale files
  this is very important:
  • establishes convention and people can PR with new locales via github
  • enables us to experiment with different crowdsourcing websites in async mode

Semi-Automated

• translations can be provided via a crowdsourcing website: https://www.transifex.com/ipfs/public/
• there is a single crowdsourcing website that user can join to start translating
  • we have multilingual dictionary for core concepts and most commonly used phrases ([NEW CONTENT] [BOUNTY] Glossary ipfs-inactive/docs#56)
  • when everything is set up we can reach out to https://discuss.ipfs.io for help in translating everything in bulk
• maintainer is responsible for synchronizing between github and crowdsource website
  • push source locale (Engligh) a week before release and/or on big changes
  • fetch translations on release day
  • (this does not scale well if we have multiple projects)
• licensing is solved (Copyright Hygiene  community#331 (comment))

Full Automation

• there is some kind of automation that removes friction
  • synchronizes new source strings from github (master) to crowdsourcing site
    • done: Meta: Translation Project for IPFS GUIs #50 (comment)
  • synchronizes new translations from crowdsourcing site to github
    • eg. making a PR once a day or by commiting to locales branch on daily basis to make sync as easy as merge to master

References

Transifex

• Installing the Transifex Client
• Understanding .tx/config file
• Manual sync via Transifex Client
  • Using Transifex with GitHub in Your Development Workflow
    • Syncing a local project to Transifex with the Transifex Client
    • Integrating the Client with CI (Travis CI, but same will work with Jenkins)
• Sync automation
  • Option A: Automatically updating source files 👌 👌 (Meta: Translation Project for IPFS GUIs #50 (comment))

    Transifex will check [Github] URL for updates twice per day and if there are any changes to the file

  • Option B: set up Jenkins: Localizing with the Transifex Client
  • Option C: Setting up an instance of Txgh (third-party sync server between Transifex and GitHub)
• Neat features:
  • Translation Memory:

    Without going into too much technical detail, Translation Memory is a database of previously completed translations. Each time a translation is submitted, it's saved to this database. In the future, if a phrase similar to the original source string appears, the translation is presented to the translator as a suggestion. Let's look at an example.

  • Sharing Translation Memory across all projects (paid feature)
  • Crowdsourcing Mode (paid)
• Bonus: eye savers for night owls 🦉
  • Dark Theme for OLED
  • Geeko Dark Theme

---

Click to expand notes for CrowdIn (alternative to Transifex)

CrowdIn

• Manual sync via CLI Tool
  • Console Client (CLI)
• Bonus perk: Localization That Does Not Delay the Releases
• Configuration File: crowdin.yaml
• Sync automation
  • Option A: Set up Jenkins with the CLI Client
  • Option B: Native GitHub Integration:

    Crowdin’s integration with GitHub makes source and translation files synchronized with GitHub repository and Crowdin translation project. All translated and approved files will be automatically pushed as a pull request to the l10n branch in GitHub repository.

    We do not commit directly to master, so that you have a chance to verify translations and keep your app safe and sound. By default, l10n_ is added to the created service branch name. In case of necessity it can be easily changed.

    • Good: looks easier to set up than Transifex
    • Bad: requires granting write access to repositories (we already use things like Waffle, but still...)

[lidel]

• Added References section with some notes about CLI for two most popular crowdsourcing sites and supported ways of integrating with Github.
• Thanks to @digital-dreamer we got Admin ownership over IPFS org at Transifex :)

[lidel]

• At CrowdIn every project has its own team and you need to manually assign people as managers/translators to each project.

• That is why I am leaning towards using Transifex: it enables us to have all apps under a single IPFS org (https://www.transifex.com/ipfs/public/) and one team of translators. We can share translation memory and glossary across all projects, and when a new one is added it gets the translation history for free.

[lidel]

Reposting some notes on i18next-react vs react-intl from ipfs/ipfs-webui#772 (review):

I was unable to find native support for i18next-react's translation format at Transifex (which I am leaning towards, here is why). People were successful with using Transifex+i18next-gettext-converter which has a support for plurals for most of languages, but there are edge cases with known issues which may produce frustrating bugs. I feel we could try to blackbox the sync by creating 1 shell script that takes care of conversion and runs at jenkins + is run manually before release, but this need for additional layer of indirection if a sort-of a warning flag.
Update: i18next supports ICU after all!

The alternative, react-intl is a part of FormatJS which is aligned with ECMAScript Internationalization API (ECMA-402), Unicode CLDR, and ICU Message syntax. ICU does not require additional conversion step and is supported out of the box by Transifex and other crowdsourcing websites. It kinda feels more future-proof, when looked at from that angle [..]

If anyone has any prior experience with either of them, feedback with pros/cons would be appreciated!

[olizilla]

Of note, i just saw https://github.com/lingui/js-lingui which may be the best of both react-intl and i18next in terms of dev experience and translation support... It uses ICU message format like react-intl under the hood, but provides a nicer high-level api for creating them. I'm wary of posting links to twitter popularity contests, but this https://twitter.com/kentcdodds/status/1036084711678861312 at surfaced that react-intl and i18next are popular now, and lingui is interesting.

[hacdias]

Also about react-intl: formatjs/formatjs#1160