When you introduce a new UI string or modify an existing one that will be displayed to the users, or remove a string that is localized, follow these steps so that it can be localized.
Table of Contents
Before proceeding, make sure you know the different [[localization APIs|]] and know which one you should use.
Wrap your string with the appropriate localization API for your use case, for example, ls`Add breakpoint`
.
If your string contains variables, consider the following cases:
Directly substitute variables, as how you would normally inject variables into a template literal with ${}
, only if your variable satisfies one of the following
If the variable is a number, e.g. ls`${renderedWidth} \xd7 ${renderedHeight} pixels`
or if your variable is a string that likely doesn't need to be localized (for example, DOM, or a url),
or if it's a string that is already localized somewhere (for example, Console and other tool titles)
Localize your variable with ls
, then do variable substitution in your template literal, for example
const title = ls`New Tool` const message = ls`Click ${title} for more details`
Make sure your string is localizable:
Do not assume word order by using concatenation. Use the whole string.
ls`Add` + ls`breakpoint`
--> ✅ ls`Add breakpoint`
Variable substitution over concatenation. This is so that the translators can adjust variable order based on what works in another language. For example:
// ❌ ls`Check ` + title + ls` for more information.` // ✅ ls`Check ${title} for more information.`
Only inject variables when necessary, i.e., do not extract common substrings from similar messages.
Prefer simple strings whenever possible. Try to move conditionals out of the string. For example:
// ❌ ls`Reveal${destination ? ls` in ${destination}` : ``}` // ✅ destination ? ls`Reveal in ${destination}` : ls`Reveal`
When your string contains plurals, make sure you pluralize by pulling conditionals outside of the string. This is because in other languages, plurals can be different from English ones. For example:
// ❌ ls`${count} insertion${count !== 1 ? `s` : ``}` // ✅ if (count === 0) ls`No insertion` else if (count === 1) ls`1 insertion` else ls`${count} insertions`
In general, a complete sentence is preferred. This usually increases the localizability of a string, as the translators have the context of the string. For example:
// ❌ let description = ls`first part` if (condition) description += ls` second part` // ✅ let description if (condition) description = ls`first part second part` else description = ls`first part`
If your string contains leading or trailing white space, it‘s usually an indication that it’s half of a sentence. This decreases localizability as it‘s essentially concatenating. Modify it so that it doesn’t contain leading or trailing white space anymore if you can.
Do not use nested template literals. This is due to a limitation of the release minifier. For more info see https://crbug.com/973285.
// ❌ UI.Fragment.build`<a>${ls`Learn more`}</a>` // ✅ const link = ls`Learn more` UI.Fragment.build`<a>${link}</a>`
What kinds of terms should be localized?
// ❌ Numbers: 1, 1.23, 1.2e3, etc. Application data: error codes, enums, database names, rgba, urls, etc. // ✅ Words and sentences Punctuation Units of measurement: kb/s, mph, etc.
git cl presubmit --upload
, ornode scripts/check_localizable_resources.js --autofix
under the devtools folderFollow the above steps.
Just remove the string from the frontend and it will be automatically removed by the presubmit script.
This is a rare case, but if a new GRD file is introduced, please read the guidance here: