How Chromium Stores Localized Strings in GRD and XTB Files

This article provides an overview of how the Chromium web browser manages localization using GRD (Google Resource Descriptor) and XTB (XML Translation Bundle) files. It details how developers define base English UI strings in GRD files, how the build system generates unique hash identifiers for these strings, and how translated strings are stored and mapped within XTB files to produce a localized browser interface.

Defining Source Strings in GRD Files

In the Chromium source repository, all base user interface strings (written in American English) are stored in .grd files and their modular sub-files, .grdp (GRD Parts). These are XML files processed by a build tool called GRIT (Google Resource and Internationalization Tool).

Each UI string is defined within a <message> tag inside the GRD file. A typical string entry contains the following components:

  • name: The symbolic constant used by developers to reference the string in C++, Java, or TypeScript code (typically prefixed with IDS_).
  • desc: A description providing context for translators (e.g., whether a word is a verb or a noun).
  • meaning: An optional attribute used to differentiate identical English strings that may translate differently depending on context.
  • Content: The actual English text, which may include <ph> (placeholder) tags for dynamic variables.

Here is an example of how a string is stored in a .grd file:

<message name="IDS_DOWNLOAD_STATUS" desc="Status text showing download progress">
  Downloading <ph name="FILE_NAME">$1<ex>installer.exe</ex></ph>...
</message>

Inside the <ph> tag, $1 represents the runtime variable, and the <ex> tag provides an example for the translator so they understand what replaces the variable.

Bridging GRD and XTB via String Hashing

Chromium does not use the name attribute (like IDS_DOWNLOAD_STATUS) to link source strings to their translations. Instead, GRIT calculates a 64-bit fingerprint hash based on the exact English string text and the optional meaning attribute.

Before hashing, whitespace is stripped and placeholders are normalized (replaced solely by their name attribute). This ensures that if two different features in Chromium use the exact same English sentence with the same meaning, they generate the exact same hash ID and only need to be translated once. Conversely, if a developer changes a single letter in the English string, the hash changes, automatically invalidating old translations and flagging the string as new for translators.

Storing Translations in XTB Files

Once strings are translated via Google's internal translation pipeline, the results are exported back into the Chromium repository as .xtb files. There is one XTB file per locale for a given GRD file (e.g., generated_resources_es.xtb for Spanish).

XTB files are strictly structured XML files that map the 64-bit hash ID to the translated text. They do not contain the IDS_ constant names, translator descriptions, or placeholder examples.

Here is how the previous GRD example is stored in a Spanish .xtb file:

<?xml version="1.0" ?>
<!DOCTYPE translationbundle>
<translationbundle lang="es">
  <translation id="7483920192837465123">Descargando <ph name="FILE_NAME"/>...</translation>
</translationbundle>

Notice that the <ph> tag in the XTB file is self-closing and only retains the name attribute. During compilation, GRIT matches the FILE_NAME placeholder in the XTB file back to the $1 variable defined in the GRD file.

Compiling Strings at Build Time

During the Chromium build process, GRIT reads the .grd file and looks up the corresponding .xtb files for all supported locales. It performs the following actions:

  1. Generates a C++ header file (e.g., grit/generated_resources.h) that assigns a sequential numeric ID to the IDS_DOWNLOAD_STATUS constant for use in the source code.
  2. Calculates the hash of the English string in the .grd file.
  3. Finds the matching <translation id="..."> in the .xtb file.
  4. Substitutes the <ph> tags in the translation with the actual formatting parameters (like $1) from the .grd file.
  5. Outputs binary .pak (data pack) files for each locale (e.g., es.pak), which the browser loads at runtime to display the correct language.