Translate

Translate Stylebot

Stylebot's UI strings live in src/assets/_locales/<locale>.config, one file per locale; en.config is the source. CI's yarn validate-locales fails while any string English has is missing from another locale, so every string needs every locale. This skill is how they get filled in.

The file format

#==== Section ====

# Theme name in the reader's theme picker.
@light_theme
Light

@restore_add_back_site
Add back $site$

• @key on its own line, the text on the next line(s), a blank line between entries. Keep keys in the same order as en.config, under the same section headers.
• # lines are comments, stripped by the build. A # line directly above a key in en.config is a note for translators: read it, and add one when you add a string whose meaning isn't obvious from its words.
• The text can't contain @ — the parser starts a new string at every @.
• $NAME$ is a placeholder. Copy it exactly (same name, same case); move it wherever the sentence needs it. The validator fails on mismatches.
• language_code isn't translated: it's the file's own locale with a hyphen (ja, zh-TW, pt-BR), set as the UI's lang so fonts follow it.
• store_listing and privacy_policy are multi-paragraph store copy, not UI; translate them too, keeping the paragraphs and bullet characters.

What to translate

1. Missing strings. Run yarn validate-locales; every "missing translation" error is a string to add.
2. Changed English. A string that changed in en.config on this branch needs retranslating even though every locale has it: git diff origin/v4 -- src/assets/_locales/en.config (or the branch's base). A renamed key counts as removed and added: rename it in every locale.
3. A new locale (/translate add <code>): create <code>.config with every section and key of en.config, translated. Use a code Chrome supports (developer.chrome.com/docs/extensions/reference/api/i18n#locales) — nothing else in the repo lists locales.

Audit a locale

For /translate audit <code>: review a whole locale that already passes the validator, as one pass with its own PR.

1. yarn validate-locales --audit <code> lists what to look at first: strings identical to English (a loanword, or untranslated?), "..." for "…", stray spaces, and short labels much longer than the English.
2. Read the whole file against en.config, top to bottom, applying "Sound native" below and the locale's per-language note. Fix untranslated strings, calques, typos and grammar, register and terminology drift. Store copy (store_listing, privacy_policy) is the oldest text and usually needs the most.
3. Look at it in the extension with yarn dev:chrome:locale <code>: the tab row, segmented controls, the shortcuts view, menus and the popup are the tight spots.
4. In the PR, list every changed string with its English and why it changed, in English, so it can be reviewed without reading the language. Say what still needs a native speaker's eye.

How to translate well

• Look at where a string is used before translating a short or ambiguous one: grep -rn "'<key>'" src and read the component. "Light" is a theme name in one place and a font weight in another; "Style" may be a noun (a site's CSS) or a verb.
• UI register: short, plain, the way the platform's own UI says it in that language. Sentence case where the language has case. Buttons and menu items are actions ("Copy CSS"), not descriptions.
• Length: many strings sit in tight buttons, tabs, segmented controls and menus. Prefer the shorter natural wording; check the component when a translation runs much longer than the English.
• Punctuation: use the language's own quotes (« », „ “, 「」, “ ”), ellipsis "…", and spacing rules (a space before ? ! : ; in French).
• Consistency: reuse the wording the locale already uses for the same concept — read neighbouring strings in that locale file before writing.