Apple .strings and .stringsdict localization QA checks whether translated iOS, iPadOS and macOS resources preserve message identifiers, punctuation, format arguments and language-dependent plural behavior. If you need to localize an Apple app, review Localizable.strings translations, fix a stringsdict plural, or explain why an Xcode localization build displays the wrong wording, begin by separating the resource-file syntax from the application APIs that consume it.
An Apple .strings file generally stores quoted key/value pairs, while a .stringsdict file expresses structured variable substitution and linguistic selection rules through a property-list dictionary. Both can deliver excellent translations, but both can also compile into content that is missing at runtime, misformatted, grammatically wrong for a number, or unexpectedly replaced by a fallback locale. Correct words are only one part of the contract.
This guide explains how people translate quickly by testing the entire path: resource extraction, stable keys, translator context, punctuation and escapes, NSString-style placeholders, plural dictionaries, locale folders, Apple String Catalogs, app build validation, screen testing and release evidence. Every check is designed to let language specialists improve naturalness while giving developers confidence that the target messages still behave correctly.
Choose the actual Apple localization format before editing
An Apple application can use legacy .strings files, .stringsdict resources, modern String Catalogs with the .xcstrings extension, interface files, asset catalogs and localization provided by libraries. A single application may use several at once. Before importing files into a translation system, identify which format is authoritative for each message and how the app reads it. Editing an old file that is no longer included in the target build accomplishes nothing, even if every target translation is immaculate.
Write down the exact Xcode target, bundle, table name and locale for a representative string. A call using NSLocalizedString with a default table name does not necessarily search the same resource as a call using a named table or a dependency bundle. The human-facing text can be identical while the lookup path differs. A robust inventory records the lookup key, table, bundle and source-code reference rather than only the English phrase.
Do not convert all formats at once just because a newer approach exists. A migration from .strings to String Catalogs should have a separate plan, validated key equivalence and support for the deployed toolchain. During an ordinary translation release, limit changes to the approved source of truth. This prevents a localization task from silently becoming an application architecture change.
Read .strings as a structured file, not a bilingual list
Traditional .strings entries commonly resemble a quoted key, an equals sign, a quoted value and a semicolon. That syntax matters. A translator who removes the semicolon, damages the closing quote or inserts an unescaped quotation mark can turn one valid entry into a file the build cannot process. Comments may sit between entries and provide meaning or usage notes. None of these structural characters should be treated as expendable decorative text.
Use a parser or the Apple toolchain to verify every delivered target file. A simplistic text split on equals signs can misread values containing equals signs, and a regular expression built only for one formatting style can miss valid alternate whitespace or comments. An import filter should distinguish quoted keys, quoted values, comments and syntax. The export must reconstruct a valid file without turning translator-facing notes into application text.
Test with an intentionally awkward entry that includes a quoted phrase, punctuation, a literal backslash, a format placeholder, non-Latin text and a comment. Round-trip through the translation environment without changing anything. If the resulting file fails to parse or gives a different value, fix the filter first. Editing thousands of segments before proving a safe round trip simply multiplies the cost of discovering the same technical defect.
Keep lookup keys stable while translating the message
A key identifies a string to the application. With a key such as account.delete.confirmation, the target-language words normally belong in the value; the key remains the stable identifier used by code. Some older applications use the source sentence itself as the key. That design makes apparently innocent English copy changes affect lookups and can complicate migration. A translation team should not normalize these cases into one assumed convention.
Build a manifest from the authoritative development-language resource and compare it with each locale. Detect required keys missing from a target, keys duplicated inside one table and obsolete target entries no longer referenced. Do not automatically delete every target-only key. Some products have conditional UI, locale-specific support messages or staged experiments that legitimately require exceptions. Those exceptions should be owned and documented rather than left mysterious.
When the source team renames a key, treat it as a versioned identity change rather than a linguistic rewrite. Translation memories can suggest the old target wording, but the new resource ID still needs approval and context. A missing key can trigger visible fallback or an untranslated identifier; test which behavior the application actually implements. Stable keys make future releases faster precisely because translation and application lookup remain separately auditable.
Distinguish source comments from displayed text
Developer comments often answer questions a translation alone cannot. ‘Continue’ could be a button that advances a lesson, an action that resumes a paused download, or a sentence fragment after a person’s name. A note telling the translator where the string appears can be as valuable as a screenshot. Extract comments into translator context and preserve source-code references wherever possible, while keeping the comment itself out of the runtime value.
Source comments may also flag placeholder types, length constraints or legal approvals. If the application must display the exact name of a subscription tier, that is a product-data rule, not a preference a reviewer should invent. If a brand name is sometimes translated but not elsewhere, document the term policy by market and component. An ordinary language review can then focus on clarity rather than repeatedly resolving the same unresolved identity questions.
Protect sensitive material in comments. A developer note may include an internal issue URL, a test user, a customer quotation or a draft product code. The translation workspace might legitimately need an abstract description rather than raw confidential details. Reviewers should know what context can be carried into an external vendor system, retained in a file or shared as a screenshot. Speed and privacy are compatible when notes are deliberately prepared.
Handle quotation marks, backslashes and escaped newlines
Quoted resource values sometimes contain quotation marks, backslashes, tabs and newline escapes. A rendered string may need visible punctuation, while the source file requires those characters to be represented safely in its own syntax. Translators should see the intended on-screen output and the stored representation as separate views. That helps avoid editing a backslash merely because it looks unnatural when printed inside a text editor.
A target sentence that includes a quoted product label may need its visible quotation marks, but an unescaped quote in the file can end the stored value prematurely. Equally, a line break intended for a help paragraph may be represented as a newline escape rather than an actual physical line break within the quoted file syntax. Test with the compiler or parser, then render the message under the UI component that consumes it.
Do not assume escaping conventions from JSON, Java properties or Android XML are interchangeable with .strings. These formats each have their own grammar and toolchain. A localization platform that uses a generic ‘escaped string’ option may quietly add or remove characters incorrectly. Establish representative round-trip tests before approving the filter, and keep those tests with the product so tooling upgrades are rechecked.
Placeholder QA starts with the consuming API
An Apple localized string can include NSString-style format specifiers such as %@ and numeric conversions. A mismatch between a placeholder and the argument passed by the app can cause incorrect output or a runtime failure. The translator should know whether an argument is a person’s name, a number, a price, a date, or a complete phrase. Keeping the same count of percent signs is not enough to prove correct behavior.
Positional argument references can help support target languages that require reordered information, but the correct syntax and permitted conversions depend on the formatting APIs in use. For example, a target may need the surname before the given name. Reordering surrounding words is a legitimate linguistic improvement; changing a numeric format conversion into an object-string conversion is not automatically safe. Check the source call signature and the formatter’s behavior.
Run format tests with representative values and not merely token counts. Include a short name, long name, very large number, zero, negative values and any optional argument positions. Compare source and target argument roles, inspect output and capture exceptions. Use a parser-aware validator where available; a regex that counts %@ strings may miss positional cases or misidentify escaped percent literals. Correctness requires the format contract and a rendered example.
A literal percent is not automatically a formatter token
A translated message might discuss a sale of 20%, show progress at 75%, or print a literal percent sign in an educational example. Depending on the formatting context, percent signs may need escaping so the formatter treats them as text rather than syntax. This is separate from the .strings file grammar. An engineer should document when the application uses the value as a format pattern and when it simply displays it.
Consider a phrase such as ‘Save 10% on your next purchase’. If the app sends this through a formatting function, an unescaped percent sign can conflict with parsing rules; if it does not, changing the visible text to contain two percent signs may be a new defect. The reviewer should never guess based only on the presence of the character. Inspect the calling code or a runtime preview that exercises the exact path.
The scalable solution is typed message metadata. Annotate a message as plain text, printf-style pattern, plural rule or another defined format. Each type gets its own validation. Such annotation reduces false alarms because an educational text about format specifiers will not be mistaken for an executable pattern, while a button containing a real argument will receive the checks it needs before release.
Understand what .stringsdict adds to localization
An Apple .stringsdict resource is a structured property list that associates a localization key with a formatting pattern and one or more variable rules. It can support plural selection that is not possible with a single fixed English sentence. Its structure commonly includes NSStringLocalizedFormatKey and rule dictionaries containing NSStringFormatSpecTypeKey and NSStringFormatValueTypeKey. The rule selects appropriate text for a variable at runtime.
This means the translator edits a grammatical system, not merely a sentence. For an English message, ‘1 file’ and ‘2 files’ might look like the complete problem. Other languages may distinguish additional grammatical categories or apply their categories to non-obvious number ranges. The translation should satisfy target-language rules and the platform’s actual selection behavior, rather than copying English’s one-versus-other split into every locale.
Reviewers need to see the variable name, its numeric type, the expected user action and the number of forms the target locale actually requires. An incorrectly named rule or malformed property-list structure is a technical failure, while a plural form that reads unnaturally is a linguistic failure. Treat both seriously, but assign them to the people and validators equipped to correct them.
Plural categories are language rules, not numerical labels
Plural categories such as zero, one, two, few, many and other are names used in plural-rule systems. They are not universal shortcuts meaning exactly the number zero, exactly one and exactly two across all languages. A locale’s membership rules depend on the linguistic system and may also be affected by how decimal values are represented. Copying one language’s category pattern into another without testing can produce plausible but incorrect text.
Design a plural test matrix by locale rather than using only numbers 0, 1 and 2. Include values likely to distinguish categories, such as 3, 5, 11, 21, 101 and decimals where appropriate. The specific expected forms must come from the target language and the formatter’s supported rules; do not declare a universal mapping for every language. When a category is not used, a valid fallback is different from a missing translation.
Ask language reviewers to inspect full phrases rather than just inflected nouns. Number agreement can affect adjectives, verbs, case and surrounding prepositions. A plural rule is useful only if the entire sentence remains grammatical. In complicated contexts, a product may need a differently structured message, separate clauses or more information about the counted item. Testing output in context reveals these requirements before users encounter them.
Keep stringsdict dictionaries and variable names intact
A .stringsdict file uses structured keys that application code and formatting rules rely on. The variable in a localized format reference must match the corresponding rule dictionary. If a reviewer renames the variable in one place but not the other, the resource may parse yet fail to select the expected string. Structural validation should compare identifiers and recognized rule metadata, not just inspect the visible target phrases.
Property-list dictionaries also have types. A string element is different from a nested dictionary, and an integer type value has a different purpose from readable translation text. Translators should work through an interface that exposes editable strings while protecting keys and rule declarations. A generic translation of every XML text node is especially dangerous because it can alter reserved syntax such as the value indicating a plural rule type.
Before export, parse the returned property list, validate the required rule structure and run actual localized formatting against a reference test app or small harness. Keep the exact input count, locale and observed result in test records. If a rule is not exercised by a particular number, include test values that are. A file that merely passes XML validation has not yet proved that its linguistic rules produce the intended UI.
Preserve argument types and numeric presentation
Numbers enter localized messages in different forms. An integer count of notifications is not the same as a decimal quantity, a currency amount or a measurement. A placeholder that expects an integer must not be rewritten into a numeric conversion that silently truncates or misrepresents the input. Check what arguments are passed and how their formats are defined before translators are asked to choose wording around them.
Where possible, format dates, amounts, currencies and measurements with locale-aware APIs rather than manually translating separators or currency symbols into a fixed phrase. For example, the message should receive a formatted price or a value with an explicit display contract, not ask a translator to decide whether the decimal point belongs to every market. A carefully localized sentence can then arrange the formatted value naturally.
Formatting and grammar may interact. In some languages, a decimal count requires a different surrounding noun form than an integer. A plural test using only two whole numbers may miss this. The engineering contract should include input type, allowable range, representation of missing values and how many arguments the localized string expects. The language reviewer can then see where grammar must adapt without changing numeric meaning.
Locale folders, tables and bundle lookup
Traditional Apple localization often organizes language resources in locale-specific .lproj folders. A build also contains a development language and may use Base localization or multiple table names. A correct target file can remain invisible if placed in the wrong folder, excluded from the target, assigned to another bundle or loaded under a different table. A missing key may show source language, key text or some other fallback depending on application behavior.
Verify the runtime lookup path using a key that has a distinctive value in every relevant locale. Log the requested locale, resolved bundle, table and displayed value. Test language and regional choices important to the product rather than simply changing the simulator system language and trusting the result. A dependency may load its strings from its own bundle even while the main app uses a different selected language.
Do not rename folders or tables as part of translation unless engineering approves the change. The best QA report can distinguish ‘translation missing from target file’, ‘target file absent from packaged app’ and ‘runtime chose another locale’. These failures look similar to users but require different repairs. Accurate classification keeps teams from rewriting a good translation when the defect was actually a resource-routing problem.
Migrating to String Catalogs requires equivalence tests
Modern Xcode projects may use String Catalogs stored as .xcstrings files. These are not simply .strings files with a different extension. A catalog can express variations and localization states in a structured format. It can also integrate with source-code extraction and project workflows that differ from a legacy hand-managed resource set. Teams should establish which format the app build consumes instead of assuming that every old file remains authoritative after migration.
During migration, inventory the source keys, placeholders, plural behavior, translator comments and locale variants. Compare the old and new runtime outputs for a representative set of messages, including those that use conditional variations or plural forms. Confirm fallback behavior. A converter that preserves visible English strings but loses the plural rule has not preserved the application semantics. Equivalence means matching the user’s experience, not matching file counts.
Plan ownership carefully. Some entries may be auto-extracted from source, while others are manually maintained and may be removed by automation if their references are not visible to extraction. Record exceptions and keep tests for important strings. Once a migration is complete, translators should work in the new authoritative format rather than editing a second copy. Duplicate sources of truth create stale translations and unnecessary reconciliation.
A realistic defect: an argument changes type
Suppose the source app formats a notification with an object argument representing a contact name, while a target translation changes the argument conversion to a numeric form because it resembles a percent-pattern token seen elsewhere. The file can remain syntactically valid and the translated sentence may sound natural in isolation. The failure appears only when a real contact name reaches the formatter. This is a structural contract violation, not a translation-style disagreement.
The fastest investigation begins with the resource key and its calling code. Record the formatter, argument list and representative input. Inspect the source and target format strings, and identify which conversion was altered. Correct the pattern in the approved target resource, rerun the formatter and capture the rendered output. Then add a typed placeholder check so similar mistakes are detected before they reach the app.
Do not resolve the problem by locking every word surrounding the placeholder. Languages may require substantial reordering, agreement or punctuation changes. Protect the identity and type of the argument while allowing the sentence to become natural in the target language. A useful translation QA rule is precise about executable syntax but permissive about meaningful grammatical restructuring.
A realistic defect: only English plural logic survives
A project might ship an English one/other distinction in its plural resource and copy that structure without adaptation into a language with additional categories. Automated tests using count 1 and count 2 can pass; other numbers produce awkward or incorrect grammar. A human reviewer reading only two screenshots may also overlook the defect. The underlying issue is incomplete test coverage of the target locale’s plural system.
Repair the problem by consulting the locale’s supported plural categories and reviewing full output sentences for discriminating numbers. Verify that the rule dictionary contains the necessary forms and a valid fallback, and that the runtime selects the expected form. Where grammar cannot be expressed safely with the available variables, escalate to product and engineering for an alternate message structure.
Document the examples in the translation handoff. A table of counts and expected phrases lets reviewers spot category-specific errors without inspecting XML metadata. It also gives automation a small set of reproducible assertions. The goal is not to impose one universal plural chart but to connect each locale’s linguistic requirements with the behavior users will actually encounter.
A realistic defect: an approved translation never appears
A localization team may sign off a polished settings label that never appears in the app. The build includes an older table, the resource has moved to a dependency bundle, or a key lookup resolves to the development language. Developers might suspect a cache; translators might rewrite the wording; neither action addresses the actual cause. This problem is most efficiently solved by tracing resource identity.
Start with the exact interface location and expected key. Follow the lookup to bundle, table and selected locale. Check the packaged app rather than the translation vendor’s export alone. If the key exists only in the source-language bundle, determine whether the target was excluded, misnamed or overwritten during build. If two files contain the same key, identify which one actually owns the displayed text.
A good regression test asserts the origin and content of a localized resource under explicit locale selection. Avoid an assertion that simply checks for a nonempty string, because an English fallback also passes that test. Once the path is verified, linguistic review can take place with confidence that a revised sentence will reach the user-facing component.
Preview accessibility, truncation and right-to-left layout
Technical parsing is only the first gate. Localized content should be viewed in the interface that presents it. A button that fits in English may truncate in German, a navigation label may reflow in another script, and a right-to-left layout may display punctuation or mixed-direction numbers unexpectedly. Screenshots and live previews help reviewers understand whether a translation is not just correct but usable.
VoiceOver and other assistive technologies may read the same localized strings or alternate accessibility labels. Test names, hints and important alerts with the active accessibility features; a placeholder that renders correctly visually may still produce an unclear spoken announcement. Check that a long translated instruction does not hide the available action or force a user to infer a missing step.
Do not fix every layout problem by shortening the sentence aggressively. First decide whether the UI can accommodate legitimate language length or wrap naturally. A revised target text must retain critical distinctions such as ‘Delete permanently’ versus ‘Remove from list’. Product design, engineering and language review should collaborate on meaningful compromises rather than transferring the full burden to the translator.
Keep translation memory reuse contextual
Translation memory is valuable when the same key, context and meaning recur across releases. It is dangerous when a short English phrase is reused without considering the component, grammatical role or arguments. ‘Open’ in a file chooser may not share the same target form as ‘Open’ describing business hours. Two strings with identical English text may require different gender, case or formality in another language.
Store stable resource IDs, table names, screenshot references, formatter types and product features as searchable context. When a translation is proposed from memory, check whether placeholders and plural rules match the current message contract. A 100% source-text match is not necessarily a 100% safe translation match. Context-aware reuse reduces review work because reviewers can trust what was carried over.
When the source copy changes, record whether the semantics changed or only punctuation and presentation. Reuse may still be appropriate after a minor style edit, but the decision should be visible. Keep terminology guidance and approved product names connected to the message, not hidden in a separate spreadsheet no one checks during review. Fast localization rests on reliable retrieval and clear reasons for each reused choice.
Build a three-stage Apple localization QA gate
The first stage validates incoming resources and extraction. Confirm that authoritative files parse, keys are stable, comments and context are available, and the translator sees only intended editable content. The second stage validates exported target resources. Compare key inventories, parse .strings and .stringsdict with the intended tools, check format arguments, and exercise plural rules for the target locales. The third stage validates the app build and actual UI.
Use separate failure levels. Broken syntax, missing required keys and incompatible format arguments are release blockers. A suspiciously long label, an unfamiliar capitalization decision or a variation in polite register may be review prompts requiring judgment. A wrong plural form can be linguistically serious despite passing syntax checks, so human review remains essential. Design the gates to communicate risk clearly rather than producing an undifferentiated warning count.
For each error, capture target, bundle, table, locale, key, file path, source and target patterns, failed assertion, reproduction input and suggested owner. A developer should not need to guess which of several language files the report addresses, and a linguist should not need to reverse-engineer a formatter to understand the visible problem. Clear diagnostics shorten the release cycle while improving its evidence.
Release handoff and final approval
Before approval, verify that the intended localization files are included in the build, all required keys resolve under the right locales, and representative messages format without failures. Check that every translated plural resource expresses the locale’s necessary forms and that numbers outside the easy cases display correctly. Confirm that accessibility labels, user actions and high-risk notices have received contextual review, not only out-of-context text approval.
Preserve a minimal record of source revision, target revision, catalog or file format, tested Xcode and runtime environment, locales, build identifier, tool versions and waivers. If an app later switches from .stringsdict to a String Catalog, the team can then identify which equivalence checks must be repeated. If a new locale is added, the plural and format test suite provides a reusable starting point without pretending that linguistic decisions are identical across markets.
Translation speed should be visible in fewer avoidable revisions, not in omitted safeguards. Once the resource grammar, lookup path and formatter behavior are verified by automated checks, human reviewers can spend more time on tone, comprehension and natural language. This division of work is what makes a multilingual Apple product easier to extend without compromising the words users depend on.
Questions iOS localization teams commonly ask
Can I translate an Apple .strings key? Usually the value is the editable part and the key should remain stable, but some older apps use the source phrase as the key. Follow the code’s declared lookup contract. Can one English plural form work for every language? No. Test target-language categories and full phrases. Does a file that parses guarantee correct formatting? No. A property list can be structurally valid while its runtime placeholder references are wrong.
Why does my target translation show English? Check table names, bundles, locale resolution, files included in the app target and fallback. Why does an apostrophe or percent sign behave strangely? Determine whether the consuming API interprets it as formatter syntax. Why does a catalog translation not match an old strings file? Identify the authoritative resource and compare runtime outputs rather than assuming both formats are built together.
Is screenshot review optional once CI passes? Not for interface quality. Automated tests excel at grammar of the resource file and formatter, while screenshots, device previews and native-speaker judgment reveal whether messages fit actual decisions and situations. Use both forms of evidence in proportion to the importance of the message, especially for payments, consent, deletion, safety and accessibility.
Continue through the How People Translate Quickly Series Index, then study ICU MessageFormat Plurals and Selects, Duplicate Localization Key QA and Localization Build Validation. These guides form part of the larger Master Art of Translation.