# Hodios paste pack: Localization (software)

Everything in Localization (software) from Hodios, the open prompt library by Hermes IDE: 7 entries, catalog 2026.1003.0.

Every entry is dedicated to the public domain under CC0 1.0. Copy, change and share them freely, no attribution needed.

Browse and search the library at https://hermes-ide.com/prompts

## How to use

Find an entry below and copy the text inside its block into ChatGPT, claude.ai or any chat. Replace each [PLACEHOLDER] with your own material. Personas, rules and styles work best as custom instructions or project instructions.

## Contents

- Localization (software)
  - [Build a localization glossary](#build-localization-glossary) (prompt)
  - [Extract hard-coded UI strings](#extract-ui-strings) (prompt)
  - [Plan and implement right-to-left support](#plan-rtl-support) (prompt)
  - [QA a translated string catalog](#review-translated-strings) (prompt)
  - [Review code for internationalization bugs](#review-i18n-readiness) (prompt)
  - [Translate a software string catalog](#translate-string-catalog) (prompt)
  - [Write ICU plural and select messages](#write-icu-plural-messages) (prompt)

---

<a id="build-localization-glossary"></a>

## Build a localization glossary

`build-localization-glossary` · prompt · Localization (software) · https://hermes-ide.com/prompts/build-localization-glossary

Builds a product term base from UI strings, with definitions, do-not-translate terms and proposed translations per locale, so localization stays consistent. Use before the first translation round.

````markdown
<context>
Without a glossary, each translator and each release picks its own word for the product's core concepts, so "Workspace" becomes three different words in German across one screen, and "Archive" and "Delete" blur together in a language where the first guess was a synonym. A good term base is short, covers the terms that carry product meaning or appear everywhere, defines each one so translators understand the concept rather than the English word, and settles brand names once.
</context>

<task>
Build a localization glossary from these strings:

[SOURCE_STRINGS]

Target locales: [LOCALES]
Product context: [PRODUCT_CONTEXT]

1. Extract candidate terms:
   - product objects and features ("Workspace", "Board", "Snapshot");
   - recurring UI actions whose differences matter ("Archive" versus "Delete" versus "Remove", "Sign in" versus "Log in");
   - domain terms that users must understand precisely;
   - brand, product and plan names, and code-like tokens.
   Skip generic words that any translator handles consistently.
2. Check the source for its own inconsistencies first: the same concept named two ways, or one word used for two concepts. Report them, because they must be fixed in the source or the glossary will encode the confusion.
3. For each term, record its part of speech, a one-sentence definition of the concept in this product, a real usage example taken from the strings, and whether it is do-not-translate.
4. Propose a translation per locale:
   - For standard concepts (Settings, Preferences, Sign in, Share), follow the target platform's published UI terminology; Microsoft and Apple both publish localized term lists. Note where the two differ.
   - For inflected languages, give the grammatical gender and the plural form.
   - Pick a translation that keeps distinct source terms distinct.
   - Note forbidden alternatives where a common choice would be wrong ("Do not use 'Löschen' for Archive").
   - Mark every proposal as "proposed" for a native-speaking reviewer to approve.
5. Keep the glossary focused: at most 40 terms, ordered by how often they appear and how much meaning they carry.
6. If the product context is missing and the strings do not make the concepts clear, ask up to 3 questions about the terms that matter most, and build the rest.
</task>

<constraints>
- Never present a proposed translation as approved or authoritative.
- Do-not-translate terms are only brand names, product names, trademarks, code identifiers and terms the context says to keep. Ordinary words are not do-not-translate just because they are capitalised.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
</constraints>

<output_format>
## Source inconsistencies
| Concept | Variants found | Example keys | Recommended single term |
"None" if there are none.

## Glossary
| Term | Part of speech | Definition | Example from the strings | One column per locale: proposed translation (gender and plural where relevant) | Notes and forbidden alternatives |

## Do not translate
One line each, with the reason.

## Export
The glossary as CSV in a code block, with columns `term,pos,definition,dnt,<locale>...,notes`, ready to import into a translation management tool.
</output_format>
````

---

<a id="extract-ui-strings"></a>

## Extract hard-coded UI strings

`extract-ui-strings` · prompt · Localization (software) · https://hermes-ide.com/prompts/extract-ui-strings

Finds hard-coded user-facing strings and moves them into an i18n catalog with meaningful keys and translator comments, without changing behaviour. Use when preparing an app for translation.

````markdown
<context>
String extraction looks mechanical, but most localisation bugs are created here. Concatenated fragments ("You have " + n + " items") cannot be translated, because word order and plurals differ by language. Keys named after the English text break as soon as the copy changes. The same English word in two contexts ("Open" the verb, "Open" the status) shares one key and gets one wrong translation. Log messages and analytics event names get extracted and break dashboards. Translators get a bare string with no idea where it appears or how long it may be.
</context>

<task>
Extract user-facing strings from [FILES].

i18n library: [I18N_LIBRARY] (if empty, detect it from dependencies and existing catalogs. If none exists, stop and recommend one suited to the stack in one paragraph).
Key style: dotted.

1. Study the existing setup: catalog location and format, how strings are looked up, the key naming already in use, the interpolation, plural and rich-text APIs, and where translator comments go.
2. Extract only text a user sees or hears: visible text, `aria-label`, `alt`, `title` and `placeholder` attributes, validation and error messages shown to users, notifications, page titles and email or push templates.
3. Do not extract: log and debug messages, exception messages that never reach the UI, analytics event names, CSS classes, test ids, route paths, enum values, API field names, or developer-only text. When in doubt, list the string under Needs a decision.
4. Convert, never copy, these patterns:
   - Concatenation and template literals become one message with named placeholders, in the library's own interpolation syntax.
   - Count-dependent text becomes the library's plural form (ICU `plural` or the platform plural resource), never `n === 1 ? ... : ...`.
   - Text with inline markup or links uses the library's rich-text or component interpolation instead of being split into pieces.
   - Dates, numbers and currency inside strings become placeholders formatted with the locale-aware formatter.
5. Name keys by feature, then screen or component, then purpose (`checkout.payment.submitButton`), never by the English text. Give identical English text in different contexts separate keys.
6. Add a translator comment to every new entry: where it appears, what each placeholder holds with an example value, and a maximum length if the space is constrained.
7. Behaviour must not change. Default-locale output must be identical to before, character for character, including whitespace and punctuation. Run the build, type check and tests.
</task>

<constraints>
- Do not translate anything; add only the source-language catalog entries.
- Do not reorganise or rename existing keys.
- Keep each file's change minimal: the lookup call plus any import the library needs.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
- Before saying the work is done, run the check that proves it (tests, build, type check or the command the user gave) and report the real result.
- If you could not run a check, say so plainly and say which one.
</constraints>

<output_format>
## Summary
Files touched, strings extracted, strings skipped.

## Catalog additions
The new entries in the catalog's own format, with their comments.

## Source changes
A unified diff.

## Skipped
| String | File:line | Reason |

## Needs a decision
Strings you could not classify, and messages that need product copy changes to translate well.

## Verification
Commands run and their actual results.
</output_format>
````

---

<a id="plan-rtl-support"></a>

## Plan and implement right-to-left support

`plan-rtl-support` · prompt · Localization (software) · https://hermes-ide.com/prompts/plan-rtl-support

Plans and implements right-to-left layout support (logical properties, mirroring rules, bidi text, icons) for a web or mobile UI. Use when adding Arabic, Hebrew, Persian or Urdu.

````markdown
<context>
Right-to-left support is not `transform: scaleX(-1)` on the whole page. The layout flips, but some things must not: media playback controls, clocks, logos, phone numbers, code and most charts. Mixed-direction text such as an English product name inside an Arabic sentence, or a phone number, needs bidi isolation, or punctuation jumps to the wrong end. Most breakage comes from physical properties (`left`, `marginLeft`, `paddingRight`) and directional icons hard-coded throughout the code.
</context>

<task>
Make [CODE_AREA] ready for the right-to-left locales ar, he on web.

1. **Audit** the code for direction-dependent code, with file and line:
   - **web:** physical CSS (`margin-left`, `padding-right`, `left`, `right`, `text-align: left`, `border-left`, `float`, and corner-specific radii), `translateX` and directional animations, `background-position`, absolute positioning, and a missing `dir` or `lang` on `html`.
   - **ios:** left and right constraints instead of leading and trailing, `NSTextAlignment.left`, images not set to flip, `semanticContentAttribute` overrides, and SwiftUI views that ignore the `layoutDirection` environment.
   - **android:** `android:supportsRtl` missing, left and right attributes instead of start and end (Android Lint flags these as `RtlHardcoded`), and vector drawables without `autoMirrored`.
   - **flutter:** `EdgeInsets.only(left:)`, `Alignment.centerLeft` and `Positioned(left:)` instead of the directional variants, missing `Directionality` or localization delegates, and icons without `matchTextDirection`.
2. **Decide mirroring** for every icon and visual, in a table:
   - Mirror back and forward arrows, chevrons, progress direction, list and indent icons, sliders, and "send" or "reply" arrows.
   - Do not mirror media play and fast-forward, clocks and circular refresh, checkmarks, logos, brand marks, keyboard and code text, or icons showing a real-world object held in the right hand.
   - Charts: time axes in RTL locales are a product decision; flag it rather than flipping silently.
3. **Bidi text:** isolate user-generated or mixed-language text (`dir="auto"`, `bdi`, `unicode-bidi: isolate`, or FSI and PDI characters on native platforms). Keep phone numbers, email addresses, URLs, code and inputs for them left-to-right. Format numbers with the locale formatter, which decides whether to use Arabic-Indic digits.
4. **Typography:** do not apply `letter-spacing` to Arabic (it breaks letter joining), avoid uppercase and italic styles that do not exist in these scripts, check the font stack includes the scripts, allow more line height, and make sure ellipsis truncation lands on the correct side.
5. **Gestures and motion:** swipe-to-go-back, carousels, drawers and slide-in transitions follow the reading direction.
6. **Plan** the work in phases: foundation (document direction, locale plumbing, lint rules that block new physical properties), shared components, screens, assets, then QA. Give each phase an S, M or L effort and note its dependencies.
7. **Implement** the foundation and the changes in [CODE_AREA]. Prefer logical equivalents (`margin-inline-start`, `inset-inline-end`, `text-align: start`, `leading`, `start`, `EdgeInsetsDirectional`) over direction branches. Use an explicit RTL override only where the logical form cannot express the intent.
</task>

<constraints>
- Do not flip the whole UI with a mirror transform.
- Left-to-right rendering must not change. Verify that each change renders the same in LTR.
- Translation is out of scope. Use a pseudo-RTL locale or the platform's force-RTL option for testing.
- Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
- Keep the change as small as it can be while still being correct.
- Read the relevant code before making a claim about it. Do not guess what a file, function or config contains.
- If the information you need is not available, say what is missing and how to get it instead of inventing it.
</constraints>

<output_format>
## Audit
| File:line | Issue | Fix |

## Mirroring decisions
| Element | Mirror? | Reason |

## Plan
Phases with effort, dependencies and a done-when line each.

## Changes
A unified diff for the foundation and [CODE_AREA].

## Test checklist
How to switch to RTL on web (the `dir` attribute, the Xcode right-to-left pseudolanguage, Android's "Force RTL layout direction" developer option, or Flutter's `Directionality` override), plus the screens and states to compare in LTR and RTL screenshots.
</output_format>
````

---

<a id="review-translated-strings"></a>

## QA a translated string catalog

`review-translated-strings` · prompt · Localization (software) · https://hermes-ide.com/prompts/review-translated-strings

QA-checks a translated catalog against its source for placeholder mismatches, broken syntax, truncation risk, terminology drift and untranslated strings. Use before merging translations.

````markdown
<context>
Translation QA catches the defects that crash or embarrass the app before users see them. In rough order of cost: a renamed or dropped placeholder that throws at runtime or prints `{name}`, broken ICU or file syntax that fails the whole catalog, missing keys that fall back to English mid-screen, a label too long for its button, and the same product term translated three different ways. Judging fluency is secondary and needs a native speaker. Mechanical checks must be exhaustive.
</context>

<task>
Check the translation against the source.

Source:
[SOURCE_CATALOG]

Translation:
[TRANSLATED_CATALOG]

Glossary: [GLOSSARY]

Work through every key. Do not sample.
1. **Coverage:** keys missing from the translation, extra keys not in the source, empty values, and values identical to the source. For identical values, decide whether they are legitimate (brand names, "OK", codes, true cognates) or untranslated.
2. **Placeholders:** the same set of placeholders, by name and count: printf (`%s`, `%d`, `%1$s`), ICU arguments, and markup or inline tags. Check that the types match (`%d` was not turned into `%s`) and that positional specifiers are used when arguments were reordered.
3. **ICU and plurals:** argument names and keywords are untouched, `other` is present, and the plural categories match the target locale's CLDR rules (no required category missing, no invalid one added).
4. **Syntax:** the file still parses (JSON escaping, PO quoting and `msgstr[n]` count against `Plural-Forms`, XLIFF well-formed, unbalanced ICU apostrophes or braces).
5. **Length:** values over a declared maximum length, and for short UI labels (under about 25 characters) values more than about 1.5 times the source length. Mark these as truncation risks.
6. **Terminology:** glossary terms translated as approved, do-not-translate terms left as they are, and the same source term translated the same way across keys.
7. **Mechanics:** leading and trailing whitespace, ending punctuation that differs (colons, ellipses, question marks), numbers or dates hard-coded in the text that differ from the source, and a mix of formal and informal address.
8. **Meaning:** flag only clear errors (opposite meaning, wrong object, a dropped negation), each with a confidence level. Leave style preferences out.
</task>

<constraints>
- Severity: **blocker** for anything that can crash, fail to parse or show raw placeholders; **major** for missing translations, wrong meaning, glossary violations and length overflows; **minor** for punctuation, whitespace and consistency.
- Quote the exact source and translated text for every finding, and give a corrected value when you can.
- If the two files are in different formats or clearly do not correspond, say so and stop.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
</constraints>

<output_format>
## Verdict
One line: ship / ship after fixes / do not ship. Then counts by severity, and the number of keys checked.

## Findings
| Key | Check | Severity | Source | Translation | Suggested fix |
Blockers first.

## Could not verify
Strings whose correctness depends on UI context or native-speaker judgement, one line each.
</output_format>
````

---

<a id="review-i18n-readiness"></a>

## Review code for internationalization bugs

`review-i18n-readiness` · prompt · Localization (software) · https://hermes-ide.com/prompts/review-i18n-readiness

Reviews code for internationalization bugs such as concatenated strings, hard-coded date, number and currency formats, naive plurals, text expansion and RTL breakage. Use before adding new locales.

````markdown
<context>
Internationalisation bugs hide until the first non-English locale ships. Then a Polish user reads "5 plik" because the code assumed one-or-many plurals, a German button overflows, a Turkish user cannot log in because `"I".toLowerCase()` is not "ı", an Arabic layout is mirrored everywhere except the margins, a Japanese price shows two decimals, and a date reads 03/04 to someone who expects 4 March. The review must find these in the code before translators start, and show the exact input that breaks.
</context>

<task>
Review this code for internationalisation readiness:

[CODE]

Target locales: [TARGET_LOCALES] (if empty, use German, Japanese, Arabic, Polish, Turkish and Hindi as stress cases).

Check each category below. For every finding, construct the locale and input that breaks it.
1. **Strings:** hard-coded user-facing text; concatenation or interpolation that fixes word order; sentence fragments assembled in code; one key reused in different contexts; text baked into images or SVGs.
2. **Plurals and gender:** `count === 1` ternaries, `+ "s"`, and any logic that assumes two forms; messages that assume a grammatical gender.
3. **Dates and times:** fixed format strings, `toString()` or formatting without an explicit locale, assuming the week starts on Sunday or Monday, the 12- versus 24-hour clock, time zone handling (store UTC, display in the user's zone), and non-Gregorian calendars if the targets need them.
4. **Numbers and currency:** `toFixed`, hand-made thousands separators, a hard-coded currency symbol or position, currency minor units (JPY has 0, KWD has 3), floats for money, and parsing user input as if it were always `1,234.56`.
5. **Text handling:** case mapping without a locale (Turkish dotted and dotless i), `length` or slicing that splits surrogate pairs or grapheme clusters (emoji, Indic scripts), byte-based truncation, sorting without a collator, and search that ignores accents or normalisation (NFC versus NFD).
6. **Layout:** fixed widths or heights on text containers (German and Finnish run 30 to 40 percent longer, and short labels can double), truncation without a tooltip, and fonts or line-height that clip scripts with tall glyphs.
7. **Direction (if any target is right-to-left):** physical CSS properties (`margin-left`, `left`, `text-align: left`), directional icons, missing `dir` and `lang` attributes, and user content not isolated with `dir="auto"` or `bdi`.
8. **Locale plumbing:** how the locale is chosen, the fallback chain, `lang` on the document, server-rendered and email text, and locale-sensitive validation (postal codes, phone numbers, names split into first and last).
</task>

<constraints>
- Report only real defects in the given code, each with file and line and the breaking example. Do not list general advice the code already follows.
- Rank by user impact: wrong data or blocked flows (wrong money amount, failed login, corrupted text) first, then unreadable or broken UI, then polish.
- At most 15 findings. If one cause repeats, report it once and list every location.
- Read the relevant code before making a claim about it. Do not guess what a file, function or config contains.
- If the information you need is not available, say what is missing and how to get it instead of inventing it.
</constraints>

<output_format>
## Summary
Two or three sentences: readiness for the target locales, and the top blockers.

## Findings
Numbered, highest impact first. Each:
- `path:line`: the problem
- Breaks in: the locale and input, with the wrong output it produces
- Fix: the code change, using the platform's locale-aware API (for example `Intl.NumberFormat`, `Intl.PluralRules`, `Intl.Collator`, ICU MessageFormat, or the platform formatter)

## Looks fine
Categories checked with no issues, in one line.
</output_format>
````

---

<a id="translate-string-catalog"></a>

## Translate a software string catalog

`translate-string-catalog` · prompt · Localization (software) · https://hermes-ide.com/prompts/translate-string-catalog

Translates a software string file (JSON, PO, XLIFF, ARB, Android or Apple strings) keeping keys, placeholders, plurals and length limits intact. Use when localizing an app's UI text.

````markdown
<context>
A string catalog is code that happens to contain language. A translated file that reads beautifully is still broken if one placeholder was renamed, a plural category the target language needs is missing, an ICU keyword got translated, or a button label is now twice as long as its slot. Translators also lack context: a bare "Post" or "Open" can be a noun, a verb or a status, and guessing silently ships a wrong UI.
</context>

<task>
Translate this catalog into [TARGET_LOCALE], using the match-existing register (for match-existing: follow the glossary or the strings already translated; if there are none, use the register the platform's own UI uses for [TARGET_LOCALE] and record that choice in Review notes):

[CATALOG]

Glossary: [GLOSSARY]

1. Identify the format and follow its rules exactly:
   - **JSON:** keys, nesting and order unchanged; escape quotes and backslashes.
   - **PO:** keep `msgid` and `msgctxt`; fill `msgstr`, or `msgstr[0..n]` for plurals, with exactly as many forms as the target's `Plural-Forms` header requires (update the header if it is missing or set for the source language). Keep flags such as `c-format`.
   - **XLIFF:** write `target` elements, keep inline elements such as `x`, `g`, `ph` and `pc` with their ids, and set the state attribute the file uses for "translated, needs review".
   - **ARB:** translate values only, and keep `@` metadata entries unchanged.
   - **Android `strings.xml`:** translate the text of `string`, `plurals` items and `string-array` items only; keep `name` attributes, leave out entries marked `translatable="false"` (Android expects them absent from translated files), give `plurals` exactly the `quantity` items the target needs, and escape apostrophes and double quotes (`\'`, `\"`) and a leading `@` or `?`.
   - **Apple `.strings` and `.xcstrings`:** keep keys and the escaping, use positional specifiers (`%1$@`) if you reorder arguments, and in a String Catalog add the target's plural variations and set each new unit's state to the one the file uses for "needs review".
2. Keep every placeholder exactly: printf specifiers (`%s`, `%d`, `%1$s`), ICU arguments (`{name}`), and markup tags. Inside ICU `plural`, `select` and `selectordinal`, translate only the text in each branch, never the argument name or the keywords. Add or remove plural branches to match the CLDR categories of [TARGET_LOCALE]: for example one, few, many and other for Polish or Russian, only other for Japanese, and six categories for Arabic. Always keep `other`.
3. Apply the glossary exactly, inflecting approved terms as the sentence's grammar requires (case, number, articles) without swapping in a synonym, and leave do-not-translate terms (brand and product names, code identifiers) as they are. Use one translation per source term across the whole file.
4. Follow the target's UI conventions: the usual verb form for buttons and menu items in that language (German uses the infinitive, as in "Speichern"), capitalisation rules, punctuation and typography (French spaces before `: ; ! ?`, the target's quotation marks, Spanish `¿` and `¡`), and gender-neutral phrasing where the language allows it naturally.
5. Respect length limits from comments or metadata. If a natural translation does not fit, give the best one that fits and note the longer alternative.
6. When a string is ambiguous without context (noun or verb, status or action, unclear placeholder content), translate the most likely reading and flag it with the alternative.
</task>

<constraints>
- Output the complete file. Never drop, merge, reorder or add keys, apart from the Android `translatable="false"` exception above.
- The file must stay syntactically valid in its format.
- Do not "improve" the source text. If the source has an error, translate what was meant and flag it.
- If the catalog is not a recognisable string catalog, or [TARGET_LOCALE] is not a valid locale, say so and stop.
</constraints>

<output_format>
## Translated catalog
The full translated file in one code block, in the original format.

## Review notes
| Key | Type (ambiguous / length / glossary / plural change / register / source issue) | Note and alternative |
"None" if there are no notes.
</output_format>
````

---

<a id="write-icu-plural-messages"></a>

## Write ICU plural and select messages

`write-icu-plural-messages` · prompt · Localization (software) · https://hermes-ide.com/prompts/write-icu-plural-messages

Converts messages with counts, gender or choices into correct ICU MessageFormat for each target locale's plural categories, with test values. Use when strings depend on a number or gender.

````markdown
<context>
English has two plural forms, so English-speaking developers write `count === 1 ? "item" : "items"` and ship it. CLDR defines up to six categories (zero, one, two, few, many, other), and which numbers fall into each depends on the locale: 21 is "one" in Russian, 1.5 is "one" in French but "other" in English, and Japanese has only "other". ICU MessageFormat handles all of this, but only when every branch is a full sentence, `other` is always present, the number is written as `#`, and the categories match each locale.
</context>

<task>
Convert these messages to ICU MessageFormat for the locales [LOCALES]:

[MESSAGES]

1. For each message, identify the variables and their kinds: a count (cardinal plural), a rank (ordinal, `selectordinal`), gender or another category (`select`), or plain interpolation.
2. Write the source-language message first:
   - Use `#` for the formatted count inside plural branches.
   - Use `=0` (or any exact `=N`) only for wording that is genuinely special ("No messages"), never as a stand-in for a plural category.
   - Use `offset:1` for patterns like "You and # others".
   - Put `select` outside and `plural` inside when both apply, and make every branch a complete sentence. Never assemble fragments around a plural.
   - Every `plural`, `select` and `selectordinal` has an `other` branch.
   - Escape a literal apostrophe as `''` and literal braces with apostrophe quoting.
3. For each target locale, list its CLDR cardinal categories (and ordinal categories if used), then write the message with exactly those branches plus any exact matches. Translations: draft. With `draft`, translate every branch with the grammar the category needs (case and agreement change between `few` and `many`, not only the noun ending) and mark each locale as needing review by a native speaker; if you cannot translate a locale reliably, fall back to `TODO` text for it and say so. With `structure-only`, write `TODO` text in every branch, with a translator note naming the number range each branch covers.
4. Choose test values that hit every category in each locale, including the tricky ones: 0, 1, 2, a few-range value, 5, 11, 21, 22, 101, 1.5, and a large number such as 1000000 where the locale has a `many` category for it.
5. If a runtime is available, verify categories with `Intl.PluralRules` (or the ICU library) and say you did. Otherwise state that the categories come from CLDR rules.
</task>

<constraints>
- Never translate ICU keywords, argument names or category names.
- Do not reduce a locale's categories to make messages shorter; missing categories fall back to `other` and read wrongly.
- If a message cannot work as ICU without a copy change (for example, a count embedded in a fragment shared across messages), say so and propose the reworded source.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
</constraints>

<output_format>
## Messages
For each key: the source message, then one code block per locale, headed by the locale and its category list.

## Test values
| Key | Locale | Value | Category | Expected output |

## Notes
Copy changes needed, translations to review, and any category you could not confirm.
</output_format>

<examples>
<example>
Key `inbox.unread`, variable `count`, locales en and ru.

en (one, other):
```
{count, plural, =0 {You have no unread messages} one {You have # unread message} other {You have # unread messages}}
```

ru (one, few, many, other):
```
{count, plural, =0 {У вас нет непрочитанных сообщений} one {У вас # непрочитанное сообщение} few {У вас # непрочитанных сообщения} many {У вас # непрочитанных сообщений} other {У вас # непрочитанного сообщения}}
```

Test values for ru: 1 and 21 are one; 2 and 22 are few; 5, 11 and 100 are many; 1.5 is other.
</example>
</examples>
````