To translate an iOS app with Xcode string catalogs, first identify the exact .xcstrings catalog and the Swift or Objective-C code that supplies its strings. Translate the user-facing text, preserve the message identity and formatting variables, complete the necessary plural or device variants, then build and test the app in the target language. A successful translation is the text the user actually sees, not merely a green mark beside a row in a localization editor.
If you are searching for Xcode .xcstrings translation, iOS string catalog localization, or how to translate an iPhone app without breaking placeholders, the fastest safe route begins with a small functional sample. Choose a button label, an interpolated message and a pluralized sentence. Trace each from the source through the string catalog to the running app. Once those three examples work, you can scale the workflow and use automated checks for the structural risks.
Apple string catalogs bring localizable content together, support language variants and make localization visible in Xcode. They do not remove the need to understand meaning, grammatical variation, programmatic arguments, resource ownership or release behavior. This guide explains those layers step by step, including extraction, context, XLIFF exchange, source changes, merge conflicts, QA, accessibility and review.
What a string catalog actually owns
An .xcstrings file is an Xcode string catalog, commonly named Localizable.xcstrings. It helps organize strings by key, source language, target language and variations. The readable project file is structured data, but the normal editorial surface is Xcode’s string catalog interface. Developers and localization systems can also work with exported resources. The safest editing route depends on project automation, the Xcode version and the teams responsible for language and code.
Think in three layers. The application code asks for a localizable message. The string catalog associates that message with its localized variants. The platform formats and displays the result for the selected language and context. A translator can make the middle layer fluent yet still fail the user if the code requests the wrong key or formats an argument incorrectly. A compiler can verify part of the contract without knowing whether the sentence is true.
Before changing a single file, establish the application’s development language, supported localizations and source-control revision. Then identify whether strings come from SwiftUI, UIKit, a localization table, another module, a package or a resource generated through tooling. A project can contain several catalogs, so the first catalog that happens to open may not own the screen you intend to translate.
Build the project to discover localizable text
Xcode string catalogs can gather many localizable strings from code when the project is built. In SwiftUI, supported localizable string literals in views may be discovered automatically. Other code paths require explicit localizable APIs or configuration. Do not assume that any English sentence in a repository will appear merely because a string catalog exists.
Use a development build to populate the catalog, then inspect a representative screen. If its visible label is missing from the catalog, trace the code. It may be an ordinary string not passed to a localization-aware API, an image containing text, a server response, a storyboard property, or a value managed by another localization system. Translation tools cannot translate something they never receive.
The first useful output is an inventory of localizable strings with their code or screen context. Mark which entries are new, which have established translations and which appear unused. Do not interpret every disappearance after a build as permission to delete a target entry; investigate whether the source was renamed, moved between catalogs or excluded by the current configuration.
Distinguish the visible English phrase from message identity
Some localization APIs use an English-looking string as the key, while others use stable identifiers that are separate from the displayed text. The difference matters when source copy changes. If a source-language sentence functions as the lookup identity, a small rewrite may be treated as a new message and leave old translations stranded. If an identifier is stable, the same rewrite may instead require an explicit re-review of the existing translations.
Record what the application actually passes to the localization API. Do not rename an identifier or rewrite a source phrase in the catalog independently of code. If developers intentionally change the message identity, migrate all references in a controlled update. If the source wording changes but meaning stays stable, confirm which translation workflow associates old and new entries.
Generated localizable symbols can help code refer to catalog entries in a type-aware, discoverable way. But generated symbols also mean that a resource key can become part of a compilation contract. Treat identifier changes as engineering work. Translators should control target-language meaning; developers should control identifier migration and lookup behavior.
Establish a reliable source language
A catalog has a source language or source localization context. Translators need to know whether the English shown in Xcode is a final editorial source or a provisional product draft. If it is provisional, target-language work may become outdated within hours. Flag uncertain source messages before approving their translations.
Choose one owner for source meaning. If a billing screen uses both charge and payment for different operations, the product team should explain the difference. If a security warning is ambiguous about whether an action is irreversible, resolve that ambiguity before translation. It is faster to fix an unclear source once than to correct its consequences across ten languages.
Record revisions. Each target approval should state the source version it was checked against. When the source changes, mark dependent translations for review even if Xcode retains their values. A stale translation can be grammatical but now inaccurate because the product behavior or legal promise has changed.
Use localization comments to reduce guessing
A short string without context is risky. Continue could refer to moving to another page, resuming a paused transfer or approving a payment. A translator needs the action, audience, screen and consequences. Add comments to the localizable API where possible, or provide accurate notes in the workflow. Apple provides ways to create or generate comments, but generated notes should still be checked for reliability.
The best comment is specific. Instead of saying button text, say that tapping this button sends the user to the review screen without submitting the form. Instead of saying success message, say that the file has been uploaded and the user can close the dialog. This lets the translator preserve the intended degree of certainty and commitment.
Attach screenshots for difficult strings and include the previous or next message if interpretation depends on it. For a target language that distinguishes formal and informal second person, declare the product’s tone rather than letting each translator improvise. Language consistency begins with clarity about the task, not with a glossary of isolated words.
Identify literal strings that should not be localized
Not every character sequence is intended for translation. Technical identifiers, protocol parameters, internal codes, file extensions, some trademarks and values consumed by another system may need to remain unchanged. Conversely, a filename displayed as explanatory text might need an accessible localized label while the underlying machine filename stays fixed.
Tag each resource according to its purpose. For instance, the word Cancel on a button should almost certainly be localized, while a JSON key named cancel_action may be a stable machine identifier. A product name can stay the same, yet an adjacent instruction must be fluent in the target language. If a service returns an English status code, translate the user-facing explanation rather than mutating the machine code.
Blindly translating string catalogs as dictionaries can blur this distinction. A controlled inventory should list which values are language, which are protected tokens and which contain both. Review unusual entries with engineering rather than assuming all data inside a catalog is safe prose.
Treat interpolation as a functional part of the sentence
A message such as You have 4 new files may be assembled from a localizable string and a runtime value. Xcode and the platform can represent such messages using format specifiers and string interpolation. The format tokens are not optional decoration; they are how the application inserts the correct value at runtime.
Preserve the argument’s identity and type. A placeholder for a file count cannot be replaced with one for a person’s name, and a number cannot be silently converted into a different value. The target language may place the variable earlier or later. That can be legitimate, but the formatting mechanism must still identify the intended argument.
Use a small set of test inputs: an empty name, a long name, a value of one, a larger value and any unusual characters relevant to the app. Observe the actual output, not just a static editor field. Dynamic input often exposes grammatical and formatting mistakes that a fluent placeholder-free translation would never reveal.
Learn the meaning of format specifiers before moving them
Apple application strings may include percent-based format specifiers such as %@, %d or %lld, depending on the API and argument type. These tokens interact with runtime formatting. Translators need an annotation that says what each argument means and whether its position may move. Editors should not normalize every percent sign or substitute a familiar token from a different framework.
Consider a notification with two arguments: a person’s name and a count of shared files. A target-language sentence may naturally begin with the count. It is not enough to move the surrounding words if the inserted arguments remain in source order. The correct fix may require supported positional format specifiers or a restructured localization resource, validated by the application.
Distinguish a literal percentage from a formatting token. A screen that says 20% off is different from a message whose discount percentage is calculated at runtime. A testing process should verify both cases. Correct formatting is a property of the code and localized resource working together.
Give plurals their own translation treatment
Pluralization is one of the reasons string catalogs matter. English might use one and other forms for a count, but many target languages require different grammatical distinctions. In Xcode’s string catalog editor, translators and developers can manage variants for pluralized strings, with appropriate locale-specific choices.
The visible variable may be a number, but the surrounding noun, verb and adjective can also vary. A target translation should read naturally for the count that selects it. Do not assume that the English singular phrase is suitable for every target category. Do not create arbitrary forms based on the category name alone. A linguist familiar with the target language should approve them.
Testing is important because a plural branch may never appear in ordinary screenshots. Use counts such as zero, one, two, five, eleven and twenty-one when they help distinguish target patterns. Verify the selected result in the application and check that the number itself appears or does not appear according to product intent. Selection and display are two separate concerns.
Why an English two-form catalog can hide problems
A developer who tests only English might believe a message is finished when one file and five files both display correctly. That evidence does not establish correct localization into Russian, Arabic or Polish. The additional target-language categories may be missing, unreviewed or associated with incorrect words. Users encounter those branches only with particular counts.
A robust project represents plural intent in its source and gives target locales the grammar they need. Where the original code was built by concatenating a number, a space and a plural noun, a translator may not be able to express the target language naturally. Fix the data model rather than writing unnatural language into a fragile string.
Make the plural test part of the feature’s acceptance criteria. When developers add a new count-based message, provide a locale-aware test fixture immediately. This costs little compared with investigating incorrect wording after the app has reached users in many regions.
Device variants should describe a real device difference
String catalogs can vary language resources by device. A product might need Tap on a touch device but Click in a desktop context. The linguistic difference is connected to a genuine interaction, not simply an arbitrary preference for shorter words. Write each variant to match what the user can actually do.
Do not multiply variants when the meaning is the same. Too many unnecessary copies create review overhead and raise the chance of inconsistent wording. On the other hand, reusing one instruction for a touchscreen and a keyboard-only interface can mislead readers. Decide variation based on user action, device affordance and UX intent.
When a message varies, test both device paths. A translation completed in the iPhone branch may still be missing from a Mac branch. Record which platform and interaction each variant serves. Translation should preserve behavior-specific instructions without inventing different product promises across devices.
Be cautious with width-specific legacy approaches
Older Apple localization workflows included width variants for different screen sizes. Modern guidance emphasizes adaptable interfaces and device variation through contemporary string catalog tools; Dynamic Type and responsive layout remain important. Do not solve a width problem simply by deleting meaning from the target sentence.
If a legacy .stringsdict or another system carries width variants, identify whether the deployed app still uses them. A short label and a long label may have different appropriate translations, but both should be understandable. Do not infer from a short resource that the action itself is less important. Test both widths and font-size settings before signing off.
Ideally, the UI allows natural language to wrap or adjust. When constrained text truly requires a shorter form, ask the product owner to approve an abbreviation or alternative phrase. Keep the full meaning available through appropriate accessibility or context rather than relying on an unexplained truncation.
Understand .strings and .stringsdict alongside .xcstrings
A project may still contain legacy .strings files or .stringsdict property lists. These are not automatically mistakes. Existing code and workflows can depend on them, and Xcode may extract or export content from multiple localization resource types. Before migrating, map which one owns each message and whether any localization is being duplicated.
The .strings format commonly associates identifiers with localized values. A .stringsdict provides structured variants such as plurals in legacy workflows. A string catalog can centralize many equivalent tasks through Xcode’s editor. But copying values across file types without reviewing their role can lose information or create competing definitions.
Migration should be a controlled engineering project. Test representative messages before and after, including plural behavior, formatting, source changes and fallback. Preserve translator comments and established terminology. Do not delete legacy resources merely because a new catalog appears. Confirm the application no longer loads or relies on them.
Export and import through a controlled localization handoff
Xcode supports exporting localizations for translators, including an .xcloc localization package with localizable material and XLIFF content. This gives external language teams a more appropriate exchange format than editing project files without context. Export from a known source revision and retain that snapshot.
A translator needs the language, intended region, glossary, screenshots and formatting notes. The exported package may contain source references and comments, but its usefulness depends on whether the development team provided meaningful information in the first place. Ask for an example of an actual screen when a short label remains ambiguous.
On import, verify the target language and source revision. Do not automatically accept every returned package into the release branch. Validate its XML or other structural content, review changed strings, integrate into the app and run tests. A file accepted by an import workflow is not necessarily a correct final user experience.
Avoid editing generated material without knowing its owner
Generated content can be overwritten when Xcode rebuilds or refreshes string catalogs. If a translator edits the wrong generated representation, a later build may erase that work or create large unexpected diffs. Establish which files are authoritative and which are temporary exports before editing.
Ask how the team manages catalog changes in source control. Is the .xcstrings file committed? Are localization packages stored separately? Is a translation management system synchronizing target text? Do automated scripts merge fields or rewrite ordering? These decisions affect where a change belongs and how to verify that it survives the next build.
The safest approach is to make the smallest authorized change in the owning layer, then run the ordinary development pipeline. Review the resulting diff. If many unrelated keys or states move, stop and investigate the tooling rather than approving a vast file rewrite that no reviewer can understand.
Read status indicators as workflow clues, not proof of quality
Xcode shows information about whether translations are new, updated or otherwise need attention. These indicators can guide review, but they are not a substitute for verifying meaning and runtime behavior. A message can be marked translated yet still contain a wrong noun, an untranslated placeholder or an obsolete product claim.
Conversely, a message may require review because its English source changed even when the previous target wording remains appropriate. The right action is to compare meanings and record a decision. Re-translating automatically can introduce needless variation and undo preferred terminology.
Define what approval means. For a high-impact permission message, approval may require linguistic review, legal sign-off and UI testing. For a simple decorative heading, a lighter process may be appropriate. Workflow state should represent evidence and ownership rather than a vague feeling of completion.
Set the right regional scope for every target
Spanish for Spain and Spanish for Mexico are related but may differ in common vocabulary, punctuation choices, formality and product conventions. Portuguese for Brazil and Portuguese for Portugal can diverge significantly for familiar UI terminology. A language tag is therefore not merely a directory label; it is part of the target audience definition.
Choose language and region combinations intentionally. If the app serves one broad-language translation, be transparent about that choice and test the fallback. If it requires regional differentiation, provide region-appropriate terminology and examples. Do not copy one market’s legal or payment wording into another without checking its truth.
A target-language reviewer should know which users are being addressed. A product team should know which fallback behavior occurs on devices whose language or region combination lacks a dedicated localization. Verify the actual route on an app or simulator, not only the label shown in the editor.
Test runtime language selection rather than assuming a target is active
A string catalog can contain a complete French translation while an app still displays English because the device, app language preference, development-region fallback or code path does not select it. To investigate, first determine the effective app localization. Then check which bundle and table supplies the target string.
Use one unmistakable test string in a development environment to prove the route. Open the exact screen where the string should appear and record the result. Remove the test marker before release. This separates a missing-translation problem from a lookup problem, which saves repeated linguistic edits that cannot affect runtime behavior.
Test common language changes, including after app restart if required by its design. Observe whether cached content or server-provided messages remain in another language. A complete string catalog cannot guarantee a complete localized experience if other systems display independent text.
Test the interface under text expansion
Translated strings can be longer than source strings. German compounds, French explanatory phrases and languages with different line-breaking rules can expose fixed-size controls. Do not compensate by translating less of the instruction or removing conditions that users need to understand.
Use Xcode and simulator tools to inspect representative screen sizes, text size settings and orientations. Verify buttons, navigation bars, alerts, onboarding flows and forms. If content truncates, identify whether the problem belongs to the copy, layout or an intentionally constrained product label. In most cases, layout should adapt to meaningful content.
Pseudo-localization can reveal fragility early, but it cannot judge natural target-language grammar. Follow it with real localized screenshots. Include both a short user name and a long one, large numeric values and visually demanding scripts where relevant.
Respect right-to-left text and mixed-script values
A right-to-left language may appear alongside Latin URLs, serial numbers, trademarks or payment identifiers. Unicode’s bidirectional behavior can produce surprising visual arrangements around punctuation. Avoid fixing these issues by inserting arbitrary invisible marks into every translation string without understanding the rendering layer.
Test the actual UI with realistic data. Confirm that account numbers retain their intended sequence, links remain tappable, and punctuation appears with the correct part of the sentence. For localized text containing dynamic content, use platform-appropriate bidi handling where the code can isolate the value safely.
Distinguish visual layout mirroring from text translation. An app may need to reverse navigation direction or adjust icon placement separately from the language catalog. A fluent Arabic sentence does not mean the whole interface is accessible or appropriately oriented.
Treat accessibility strings as part of the release
A button may show only an icon while a VoiceOver label describes its purpose. If the label is untranslated or misleading, a user relying on assistive technology receives an inferior experience even when the visual UI looks perfect. Locate descriptions, hints, state announcements and alternative image explanations owned by the project.
Listen to the completed screen with VoiceOver in the target language where practical. Check whether abbreviated labels are pronounceable, whether placeholders are spoken as real values and whether important status changes are announced. A translated alert that omits the consequence of a destructive action can be more harmful than a clipped decorative subtitle.
Accessibility review also tests clarity. If an experienced speaker cannot understand the target label when hearing it without surrounding visual context, the wording may depend too much on an English-specific convention. Improve the message rather than treating assistive technology as an afterthought.
Keep product terminology consistent across catalogs
An app can have separate catalogs for the main interface, notifications, onboarding, settings or embedded frameworks. Users experience them as one product. If one catalog translates workspace differently from another, the user’s mental model becomes unstable, especially when the same concept appears in instructional text and button labels.
Build a concept-based glossary. Define what workspace, project, team, subscription and account actually mean in the product. Include prohibited alternatives and examples where a similar English word refers to a different concept. Provide grammatical variants where the target language needs them rather than insisting on one literal word in every context.
Review terminology in real user journeys. A person may begin an operation on one screen and complete it on another. Consistency should help them recognize the same object, but it should not force awkward grammar. A shared terminology owner can resolve conflicts faster than separate translators working from screenshots in isolation.
Handle dates, currencies and measures outside sentence templates
An iOS string might contain a price, date or quantity. The target sentence must preserve the meaning of the event, while the platform should format dynamic values for the user’s locale. Hardcoding English month order or decimal separators inside a sentence can produce inaccurate or confusing results.
Separate the responsibilities. Code or formatting utilities should deliver correctly formatted data, while the localized message controls how the data is integrated into natural language. A translation should not alter the underlying transaction amount or currency code. A localized numeral may look different without changing its numeric value.
Test combined outputs. A subscription confirmation can include a billing period, tax-related wording, a date and a cost. Check each separately, then read the complete message as a user would. Successful numeric formatting is not enough if the translated sentence changes whether the charge is recurring.
Protect placeholders during machine translation
AI-assisted translation can accelerate an initial language draft, but a model may rewrite a placeholder as ordinary text, add explanatory punctuation inside it or omit one because it seems redundant. These mistakes can remain invisible until runtime values are inserted. Treat format arguments as locked semantic objects rather than words to paraphrase.
Before translation, extract an inventory of tokens and their meanings. After translation, compare the tokens and check allowed reordering. Run the target through the production formatter with realistic values. Reject a fluent sentence that damages the runtime contract, even if human reviewers like its wording in isolation.
Machine translation can also create unjustified certainty, especially in warnings or permission text. A human reviewer should compare actions, conditions and consequences against the source. Speed comes from using automation for routine checks while preserving human judgment for meaning.
Build a versioned reviewer workflow
For each localization update, record the source commit, target locale, exported package, translation owner, linguistic reviewer and integration build. This does not require a giant spreadsheet. A concise issue tracker entry or structured translation platform record is enough if it can answer who approved which sentence and why.
When source text changes, review the affected targets. When code changes, retest formatting and lookup even if the translation text remains identical. When the app adds a new device variant, expand the test matrix. Avoid a workflow in which everyone assumes somebody else checked the boundary between code and language.
Define severities. A missing decorative sentence may be lower priority than an incorrect irreversible-action warning. An app crash caused by a malformed format string is a technical release blocker. An inaccurate privacy choice is a meaning and trust blocker. Different problems need different owners, but both must be resolved before users encounter them.
Validate the catalog structure in continuous integration
String catalogs are structured resources. If tooling edits their serialized form directly, validate that the structure remains parseable and compatible with the Xcode build. Compare keys, supported target languages, required entries and format arguments. Do not rely solely on a generic JSON parser, because an apparently valid document can still violate the expectations of Xcode or the application.
Integrate the resources into the project’s normal build and test pathway. Watch for unexpected changes in source keys, deleted translations, malformed variants and compiler warnings. A source-control diff should be reviewable. If a translation import rewrites hundreds of unrelated entries, investigate before merging.
Use automated checks where rules are deterministic, then reserve human attention for cases requiring interpretation. This is how a localization pipeline becomes both faster and more dependable: it avoids making expert language reviewers manually count placeholders while leaving subtle meaning decisions to machines.
Diagnose missing translations from the outside inward
Suppose a button remains English in a French build. Start at the visible screen. Identify the actual string lookup and its table or catalog. Confirm that the app is running in the expected locale. Check whether the French entry exists and has an approved value. Then inspect whether the current build included it.
Do not immediately create another French translation of the English text. That may simply add a duplicate resource unused by the application. A wrong table, stale bundle or incompatible identifier can keep the original text visible regardless of what the translator enters.
Similarly, when a user reports a malformed number in a German notification, determine whether the format occurred in code, a server response or a localized string. Repair the earliest incorrect transformation. A localized app is a chain of systems; not every symptom belongs to the catalog.
A practical case study: the wrong confirmation promise
Imagine a source button labeled Save changes and a confirmation saying Changes saved. The product later switches to a workflow in which clicking the button submits changes for approval, but the English confirmation is not updated immediately. The old target translations remain grammatically polished and are marked complete.
The real problem is not vocabulary. The app is promising that a change has been applied when it has merely been requested. Correct the source behavior and wording first. Then revise every target to preserve the difference between submitted and completed. Review any accompanying status or notification messages.
This case illustrates why translation state must be connected to source intent. A catalog can only support accurate language if product changes are reflected in the strings and their review requirements. A translation audit should ask what the user believes after reading the message and whether that belief is true.
A practical case study: plural forms in an upload screen
An upload screen displays the number of files selected. English testing confirms one file and five files. Later, a target-language reviewer notices that counts two and five require different noun forms. The catalog has only a simplistic target value, and the application is using a source sentence assembled from separate number and noun fragments.
The repair is to express the whole message through a suitable localization-aware plural mechanism. Give the translator full grammatical branches and the meaning of the count. Then test the app at values that exercise the target language’s rules. If the interface needs the number visible, check its insertion as well as the grammatical selection.
The lesson is to model meaning at the message level. Translation cannot reliably repair grammar that has been split into fragments before the message reaches the language layer.
A practical case study: an export merge overwrites reviewed copy
A language team reviews a Spanish translation in an exported localization package. Meanwhile, a developer edits the source strings and regenerates the catalog. When the old package returns, an import appears successful but creates a surprising diff and restores outdated wording.
A safer process compares the export’s source revision with the current project. It flags changed messages for review, applies unchanged approved entries where valid and escalates conflicts rather than silently overwriting newer work. The final build tests the resulting strings, not merely the import command’s success.
This is why source control and translator context matter. They allow the team to retain good work while making change visible. Fast translation is controlled reuse, not blind acceptance of old text.
Your repeatable release checklist
Confirm that the intended catalog, source locale and application code agree. Build the project to discover localizable messages, check whether the inventory covers the intended screens, and provide screenshots or comments for ambiguous entries. Preserve identifiers and the types and meanings of interpolation arguments.
Review plurals, device variants, legacy resource ownership and regional language scope. Import translations from a known revision, inspect the file diff and run the actual Xcode build. Test target-language screens, counts, long text, accessibility labels, dates, numbers, mixed-direction content and important errors.
Ask a qualified language reviewer to approve meaning and tone after the technical checks. Keep a small record of source version, target version, review status and test evidence. If a regression appears later, this makes it possible to identify the responsible stage quickly.
Frequently asked questions
What does .xcstrings mean in Xcode?
It is the filename extension used for Xcode string catalogs, which organize and manage localizable strings and variants. A common file is Localizable.xcstrings. Use the appropriate Xcode editor and project workflow rather than treating it as an ordinary text glossary.
Does Xcode translate an entire app automatically?
No. Xcode can discover many localizable strings and provide workflows for adding and managing languages, but correct localization also requires translating source content, preserving placeholders, handling plural grammar and testing runtime screens. Text from servers, images or nonlocalizable code may need separate handling.
Can a translator change a key in the catalog?
Not casually. The key may be referenced in code or generated symbols and may be part of how the application finds the resource. Coordinate identity changes with developers. The usual translation task is to edit approved target-language values, not to rename the lookup contract.
Why does a translation look complete but still show English?
Possible causes include locale selection, fallback, stale builds, incorrect table or catalog ownership, missing extraction or source changes. Trace the live lookup before adding another translation. A status indicator in the editor does not prove the application is using that value.
Are English plurals enough for every language?
No. Grammatical quantity rules vary. Use the plural forms required for the target locale and test the application’s actual selection for representative counts. The correct words and the runtime branch must agree.
Official documentation and further learning
Apple explains the current catalog editor and plural/device variants in Localizing and varying text with a string catalog. Its Exporting localizations guide describes the localization handoff, and Preparing your app’s text for translation covers localizable APIs. Check those materials against the Xcode version used by the project.
Continue with the How People Translate Quickly series index, ICU MessageFormat Plurals and Selects, Localization Build Validation and Master Art of Translation. For another platform-specific comparison, see Android strings.xml and Plurals QA.
Start with one actual iPhone screen. Locate its source message, add meaningful context, translate it, test its variables and run it under the intended locale. Repeat with a plural and a device-specific instruction. When those examples are stable, the entire catalog becomes easier to translate, review and maintain without sacrificing clarity.