The project has translations for many languages. This covers all the details of that process for people.

For a general overview of localizing code, see the Chrome i18n documentation. We won't cover general Chrome/web platform logic here.

For Googlers, see the Translation Console Overview.


The nassh & hterm code use localize & hterm.msg to lookup messages.

The en/messages.json file contains all the original messages. We maintain this file directly in this repository.

The en/messages.json file is periodically & automatically copied to internal Google systems (using copybara) into the hterm_messages directory. CLs will be generated that developers have to manually approve, but everything else is automatic.

It is periodically & automatically imported into the Translation Console by converting the messages.json format to XMB (XML Message Bundle) under the transconsole/xtb tree (see en.xmb). Then it is automatically flagged for translation updates. Developers do not need to trigger this flow.

Translations are periodically & automatically exported internally using the XTB (XML Translation Bundle) format under the transconsole/xtb tree. Developers do not need to trigger this flow.

Finally, the XTB files are converted back into messages.json before being merged back into this repository. This step is currently run manually by Google developers, although see the Automatic Updates section below for more info.

Sometimes, usually when new messages are added, translators will ask for clarification and file localization queries. The Google l10n team will triage & assign to Googlers as needed. Googlers will then address feedback & update the en/messages.json or answer their questions directly as makes sense.

Translating HTML

When writing HTML pages, use the i18n attribute on elements, and then lib.MessageManager.processI18nAttribute API will take care of inserting the right translations at runtime.

Updating Translations

  • Check on the current status of translations by looking at tc/nassh.
  • Go into //security/nassh/translations/.
  • Make sure the locale list in BUILD is up to date.
  • Run blaze build msg_roundtrip_test to verify the entire cycle.
  • In the root of the client, the new messages.json files will be under blaze-bin/security/nassh/translations/messages_fs/_locales/.
  • Use the import-translations to import: .../nassh/bin/import-translations .../google3/blaze-bin/security/nassh/translations/messages_fs/_locales/
  • Upload & land the CL in our git repository.

See the TC page for more details.

Automatic Updates

Our official build/release pipeline will automatically dump the latest translations and integrate them into the releases. Unfortunately, this means the official releases will always be up-to-date, but not the open source code or releases. This impacts our integration into CrOS with the crosh and Terminal projects. So periodic manual exports are still required.


Do I have to translate messages myself?

Nope, we don't write any of the translations ourselves. We only maintain the en/messages.json source messages. Everything is handled for developers.

How do I fix a translation?

We accept bug reports for bad translations, but we don‘t accept changes from contributors as they’ll be automatically overwritten.

So feel free to file bugs for us, and we'll take care of sending that feedback to our translators for fixing things.

For Googlers, at this point the process is:

  • Go to the project's messages list.
  • Find the string that needs fixing.
    • Click the message id to open the message-specific page.
  • Find the language that needs updating.
    • Click the language name to open the language-specific page.
  • Find the “Make a suggestion” link at the bottom.
  • Fill out the form details and submit it.
    • Include the original report (bug or forums) if available.