Give each message a clear contract¶
A translator needs to know what a message means, when it appears and which parts the application supplies. Keep that information with the resource through translation, review and import. A spreadsheet containing only keys and English text can lose the distinction between a command, a property and a result.
Use this page when preparing a translation batch. The shared messages and variables guidance explains complete messages and format syntax; the principles establish FontLab terminology and space constraints.
Identify the meaning, then the string¶
Give each resource a stable identity and a specific purpose. Two controls can both say “Open” in English while one names an action and the other describes a contour. Sharing their text would force unrelated meanings into one translation. Reuse a resource only after checking meaning, grammatical role and context.
A changed operation needs a translation review even if its key stays the same. If a command changes from removing a glyph from a selection to deleting it from the font, the old translation cannot be approved by an unchanged key. Record the source revision and explain the behavioral change. Translation memory can suggest wording; it cannot establish that the old wording still describes the operation.
Keep the resource identity separate from its displayed text. Renaming a key is an engineering change that must preserve its references. Do not delete a translation solely because a literal search finds no use: some resources are selected through feature names, generated code or runtime values.
Supply context that answers a real question¶
For an illustrative export-status message, a useful handoff looks like this:
| Field | Information to provide |
|---|---|
| Identity | Stable resource key and source revision |
| Trigger | Export has finished; count includes only successfully written files |
| Purpose | Status sentence, separate from any error explanation |
| Count | Nonnegative integer; whether zero can reach this message |
| Destination | Folder path supplied by the application; preserve its contents |
| Related text | Progress status, partial-failure message and recovery action |
| Surface | Screenshot and actual available space in the status area |
| Review | Build, locale, representative values and unresolved decisions |
This is a documentation example, not a declaration of FontLab resource names or export behavior. Fill in the actual product contract before translating. “Count” alone would leave the translator guessing whether it means fonts, instances, glyphs or files. A screenshot alone would not explain a zero or failure case.
State whether each value is user text, a literal identifier, an already localized label or a quantity that needs formatting. Include its allowed range, unit and empty-value behavior where relevant. Do not infer grammatical gender or case from one sample name. If substitutions require different grammar, supply complete message choices supported by the product's established message system.
When a message identifies a file, glyph or resource, preserve the supplied identifier's spelling and case. Use the surface's normal code or emphasis style to distinguish it from the explanation. Uppercasing a path for emphasis can mislead the reader and spoil a copied value.
Review every supported branch¶
Keep enough of each alternative together for a translator to control agreement and word order. ICU recommends full sentences within plural or selection branches where possible. Use the actual engine's parser and documented syntax; a pattern that looks like ICU is not proof of compatibility. See ICU message formatting.
Plural category names such as one and few are locale-dependent selectors,
not fixed numeric intervals. Test the categories required by each target locale,
including larger values and fractions when the input permits them. Ordinal
messages need their own cases. A special message for exactly zero is a separate
choice from assuming that the locale has a zero category. Consult the
CLDR plural rules.
Choose cases from the real input domain. An exported-file count needs whole numbers; a measurement may allow fractions. Verify the entire rendered message for each case, including the number's display precision. A correct category selection does not establish that the surrounding noun and verb agree.
Preserve placeholder identifiers and format syntax. Reordering or repeating a value can be valid when the parser permits it; changing its identity or meaning is not. Check missing and unexpected arguments, type changes, escapes and markup with the product's parser. Counting braces or tags cannot establish a valid message with nested choices or elements.
Keep the checks distinct¶
| Check | What it establishes |
|---|---|
| Resource parsing | The catalog and message syntax can be read by the intended tools |
| Argument contract | Supplied values match the message's required inputs |
| Resource delivery | The requested feature actually loads the intended language |
| Language review | Meaning, terminology and grammar are correct in context |
| Interface review | The complete result remains readable and usable in its surface |
Typed resource keys can catch some mistakes during development, depending on the library and its configuration. They cannot approve a translation or prove that a catalog reaches a released application. For example, i18next documents separate options for resource typing and strict key checks in its TypeScript guidance.
Test the expected text, branch and actual language. An assertion that the result is a string could pass for an untranslated key. Treat an intentionally empty message, an absent entry, an unloaded catalog and a fallback as different outcomes. Record why an empty value is allowed; do not silently use it as evidence that translation is complete.
Carry review decisions back into the product¶
When a translation returns, compare it with the source revision supplied to the translator. Resolve changed meaning and argument contracts before importing it. Keep terminology decisions in the canonical language data, with their existing approval status. Keep resource-specific context with the corresponding message.
Recheck the imported result in the working interface, including messages reached only after an error or a delayed operation. Accessible names, validation details and loading states belong in the same coverage. Record cases as passed, failed or not checked; an empty failure list does not prove that review happened. Use the runtime review to retain reproducible evidence.