# Hodios paste pack: Localization (software)
Everything in Localization (software) from Hodios, the open prompt library by Hermes IDE: 19 entries, catalog 2026.1004.3.
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)
- [App localisation track](#app-localization-track) (workflow)
- [Automate translation file sync](#automate-translation-file-sync) (prompt)
- [Build a localization glossary](#build-localization-glossary) (prompt)
- [Design international name and address fields](#design-international-address-and-name-fields) (prompt)
- [Design locale detection and routing](#design-locale-detection-and-routing) (prompt)
- [Extract hard-coded UI strings](#extract-ui-strings) (prompt)
- [Implement locale-aware formatting](#implement-locale-formatting) (prompt)
- [Implement locale-aware sorting and search](#implement-locale-aware-sorting-and-search) (prompt)
- [Internationalisation-ready code rules](#i18n-ready-code-rules) (rule)
- [Localise game strings and fonts](#localize-game-strings-and-fonts) (prompt)
- [Localization engineer](#localization-engineer) (persona)
- [Plan a new language launch](#plan-new-language-launch) (prompt)
- [Plan and implement right-to-left support](#plan-rtl-support) (prompt)
- [Pseudo-localize the UI](#pseudo-localize-ui) (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)
- [Write translator context notes](#write-translator-context-notes) (prompt)
---
## App localisation track
`app-localization-track` · workflow · Localization (software) · https://hermes-ide.com/prompts/app-localization-track
Takes an English-only app to its first extra language in gated steps, from readiness scan and string extraction to formatting fixes, pseudo-localisation, translation hand-off and linguistic QA.
````markdown
Takes an app that only speaks English to its first extra language the way a localization engineer would: find what blocks translation, make the code translatable, prove it with pseudo-localisation, hand translators a complete package, and gate the release on native review. The first language costs the most because it pays for the plumbing; done well, later languages are mostly translation.
[APP_DESCRIPTION]
Target locale: [TARGET_LOCALE]. Stack: [TECH_STACK] (detect from the repo if empty).
Rules for every step:
- Work from the code you have read. Cite file paths; never invent findings, string counts or library APIs.
- Ask for missing essentials (who translates, deadline, platforms) and mark gaps as [X].
- Keep English behaviour and text unchanged unless a fix needs it, and list every such change.
- Do not ship machine translation as final text; do not state legal or store requirements as fact, and say who should verify them.
- End each artifact with open questions.
- 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.
---
# Step 1: Readiness scan
1. Identify the stack, any existing i18n library, where user-facing text lives (UI, server responses, emails, push, PDFs, images) and how the app picks a locale today.
2. Count hard-coded strings by area, and list concatenations, naive plurals, hand-built dates, numbers and currency, fixed-width text containers and text in images, with file paths.
3. Note what the target locale adds: plural categories, script and direction, formats, text length.
4. Recommend the i18n library and catalog format for this stack if none exists, with one alternative.
Sections: Stack and set-up, Findings by area (table: Area | Issue | Count | Example path), Locale-specific risks, Recommendation, Open questions. Stop and wait for approval.
---
# Step 2: Extract strings with context
1. Set up the approved library and an English source catalog; add a lint rule against new hard-coded strings if the stack has one.
2. Move strings into the catalog area by area, with stable keys by feature and purpose and a translator comment wherever meaning, placeholder or length is not obvious.
3. Rewrite concatenations as single messages with named placeholders, and counts as ICU plurals.
4. Change no behaviour or visible English text, except where a fix needs it; list those.
Sections: Changes by area, New keys (count and examples), Strings left for later with reasons. Stop and wait for approval.
---
# Step 3: Fix locale formatting
1. Replace hand-built dates, times, numbers, currencies, lists and relative times with locale-aware APIs, passing the active locale.
2. Fix layout for text growth (wrapping, no fixed widths); for a right-to-left target, switch to logical CSS properties and set `dir`.
3. Make the locale choice explicit: saved user choice, then device or browser preference, then default, with a fallback chain to English.
4. Add tests that render key screens or functions in English and the target locale.
Sections: Changes, Tests added, Remaining risks. Stop and wait for approval.
---
# Step 4: Pseudo-localisation check
1. Add a pseudo-locale that accents characters, brackets each string and expands it by about 35 percent.
2. Walk the key flows in it and record every untranslated string (shows without brackets), truncation, overflow and broken placeholder, by screen.
3. Fix what is in scope and list the rest.
Sections: Issues found (table: Screen | Issue | Fixed?), Remaining issues. Stop and wait for approval.
---
# Step 5: Translation hand-off
1. Prepare the package: the catalog export in a format the translator accepts (XLIFF is the most portable), screenshots or a staging link, character limits, a glossary of product terms and do-not-translate words, and tone notes.
2. Write the brief: audience, deadline, review process and who answers questions.
3. Set up the return path: translations come back through a pull request, never hand-pasted, with CI checking syntax and placeholders.
4. Do not machine-translate for release unless the team chose it, and then mark it for native review.
Sections: Package contents, Translator brief, Return process. Stop and wait for approval.
---
# Step 6: Linguistic QA and release
1. Plan in-context review by a native speaker on a staging build: key flows, emails and store listing, with a bug template (screen, string key, issue, suggested fix, severity).
2. Run functional checks in the target locale: missing keys, fallbacks, formats, layout and, if relevant, direction.
3. Define the release gate (for example no open critical or major bugs and all checkout and legal strings reviewed) and a rollout behind a flag or to a small audience first.
4. List what the team must verify outside engineering (legal text review, store requirements, support coverage).
Sections: QA plan, Release gate, Rollout, Open items.
````
---
## Automate translation file sync
`automate-translation-file-sync` · prompt · Localization (software) · https://hermes-ide.com/prompts/automate-translation-file-sync
Designs the pipeline between a repo and translators, with key extraction, upload to a translation system or vendor, download of finished locales, CI checks for keys and fallbacks, and approvals.
````markdown
Translation by email attachment breaks as soon as a team ships weekly. Strings change after they were sent; translated files overwrite each other; a renamed key silently drops a translation; releases go out with raw keys on screen; and nobody knows which locale is complete. Continuous localisation fixes this with a few rules: the source locale lives in the repo and is the single source of truth; target locales flow back through automation, never by hand-editing; CI blocks broken placeholders and missing source keys but does not block on untranslated targets; and a fallback chain decides what users see meanwhile. The translation management system (TMS) is a choice, not the pipeline itself, so the design should work with a vendor file exchange too.
Design the translation sync for [TECH_STACK] with json catalogs.
1. Source of truth: where source strings live, who may edit target-locale files (normally only the sync bot), and how keys are named and commented.
2. Extraction: when keys are extracted (on merge to the main branch, not every commit), with which tool for this stack, and how unused keys are detected and removed after a grace period rather than immediately.
3. Upload: push new and changed source strings with context (comments, screenshots, max length) to the TMS through its CLI or API, or produce an export file (XLIFF is the most portable) for vendors. Changed source text must invalidate or flag existing translations.
4. Download: a scheduled job or webhook that pulls completed translations into a branch and opens a pull request; only reviewed or approved strings are included, per a status rule you define. Never commit directly to the main branch.
5. CI checks on every pull request: catalog syntax valid; placeholders and ICU plural or select structure match the source in every locale; no duplicate keys; no keys used in code but missing in the source catalog; no hard-coded strings in changed UI files if a linter exists. Report, but do not fail on, missing target translations. Report completeness per locale.
6. Fallbacks: the runtime chain (for example `pt-BR` to `pt` to `en`), behaviour for a missing key (fallback text, never the raw key in production), and logging of missing keys.
7. Release gating: which locales ship when below a completeness threshold (for example 100% for checkout, 95% overall), and who decides.
8. Branching: how feature branches handle new strings (translate after merge, or a pre-translation branch for big launches) and how conflicts in generated files are avoided.
9. Machine translation: where it is allowed (draft for human review, never straight to legal or checkout copy) and how it is labelled in the TMS.
- Stay tool-agnostic in the design; give one concrete example configuration for this stack and say which parts change with another TMS. Do not invent CLI flags or API endpoints; mark them [check docs] when unsure.
- Never store TMS API tokens in the repo; use CI secrets.
- Ask about the translators and cadence if workflow notes are empty and the answer changes the design.
- 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.
## Pipeline
A numbered flow from developer commit to translated release, and a short text diagram.
## Configuration
Example config and CI job definitions for [TECH_STACK], with comments.
## CI checks
Table: Check | Fails the build? | Tool or script | What it catches.
## Roles and approvals
Table: Role | Owns | Approves.
## Rollout
Steps to move from today's process, including a one-time cleanup of stale keys and a pilot locale.
````
---
## 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
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.
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.
- 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.
## 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,...,notes`, ready to import into a translation management tool.
````
---
## Design international name and address fields
`design-international-address-and-name-fields` · prompt · Localization (software) · https://hermes-ide.com/prompts/design-international-address-and-name-fields
Designs form fields, validation and storage for personal names, postal addresses and phone numbers that work across countries. Use for international sign-up, checkout or shipping forms.
````markdown
Forms built around one country's conventions quietly reject real people: a "last name" field required for someone with one name, a regex that rejects apostrophes, hyphens or non-Latin scripts, a 5-digit postcode rule that blocks Canada, a mandatory state field for Ireland, a phone field that strips the country code, or a 30-character limit that truncates a Thai or Portuguese full name. Each rejection is a lost sign-up or a misdelivered parcel. Experts design from the data's purpose (what goes on a shipping label, what a courier needs, what a payment provider requires), use per-country address formats from a maintained dataset rather than guesswork, store phone numbers in E.164, and validate only what they must.
Design name, address and phone fields for this form, serving: worldwide.
[FORM_DESCRIPTION]
1. Purpose first: for each piece of data, state why it is collected and the downstream system that consumes it (courier label, tax invoice, payment provider address verification, identity check, greeting). Drop fields that have no consumer.
2. Names:
- Default to one "Full name" field plus an optional "What should we call you?" field for greetings. Split into given and family name only if a consumer requires it (some payment or identity providers do), and then make neither field mandatory on its own where the provider allows.
- Accept any Unicode letters, marks, spaces, apostrophes, hyphens and periods; no minimum length beyond one character; maximum at least 100 characters; no case changes on save.
- For Japanese, Chinese and Korean markets, consider a phonetic reading field (furigana) if sorting or calling by name matters.
3. Addresses:
- Choose the format per country from a maintained source (for example Google's libaddressinput metadata or a commercial address API), switching fields and labels when the country changes: "Postcode", "ZIP code", "PIN code"; state, province, prefecture or none; field order (Japan starts with postcode and prefecture).
- Put country first so the rest of the form adapts. Use `autocomplete` tokens (`country`, `address-line1`, `address-line2`, `address-level1`, `address-level2`, `postal-code`).
- Postcode: required only where the country uses postcodes (for example not in Hong Kong or most of the UAE); validate with the country's pattern only as a soft warning unless the courier rejects invalid codes.
- Keep two or three free address lines; never parse house numbers out.
- Offer address lookup as a shortcut, never as the only way; always allow manual entry.
4. Phones: one field with a country selector defaulting from the address country, parsed and validated with a maintained library (for example libphonenumber), stored in E.164 (`+4915112345678`), and displayed in national format. Do not require a mobile number unless SMS is essential.
5. Things never to validate: name "realness", the presence of a family name, Latin-only scripts, house-number presence, postcode on countries without them, phone length by your home country's rules.
6. Storage: Unicode text columns (UTF-8, `nvarchar` on SQL Server), generous lengths, country as ISO 3166-1 alpha-2, the raw input preserved alongside any normalised form, and no derived fields stored as truth (do not split full name into first and last later).
- Name the data source to verify country rules; do not state a country's postcode format from memory unless it is well known, and mark uncertain ones [verify].
- Respect data minimisation: collect only what a consumer needs, and say where privacy law may limit collection or retention without giving legal advice.
- If the form's consumers are not described, ask which systems use the data before deciding on split name fields.
- 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.
## Decisions
Table: Data | Purpose and consumer | Field design | Required? | Why.
## Fields by country
Table for each target country (or the five most different for worldwide): Field order | Labels | Required fields | Postcode rule.
## Validation rules
Bullets: hard rules, soft warnings, and things never validated.
## Storage schema
The table definition or schema with types, lengths and a note per column.
## Test data
At least ten real-world-shaped test entries that break naive forms (single names, long names, apostrophes, non-Latin scripts, addresses without postcodes, Japanese order, international phone numbers), using fictional people.
````
---
## Design locale detection and routing
`design-locale-detection-and-routing` · prompt · Localization (software) · https://hermes-ide.com/prompts/design-locale-detection-and-routing
Designs how a web or mobile app picks and remembers language and region, with negotiation, explicit choice, URL strategy, hreflang, fallback chains and language kept separate from currency.
````markdown
Teams often treat "locale" as one setting and get stuck: a Swiss user wants French text but Swiss francs; an expat in Germany wants English with German shipping; a geo-IP redirect sends a traveller to the wrong site and hides the one they wanted from search engines; and an app store build ignores the per-app language the phone already lets users set. A sound design separates language (for text), region (for formats and legal content) and market (for currency, catalogue and prices); resolves them in a clear order with the user's explicit choice always winning; uses BCP 47 tags; and gives every language its own crawlable URL on the web.
Design locale detection and routing for this web product:
[PRODUCT_DESCRIPTION]
Locales: [LOCALES]
1. Locale model: define the separate settings (UI language, formatting region, market or storefront, time zone) and which ones the user can change independently. Map the requested locales to BCP 47 tags and say which are language-only, which are language-region, and which share translations (for example es-419 for Latin America).
2. Resolution order, first match wins. On the web, a URL that carries a locale always renders that locale, so shared links and crawlers get what the URL promises; a saved choice that differs triggers a suggestion banner, never a redirect away. For URLs without a locale (the root, app start, emails and other server channels) resolve in this order: explicit choice saved in the account; explicit choice in a cookie or local storage; the OS or browser preference list (`Accept-Language` with quality values, `navigator.languages`, the per-app language on iOS and Android 13+); then the default. Use a real BCP 47 lookup or best-fit matcher (the framework's built-in matcher or a maintained library such as `@formatjs/intl-localematcher`), not string prefix matching. Geo-IP may suggest a market but never switch language silently.
3. Fallback chain: for each supported locale, its chain (for example `de-CH` to `de` to `en`), and how missing strings, formats and content fall back separately.
4. Web URL strategy: compare subpath (`/de/`), subdomain and country-code domains for this product, recommend one, and give the routing rules: the root URL behaviour (a language chooser or a non-redirecting default, plus a suggestion banner rather than a forced redirect), `hreflang` alternates including `x-default`, canonical tags, sitemaps, and `lang` on `html`. Never vary the content of one URL by `Accept-Language` without `Vary` and alternates.
5. Mobile: follow the system and per-app language settings, offer an in-app picker only if users need a language different from the system, and handle the store listing languages separately.
6. Language switcher: names each language in its own language ("Deutsch", "Français"), not flags; keeps the user on the equivalent page; remembers the choice.
7. Server and other channels: emails, push notifications, PDFs and support use the saved language, not the request headers of whoever triggered them.
8. Give implementation sketches for the stack described (middleware, routing config, the negotiation function), and list edge cases with expected behaviour.
- Recommend one approach with reasons; mention the main alternative and when it would win.
- Do not state SEO outcomes or legal requirements as certain; say what to verify (for example country-specific legal pages).
- If the locale list is vague ("all of them"), or the stack, how users arrive, or whether prices and catalogue differ by country is missing, ask for those first and do not design for every language.
- 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.
## Decision summary
Five to eight bullets in decision-record style: the choice and why.
## Locale model
Table: Setting | Values | Source | User can change?
## Resolution order
Numbered list, and the fallback chain per locale as a table.
## URL and SEO
URL pattern, redirect rules, hreflang example for one page. "Not applicable" for mobile-only.
## Implementation
Code or config sketches for the stated stack.
## Edge cases
Table: Situation | Expected behaviour (traveller, VPN, shared device, logged-out user with saved cookie, a shared link in a language other than the saved choice, unsupported language, crawler without Accept-Language).
````
---
## 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
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.
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.
- 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.
## 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.
````
---
## Implement locale-aware formatting
`implement-locale-formatting` · prompt · Localization (software) · https://hermes-ide.com/prompts/implement-locale-formatting
Replaces hand-built date, time, number, currency, percentage and list formatting with locale-aware platform APIs across a codebase, and adds tests that run in several locales.
````markdown
Hand-built formatting looks right only in the developer's own locale. `month + "/" + day` is wrong for most of the world; `amount.toFixed(2) + " $"` breaks currencies with zero or three decimal places and puts the symbol on the wrong side; `n.toString().replace(/\B(?=(\d{3})+(?!\d))/g, ",")` ignores Indian digit grouping and locales that use a dot or a space as the separator; string-joined lists with "and" cannot be translated; and dates formatted on the server in its own time zone show the wrong day to users elsewhere. Platform APIs backed by CLDR data (`Intl` on the web and Node, `FormatStyle` and formatters on Apple platforms, `java.text`/`android.icu` on Android, ICU or Babel-style libraries on servers) solve all of this when used consistently.
Replace hand-built formatting in [SCOPE] with locale-aware formatting for web, supporting [LOCALES].
1. Run the build and tests and record the baseline. If they fail, stop and report.
2. Find where the app decides the current locale and time zone today (user settings, the request's language header, the device). If there is no single source, note it under Needs a decision and use the platform default for now; do not invent a locale-detection system.
3. Inventory hand-built formatting: string-concatenated dates and times, fixed date patterns, `toFixed` or manual separators for numbers, hard-coded currency symbols or positions, manual percentage maths, relative times ("3 days ago"), lists joined with commas and "and", units (km, kg) and file sizes. Also find parsing of user-entered numbers and dates that assumes one format.
4. Create or extend one small formatting module that wraps the platform APIs (on web, use its standard CLDR-backed formatters) and takes the locale (and time zone, where relevant) explicitly. Reuse formatter instances where construction is expensive. Do not add a new dependency when the platform API covers the need.
5. Replace each instance with a call to that module:
- Dates and times: format with style options (date style, time style or explicit fields), never fixed patterns, and always with an explicit time zone. Store and transmit timestamps in UTC; convert only for display.
- Money: format from an amount and an ISO 4217 currency code, letting the API decide symbol, position and decimal places. Keep monetary amounts in integer minor units or a decimal type; never format a floating-point sum.
- Numbers, percentages, compact numbers, units and relative times with their dedicated formatters.
- Lists with the list formatter.
- Parsing of user input: use locale-aware parsing, or a locale-neutral input control, and never assume a decimal separator.
6. Add tests that render representative values (a date near midnight in a non-UTC zone, a large number, a negative amount, a zero-decimal currency such as JPY, a three-decimal currency such as KWD, a list of three items) in every locale in [LOCALES]. Assert on structure and key properties, or on outputs you have verified from the platform, not on strings you guessed; note that whitespace characters such as narrow no-break spaces can differ between runtime versions.
7. Run the build, type check and tests again, and compare with the baseline.
- Do not translate strings or move text into catalogs; that is separate work. Where a formatted value sits inside a concatenated sentence, flag it under Needs a decision.
- Output in the default locale may change only where the old output was wrong; list every such change.
- Never change stored data formats or API payloads to localised strings.
- 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.
- Fix the behaviour, not the test. Never special-case test inputs, weaken assertions or skip tests to make a check pass.
- If a test looks wrong, explain why and ask before changing it.
## Baseline
Build and test results before changes.
## Inventory
| File:line | Kind (date, money, number, list...) | Problem | Replacement |
## Formatting layer
The formatting module as code.
## Changes
A unified diff of the call sites.
## Tests
The new tests, and the locales and edge values they cover.
## Needs a decision
Locale and time zone source issues, concatenated sentences, default-locale output changes.
## Verification
Commands run and their real results.
````
---
## Implement locale-aware sorting and search
`implement-locale-aware-sorting-and-search` · prompt · Localization (software) · https://hermes-ide.com/prompts/implement-locale-aware-sorting-and-search
Implements locale-aware sorting, comparison and search with ICU collation, Unicode normalisation, case folding, accent-insensitive matching and database collations, plus tests that break naive code.
````markdown
Code that sorts and searches by byte or code point works for ASCII English and fails everywhere else. Swedish sorts "ö" after "z", German sorts it with "o"; Spanish users expect "ñ" after "n"; "Zoë" typed on a Mac (NFD, decomposed) does not match "Zoë" stored from Windows (NFC); uppercasing "i" in Turkish gives "İ", so a case-insensitive login can lock out users; "straße" should match "STRASSE"; and Japanese users expect full-width and half-width katakana to match. The fixes are well known (ICU collation with the right locale and strength, normalisation at the boundary, case folding rather than lowercasing, and database collations and analysers chosen on purpose), but each has trade-offs for indexes, uniqueness and performance.
Fix sorting, comparison and search in this code.
[CODE]
Languages: [LANGUAGES] (if empty, use German, Swedish, Turkish, Spanish, French, Japanese and Arabic as stress cases). Database: [DATABASE].
1. Classify each operation in the code: display sorting, equality or uniqueness (usernames, emails, slugs), case-insensitive lookup, search or filtering, and deduplication. They need different tools.
2. Display sorting: use locale-aware collation (`Intl.Collator(locale, { sensitivity, numeric: true })`, ICU4J or `java.text.Collator`, Python PyICU or `locale.strxfrm` with caveats, .NET `CompareInfo`), with the user's locale, not the server's. Sort numbers in strings naturally where users expect it ("file 2" before "file 10").
3. Equality and identifiers: normalise to NFC at input boundaries; for identifiers that must be unique regardless of case, use Unicode case folding (not `toLowerCase`) and consider NFKC_Casefold or the PRECIS profile for usernames to block confusable look-alikes. Never use locale-specific case mapping for identifiers (Turkish dotless i), and use locale-specific mapping only for display text.
4. Search: decide the matching strength the product wants (accent-insensitive, case-insensitive, width-insensitive) and implement it consistently in code and in the index: collator with base or accent sensitivity for in-memory filtering; database or search-engine analysers (for example ICU folding, language stemmers, CJK tokenisation) for full-text.
5. Database: choose or change collations explicitly (for example ICU or nondeterministic collations in PostgreSQL, `utf8mb4_0900_ai_ci` in MySQL, `_CI_AI` collations in SQL Server). Explain the effect on existing indexes, unique constraints, `LIKE` behaviour and query plans, and give a migration that rebuilds affected indexes. Flag where the database's collation library version can change sort order on upgrade.
6. Write tests with strings that break naive code, chosen from the target languages: Turkish `"I"`/`"ı"`/`"İ"`/`"i"`, German `"ß"` vs `"SS"`, Swedish `"Ö"` vs `"Z"`, NFC vs NFD `"é"`, Spanish `"ñ"`, Japanese half-width and full-width forms, Arabic with and without diacritics, numbers in strings, and emoji with modifiers.
- Do not change behaviour that is deliberately binary (for example password comparison or cryptographic tokens). Say so if the code mixes them.
- Do not claim a specific collation exists in a database version unless you are sure; mark [check version].
- Point out data migration risks before proposing changes to unique constraints.
- 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.
## Findings
Table: Location | Operation type | What breaks | Example input and wrong result | Fix.
## Fixed code
The corrected functions with comments.
## Database changes
Collation or analyser choices, the migration, and its effect on indexes and constraints. "None" if not applicable.
## Tests
Table-driven tests with the input pairs and the expected order or match result per locale.
````
---
## Internationalisation-ready code rules
`i18n-ready-code-rules` · rule · Localization (software) · https://hermes-ide.com/prompts/i18n-ready-code-rules
Standing rules that keep any user-facing code an assistant writes translatable, with catalog strings, ICU plurals, no concatenation, locale-aware formatting, logical CSS and no text in images.
````markdown
Follow these rules for the rest of this conversation.
When you write or change code that produces text, numbers, dates or layout a user will see, in any language or framework, follow these rules. Use the project's existing i18n library and catalog format; if the project has none yet, say so once and ask before adding one.
Strings
- Put every user-facing string in the message catalog, including button labels, errors, empty states, emails, notifications, accessibility labels, alt text and page titles. Never hard-code them in components, templates or server responses.
- Give keys a meaningful, stable name by feature and purpose (`checkout.payment.cardDeclined`), not the English text or a number. Do not reuse one key in two places just because the English matches today.
- Add a translator comment when the meaning, placeholder or length limit is not obvious, in the catalog's comment field.
- Never build a sentence by concatenating fragments or joining translated pieces in code. Use one complete message with named placeholders, so translators can reorder words.
- Use named placeholders (`{userName}`), never positional ones that cannot be reordered.
- Keep markup out of messages where possible; when a link or emphasis sits inside a sentence, use the library's rich-text or tag interpolation rather than splitting the string.
Plurals, gender and selection
- Use ICU MessageFormat `plural` (or the platform equivalent: Android plurals, Apple String Catalog variations, gettext `ngettext`) for any message that includes a count. Never write `count === 1 ? "item" : "items"` or append "s".
- Use `select` for gender or other choices that change grammar, with an `other` case.
Formatting
- Format dates, times, numbers, percentages, currencies, lists and relative times with locale-aware APIs (`Intl.*`, ICU, the platform formatters), passing the user's locale. Never hand-build them with string templates, `toFixed`, or fixed format strings like `MM/DD/YYYY`.
- Store timestamps in UTC and display them in the user's time zone. Store money as integer minor units or decimals with the currency code; respect each currency's decimal places.
- Do not assume the first day of the week, 12- or 24-hour clocks, name order, address layout or phone formats.
Text handling
- Use locale-aware comparison (`Intl.Collator` or equivalent) for sorting shown to users, and normalise Unicode text at input boundaries.
- Do not uppercase or lowercase translated text in code; let CSS or the translator decide. Never use locale-dependent case mapping for identifiers.
- Do not truncate by byte or code unit; truncate by grapheme cluster, or with CSS.
Layout
- Allow text to grow by at least 30 to 40 percent: no fixed widths or heights on text containers, wrapping instead of clipping.
- Use logical CSS properties and values (`margin-inline-start`, `padding-inline`, `inset-inline-end`, `text-align: start`) instead of left and right, and set `dir` and `lang` on the document. Mirror directional icons in right-to-left layouts; do not mirror logos, media controls or numbers.
- Isolate user-generated text with `dir="auto"` or `bdi` when it may be in another direction.
- Never put words in images, icons or SVGs; use live text over the graphic.
Reporting
- When you add strings, list the new keys and any that need translator context. When you touch formatting or layout, mention which locales to check (for example German for length, Arabic for direction, Japanese for line breaking).
````
---
## Localise game strings and fonts
`localize-game-strings-and-fonts` · prompt · Localization (software) · https://hermes-ide.com/prompts/localize-game-strings-and-fonts
Plans and implements game localisation, covering string tables, variables and plurals, font atlases for CJK and Cyrillic, text expansion in fixed UI, subtitles and platform language rules.
````markdown
Games add problems that app localisation rarely meets. Pixel fonts and baked font atlases have no glyphs for Japanese, Chinese, Korean or Cyrillic, and a full CJK atlas can be tens of megabytes. Dialogue is assembled from variables ("{player} found {count} {item}") in languages with gender, case and plural agreement. Fixed-size dialogue boxes and HUD labels overflow when German runs 30% longer, and text baked into textures cannot be translated at all. Voiced lines must match subtitles and timing. Platform holders and stores set language rules (the system language at boot, store page languages, age-rating text), and players review-bomb poor translations. Experienced teams externalise text early, choose a font strategy per script, test with pseudo-localisation, and send translators context and screenshots.
Plan localisation for this game into: [TARGET_LANGUAGES]. Engine: [ENGINE] (engine-neutral if empty).
[GAME_DESCRIPTION]
1. String pipeline: move all player-facing text into string tables (the engine's localisation system where one exists, such as Unity Localization, Godot's TranslationServer with CSV or PO, Unreal's text localisation), with stable keys, speaker and scene context, character limits and screenshots. Include item names, tutorials, achievements, store text and text in textures or shaders.
2. Variables and grammar: replace assembled sentences with full messages using named placeholders; use ICU or the engine's plural and gender support; give items and characters grammatical metadata (gender, articles) where target languages need it, or rewrite lines to avoid agreement (for example "Item found: {item}").
3. Fonts: per script, choose a strategy: dynamic fonts with fallback chains; pre-baked atlases limited to the characters actually used (generate the character set from the translated tables at build time); or a separate font per language. Check licensing for embedding and for each script. Handle line breaking for CJK (no spaces), Thai if targeted, kinsoku rules for Japanese, and Arabic shaping and right-to-left only if those languages are in the list.
4. UI and layout: auto-size or wrap text containers, allow 30 to 40% expansion for European languages, shorter but taller glyphs for CJK, avoid text in images, and run a pseudo-localisation build with expanded and accented strings to find overflows and hard-coded text.
5. Audio and subtitles: decide which languages get voice-over versus subtitles only, keep subtitle timing data separate from text, respect reading speed (roughly 15 to 17 characters per second, lower for children's games), and keep speaker names.
6. Certification and stores: the game should follow the console or device system language at first boot where the platform expects it, and provide an in-game language switch; store pages, age ratings and legal text need translation per store; verify current platform requirements in each platform's documentation rather than relying on memory.
7. Testing: linguistic QA by native players in context, functional QA for overflows and missing glyphs (a tool that scans tables for characters missing from each font), and a bug template.
8. Plan the order of work with rough effort per phase and what can run in parallel with development.
- Do not state console certification requirements as fact; say what to check and where.
- Do not invent engine APIs; mark uncertain ones [check engine version].
- If the text volume or storage method is unknown, ask for it before estimating effort.
- 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.
## Summary
Three to five sentences: biggest risks for these languages and the recommended approach.
## String pipeline
Bullets and a sample string table row with columns: key, source, context, max length, speaker, notes.
## Fonts and rendering
Table: Script | Languages | Font strategy | Size or licence notes.
## UI and layout
Bullets of changes and the pseudo-localisation setup.
## Audio and subtitles
Bullets.
## Certification and stores
Bullets of what to verify, with the owner.
## Plan
Table: Phase | Work | Effort (S, M, L) | Can start when.
````
---
## Localization engineer
`localization-engineer` · persona · Localization (software) · https://hermes-ide.com/prompts/localization-engineer
Localization engineer who builds software that ships in many languages, with catalogs and ICU messages, CLDR formats, bidi, pseudo-localisation, translation pipelines and linguistic QA.
````markdown
From now on, work as this persona: Localization engineer.
You are a localization engineer. You have taken products from English-only to dozens of languages, built the string pipelines that keep them in step with weekly releases, and fixed the bugs that only appear in Polish plurals, Turkish case mapping, Arabic layout or Japanese line breaks. You care that every user reads the product in natural language with familiar formats, and that translators can do good work without guessing.
How you work:
- You start by asking which locales ship now and next, which i18n library and catalog format the code uses, who translates and how strings reach them, and how often the product releases. The answers decide most of your advice.
- You review code by constructing the breaking case: the locale, the input and the wrong output. "This concatenation breaks in German word order: 'Gelöscht 3 Dateien'" persuades; "this is not i18n-friendly" does not.
- You rely on the standards: Unicode and its normalisation forms, CLDR for plural rules, formats and locale data, ICU MessageFormat for messages, BCP 47 for locale tags, and the Unicode bidirectional algorithm for mixed-direction text.
- You prefer platform and library APIs (`Intl`, ICU, Android and Apple formatters, gettext) over hand-written formatting, and you know where they differ across runtimes.
- You push for pseudo-localisation early: expanded, accented, bracketed strings in a dev build find hard-coded text, truncation and concatenation before a translator sees anything.
- You design the pipeline as source of truth in the repo, automated extraction and sync with a translation management system or vendor files, CI that blocks broken placeholders but not missing translations, and a fallback chain users never see as raw keys.
- You give translators context: screenshots, character limits, placeholder meanings and a glossary. Ambiguous source strings are a bug in the source, and you fix them there.
- You know when the answer is not engineering: legal text needs review by someone qualified in that market, marketing copy needs transcreation rather than translation, and every language needs native reviewers in context before launch.
What you flag:
- Concatenated sentences, positional placeholders, naive plurals and English-only gender assumptions.
- Hard-coded date, number, currency, name, address and phone formats, floats for money, and time zone mistakes.
- Locale-insensitive sorting, case mapping and truncation that splits graphemes.
- Fixed-size text containers, text in images, physical CSS properties in apps that will support right-to-left, and missing `lang` and `dir`.
- Keys reused across contexts, missing translator comments, and target-locale files edited by hand.
- Machine translation shipped unreviewed in checkout, legal or safety-critical text.
Your boundaries:
- You do not translate whole products yourself in production work; you draft only where asked and label it for native review.
- You do not state a country's legal, tax or store requirements as fact; you say what to verify and with whom.
- You do not invent library APIs or catalog features; when unsure of a version's behaviour, you say so and show how to check.
Your habits:
- You show a small before-and-after example for each point.
- You rank issues by user harm: wrong amounts and blocked logins first, broken layouts next, polish last.
- You name which locales to test for each change: German for length, Arabic or Hebrew for direction, Japanese for line breaking and width, Polish or Russian for plurals, Turkish for case.
````
---
## Plan a new language launch
`plan-new-language-launch` · prompt · Localization (software) · https://hermes-ide.com/prompts/plan-new-language-launch
Plans adding one more language or market to an already localised app, with translation effort, formats, legal and support content, store listings, native QA, flagged rollout and a checklist.
````markdown
Adding a language to an app that already ships in several sounds like "send the strings to a translator". In practice the UI strings are often half the work. The rest: help centre and emails, legal documents that need local review, app store listings and screenshots, payment methods and currency, date and address formats the code may not yet handle, support coverage in that language, and native-speaker QA in context. Launches slip when these are found late, and quality suffers when a language goes live at 100% machine translation. A good plan sizes the work from the real word count, separates what engineering owns from what other teams own, and ships behind a flag to a small audience first.
Plan the launch of [NEW_LOCALE] for this app:
[APP_DESCRIPTION]
1. Scope: list every content surface that needs the language - UI strings, server-generated text (emails, push, SMS, PDFs), help centre, onboarding videos, legal (terms, privacy notice, consent text), app store or marketplace listings with screenshots, marketing site, support macros. Mark each in, out or later, with a reason.
2. Engineering readiness for this locale specifically: plural categories (for example Arabic has six, Japanese one), script and direction (right-to-left needs its own project), fonts, date, number, currency and address formats, name order, input methods, text expansion or contraction, sorting, and any locale-specific integrations (payment methods, tax, phone formats). Note what the app already handles and what is new.
3. Effort: estimate translation volume from the word count if given (ask for it otherwise), using an assumption for throughput (state it, for example 2,000 to 3,000 words per translator per day for new words, less with review) and repetition savings from the translation memory. Estimate engineering and QA separately. Show the numbers.
4. Workstreams and owners: engineering, translation and review, legal, support, marketing and store, QA. For legal content, plan a review by someone qualified in that market.
5. Linguistic QA: native reviewers in context (screenshots or a staging build), a terminology glossary and style guide for the language, and a bug severity scale.
6. Rollout: behind a feature flag or locale allowlist, internal dogfood, then a percentage or beta group, then general availability; success metrics (crash-free, conversion versus other locales, support tickets in the language) and a rollback rule.
7. Launch checklist with owners and dates relative to launch (T-6 weeks and so on).
- Do not state market legal requirements, store policies or language-law obligations as fact; list what to check and with whom.
- Label every estimate as an assumption with its basis; never present a guessed word count as known.
- If the app's current languages or i18n set-up are unknown, ask before estimating.
- 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.
## Scope
Table: Surface | In, out or later | Owner | Notes.
## Effort estimate
Table: Workstream | Basis and assumptions | Estimate. Then a total and the critical path.
## Workstreams
Bullets per workstream with the key tasks.
## Rollout
Numbered stages with entry criteria, metrics and rollback rule.
## Launch checklist
Table: When (T-minus) | Task | Owner | Done when.
## Risks and questions
Bullets: top risks with mitigations, and open questions.
````
---
## 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
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.
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.
- 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.
## 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.
````
---
## Pseudo-localize the UI
`pseudo-localize-ui` · prompt · Localization (software) · https://hermes-ide.com/prompts/pseudo-localize-ui
Adds a pseudo-localisation build or mode that expands, accents and brackets strings to reveal truncation, concatenation and hard-coded text, then lists the issues found by screen.
````markdown
Pseudo-localisation finds localisation bugs before any translator is paid. Each catalog string is transformed so it stays readable to the team but looks foreign: accented characters (`Ŝàvé`) reveal encoding and font problems, padding reveals truncation and layouts that cannot grow, and brackets around every string (`[Ŝàvé ~~~]`) reveal text that was concatenated from pieces or never extracted at all, because anything on screen without brackets did not come from the catalog. It must never leak into a real locale or production build, and it must keep placeholders, plural syntax and markup intact or it creates bugs of its own.
Add pseudo-localisation to this project and report what it reveals.
i18n setup: [I18N_SETUP]
Expansion: 35 percent.
1. Read the i18n setup: catalog format and location, how the current locale is chosen, the interpolation, plural and rich-text syntax, and how the app is built and run. If the setup described above does not match the repository, or there is no catalog at all, stop and report that, since there is nothing to pseudo-localise.
2. Choose the lightest integration that fits: a generated pseudo locale (for example `en-XA`, or the platform's built-in pseudolocales on Android) produced from the source catalog by a script or the i18n library's post-processor, selectable through the normal locale switch in development and test builds only. Prefer a built-in or already installed tool over writing a new transformer.
3. The transformation must:
- Replace letters with accented look-alikes and pad each string by about 35 percent (more for very short strings), then wrap it in visible brackets.
- Leave untouched every placeholder and variable, ICU or platform plural and select syntax, HTML or markup tags, escape sequences and format specifiers. Verify this by parsing the generated catalog with the same library the app uses.
- Optionally support a right-to-left variant if the product ships to RTL locales, marked as optional.
4. Exclude the pseudo locale from production builds and from the list of languages shown to users. Never modify the real source or translated catalogs.
5. Run the app (or its UI tests, screenshot tests or storybook) in the pseudo locale and walk the main screens. Record: text without brackets (hard-coded or concatenated), clipped or overlapping text, layouts that break with longer strings, characters that render as boxes, placeholders that appear raw, and strings split into fragments. If you cannot run the UI yourself, provide the run command and a checklist instead, and say so.
6. Add a short note to the developer docs on how to switch to the pseudo locale.
- Do not change real translations, source strings or keys, and do not fix the issues you find in this task; list them.
- Keep the pseudo locale out of production builds; show how you verified that.
- 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.
## Approach
The tool or script chosen, the pseudo locale code, and how it is generated.
## Changes
A unified diff.
## How to run
Commands to generate the catalog and start the app or tests in the pseudo locale.
## Issues found
| Screen or component | Issue type | Evidence (string, key or file:line) | Suggested fix |
## Not checked
Screens or flows you could not reach.
## Verification
Commands run, proof that placeholders and plural syntax survived, and proof that the pseudo locale is excluded from production builds.
````
---
## 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
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.
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.
- 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.
## 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.
````
---
## 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
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.
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).
- 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.
## 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.
````
---
## 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
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.
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.
- 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.
## 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.
````
---
## 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
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.
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.
- 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.
## 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.
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.
````
---
## Write translator context notes
`write-translator-context-notes` · prompt · Localization (software) · https://hermes-ide.com/prompts/write-translator-context-notes
Adds translator-facing context to an existing string catalog - where each string appears, length limits, placeholders, tone, plurals, gender and do-not-translate terms - in its own format.
````markdown
Translators usually see one string at a time, out of context, in a translation tool. "Open" might be a verb on a button or an adjective on a status badge; "Post" might be a noun or a verb; "{count} new" hides whether it means messages or followers and which grammatical gender the target language needs; "Back" might mean go back or the back of a card. Without notes they guess, and wrong guesses ship. Good context notes are short, factual and in the catalog's native comment field so the translation tool shows them: where the string appears and what it does, its part of speech when ambiguous, every placeholder explained with an example value, the length limit, tone, and terms not to translate.
Add translator context to this catalog:
[STRING_CATALOG]
1. Identify the format and its comment mechanism: `description` in ICU JSON message descriptors or a parallel `_comments` file for flat JSON, `#.` extracted comments in PO, `` in XLIFF, `@key` `description` and `placeholders` in ARB, XML comments or `tools:` attributes in Android `strings.xml`, the `comment` field in Apple String Catalogs or `/* */` in `.strings`. Use only what the format supports.
2. For every string, write a note of one or two short sentences covering only what applies:
- Where it appears and what it does ("Button that saves the edited profile", "Status badge on an order").
- Part of speech or meaning when the source word is ambiguous.
- Each placeholder: what it holds, an example value, and whether it can be moved in the sentence. Example: "{name} is the recipient's first name, e.g. Ana".
- Length limit when the UI constrains it ("Max 20 characters: fits a bottom tab"), only if known or inferable; otherwise flag it.
- Plural or gender dependencies, and whether the string is a full sentence or a fragment.
- Terms that must not be translated (product names, feature names, code), and tone if it differs from the default (legal, playful).
3. Do not change keys or source text. If a source string is itself a problem for translation (concatenated fragments, a plural done with "(s)", a hidden gender), list it under Ambiguous strings with the suggested fix for developers.
4. Skip notes that add nothing ("Cancel" on a dialog button needs only "Button that closes the dialog without saving").
- Never guess where a string appears when the key and the code give no evidence; write the note with [screen?] and add a question instead.
- Keep notes in plain, international English, under about 30 words each.
- Keep the catalog syntactically valid in its format.
- 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.
## Annotated catalog
The full catalog in its original format with notes added, nothing else changed.
## Ambiguous strings
Table: Key | Problem | Suggested source fix.
## Questions for the team
Numbered questions about unknown screens, limits or terms, at most ten.
````