the Chromium logo

The Chromium Projects

Add & translate strings (aka 'Localization' or 'Translations')

Help improve our translations:


Chromium uses GRIT for managing its translated strings in grd/grdp files.

Base messages are written in U.S. English (en-US) and are translated into supported language locales by an internal Google Localization process. Translations are submitted to the chromium .xtb files after a few weeks.

Strings are included on all platforms by default and will needlessly increase the download size if they're not used. It's important to judiciously surround strings with appropriate <if> clauses to ensure that they are only included on the platforms where they're actually used.

How strings get translated

  1. Strings get added to a .grd(p) file in en-US.
  2. [BlackCloudOfMagic] Translators are provided with the new strings.
  3. <Googler-only link> Further internal detail about the translation process here. </Googler-only link>
  4. [BlackCloudOfMagic] Translations are created and stored in .xtb files
  5. Changes to .xtb files are submitted to the Chromium source tree

Add a string

If you're developing for Mac, also see notes on how to add strings for Chrome on Mac.

  1. Check whether the string you need already exists. If you find a matching string, read the description to see how it's intended to be used, and leverage it if you can. Otherwise, continue.

  2. Add the string to the grd file (generated_resources.grd, webkit_strings.grd, chromium_strings.grd or google_chrome_strings.grd).

  3. Include screenshots, meanings, and descriptions for all strings. This is crucial for high-quality translations.

  4. Use ICU message syntax to accommodate plurals and gender.

  5. As needed, surround the string with an appropriate <if> clause to ensure that it's only included it on platforms where it's actually used (e.g., Mac and Linux); this avoids needlessly increasing the download size. Strings used on all platforms can omit the <if> clause.

  6. The next time you build the solution, this will automatically add the en-US string.

  7. In your code, include ui/base/l10n/l10n_util.h and chrome/grit/generated_resources.h.

  8. To get the string, use l10n_util::GetStringUTF16. Alternately, you can use l10n_util::GetStringFUTF16 which will replace placeholders $1 through $4 with the extra arguments of GetStringFUTF16. Note that we generally prefer to use UTF-16 encoded strings for user-visible text.

  9. Deal with message placeholder content. Example:

    Hey <ph name="USER">%1$s<ex></ex></ph>, you have <ph name="NUMBER"><ex>10</ex>$2</ph> messages.
    

Add an Android/Java string

  1. Check whether the string you need already exists. If you find a matching string, read the description to see how it's intended to be used, and leverage it if you can. Otherwise, continue.

  2. Add the string to the grd file in the Java folder (e.g. content/public/android/java/strings/android_content_strings.grd). Strings should be named in all caps with the prefix IDS_. For example: IDS_MY_STRING.

  3. Include screenshots, meanings, and descriptions for all strings. This is crucial for high-quality translations.

  4. At build time, an Android-style strings.xml file will be generated in the out directory.

  5. You can reference these strings in Java code using the standard R.string.my_string syntax, or in Android layouts using @string/my_string. Note: the name is lowercase and the IDS_ prefix is stripped.

  6. Deal with special characters.

  7. Deal with message placeholder content. Example:

    Hey <ph name="USER">%1$s<ex></ex></ph>, you have <ph name="NUMBER"><ex>10</ex>$2</ph> messages.
    

Add a new grd(p) file

This should be rare. We want to be very careful about expanding the number of grd(p) files in our source tree.

General notes:

Notes for translation:


Give context to translators

Add a screenshot

Screenshots of Chrome's UI strings can provide more and clearer context for our translators. Requests for screenshots make up at least 5% of localization bugs.

Follow the steps at https://g.co/chrome/translation to add a screenshot to correspond with your strings.

Use message meanings to disambiguate strings

When? Existing translations are reused when a new message matches an existing one. We rely heavily on reused translations to keep our localization costs manageable. If your string has a specific need to be treated differently than existing strings with identical text (because of a unique context or new restrictions like length or capitalization), add a meaning attribute. Messages with different meaning attributes will be translated separately. Adding a meaning to an existing string will trigger a retranslation.

The meaning attribute may specify a need for disambiguation, due to:

How? In the example below, we want to apply specific capitalization rules, so we can't reuse the existing translation. We added a meaning to the string so that the automated Translation Console tool disambiguates this string. The meaning's details will help future Chromium contributors understand the difference among identical strings; however, the translators will not see the meaning attribute:

<message name="IDS_BOOKMARK_BUBBLE_PAGE_BOOKMARKED"
  meaning="In Title Case for Apple OS"
  desc="In Title Case: Title of the bubble after bookmarking a page.">
  Bookmark Added!
</message>

Write good descriptions

Why? The message description is a critical piece of context our translators receive when translating UI strings. Translators see each string in isolation and in a random order: they don't know which feature the string is associated with, where it might appear on a page, or what action it triggers. Adding enough context to each string in a project increases the speed, accuracy, and quality of translations, which ultimately improves user satisfaction. For example, of the following code:

<message name="IDS_BOOKMARK_BUBBLE_PAGE_BOOKMARKED"
  desc="In Title Case: Title of the bubble after bookmarking a page.">
  Bookmark Added!
</message>

the translator would only see:

How? Add as much of the info below in the message description as would be useful:

Keep in mind that the translators will not know the product as well as you do, and they work on multiple products and projects. Also, they're not engineers. So make sure that the description will be understandable by a more general audience and doesn't contain too much technical detail. Imagine giving this description out of context to a person who isn't on your project, like your cousin. Would they still understand it?

Note: changing a message description without changing the message itself or adding a meaning attribute does not trigger a retranslation of a string.

Examples of good message descriptions:

Examples of poor message descriptions: