Android Strings.xml and Plurals Translation QA

Android strings.xml translation works when you translate the visible wording but preserve the resource contract. For an Android app, that means keeping resource names, XML structure, formatting placeholders, plural quantities and locale folders intact while making every message natural in its target language. Start with a source and target inventory, translate only user-facing values, compile the resources, then check actual screens and quantities in the running app.

If you need to translate Android string resources quickly, the most useful first check is simple: can the app still find each string and display it correctly after Android processes the XML? A perfectly grammatical sentence is not a successful translation if its resource name has changed, a quotation mark breaks parsing, a percent placeholder receives the wrong argument, or a plural form is never selected for the intended locale.

This guide explains how to translate Android strings.xml files, string-array resources and plurals safely. You will see how XML escaping differs from Android resource escaping, what format arguments must keep, how Android plural categories work, how language-region resource directories affect delivery, and what to test before release. It follows a practical path from preparation to independent quality assurance, with examples of failure, repair and prevention.

Start with one working string, not a giant translation export

Open the Android project and find the actual resource that the application uses. A typical file is res/values/strings.xml, but the filename can vary. The resources may be distributed across modules, libraries or feature packages. Find one button label and trace it into a real view or Compose component. Identify its name attribute, source text, the locale-specific copy and the code that retrieves it. When that one example works from file to screen, you know which part of the workflow is responsible for the next message.

The resource name is a stable identifier, not a sentence to translate. A key such as action_save may be referenced as R.string.action_save. The target may change Save to a natural equivalent, but it must keep action_save unless developers intentionally migrate the identifier everywhere. This distinction immediately reduces needless rework. It also helps translators understand why an invisible-looking resource key is as important as the visible words.

Take a snapshot before editing. Record the commit or content version, the supported locales, resource locations, build variant, and who owns string extraction. Create one source-of-truth inventory rather than passing independently edited spreadsheets around. When disagreements occur, you should be able to answer which exact source string, project revision and target locale a translation was created for.

Understand the three principal resource shapes

Android has simple strings, string arrays and quantity strings called plurals. They solve different problems. A simple string supplies one piece of text such as a screen title. A string-array supplies a list of entries, such as labels for fixed options. A plurals resource supplies variants chosen using language-specific grammatical quantity rules. These are different resource types even when their source wording looks similar.

For a simple example, a string named greeting might hold Welcome back. The French translation changes the value, not the resource name or enclosing string element. A string-array named payment_steps could contain four instructions that a screen expects in a particular order. Its translated copy must still be four entries in the same intended positions if callers rely on indices. A plurals entry named selected_files could have one and other variants in English but a different set of categories in another language.

The crucial QA question is not whether source and target XML have identical visible sentences. It is whether they have compatible contracts for the application. Arrays must retain their semantics. Plural variants must represent the target language. Every resource reference must resolve in the intended build. A combined inventory should therefore include resource type, name, usage context, translatable status, formatting arguments, and review owner.

Decide what is translatable before opening a CAT tool

Many resource files contain values that look like text but are not prose. A URL, asset filename, feature flag, analytics event name, error code or internal token may be stored near button labels. Blindly translating every XML text node risks breaking the application. The project should mark deliberately excluded strings through the platform mechanism or an extraction policy, and reviewers must verify that the policy matches runtime use.

In Android resources, translatable="false" marks a string that should not be offered as a translation target. It is useful for values such as a nonlocalized brand token or technical constant. It is not permission to ignore genuinely user-visible copy. A brand name might remain unchanged, but a sentence that explains the brand still needs localization. Similarly, a website address may remain fixed while the accessible link label should be rewritten for the reader.

A practical extraction sheet has one row per resource with columns for name, type, screen, meaning, do-not-translate tokens, screenshots, placeholders and locale. Add an owner for uncertain items. Translators can then spend their time on actual language decisions rather than guessing whether a string is a secret configuration setting or a label the customer will see.

Protect XML syntax while editing natural language

An Android resource file is XML. Characters used as markup must be represented correctly. A literal less-than sign in text cannot simply be inserted as though it were harmless prose. Ampersands in XML text also require proper entity handling. When an instruction says the user can choose A & B, the editor must preserve the intended displayed ampersand without creating an invalid XML entity.

Do not confuse the XML layer with the Android string-resource parser. XML escaping protects document structure, while Android has additional handling for characters and formatting in resource values. A string that passes a generic XML validator may still need adjustment before the Android resource compiler accepts it, and a source that looks strange to a translator may be deliberately escaped for Android.

The safe way to handle these layers is to use the project’s compiler as an authority. Build after representative changes rather than trusting an editor preview. Examine the runtime output as well. A file can be syntactically valid yet display an unwanted backslash, a collapsed space or encoded markup because the translation workflow transformed the value at the wrong stage.

Treat apostrophes and quotation marks as a build concern

Apostrophes are especially common translation hazards because some target languages use them frequently. Android string resources have quoting and escaping rules beyond ordinary XML. An unescaped apostrophe in a resource value can produce a resource-processing error. Escaping the apostrophe with an Android backslash, or correctly quoting the value according to the resource rules, can resolve that problem.

Suppose the source is an English label with no apostrophe, while the French target introduces one in an ordinary word. The source file compiles and the target fails. This is not a reason to change the natural French translation to an awkward expression. It is a reason to encode the target correctly. The language reviewer should approve the wording and the build should test the resource representation.

Double quotation marks need equal care. Sometimes quotes are punctuation the user should see; sometimes quotes control Android whitespace preservation or escaping. Never run a global find-and-replace that strips quotation characters to make files look tidier. Verify whether they are syntax or content in that particular string, and preserve the resulting displayed meaning.

Keep whitespace intentional, not accidental

Spacing can make or break an interface. Android resource processing normally normalizes many whitespace sequences unless the string is encoded to preserve them. A translator can add multiple spaces to align a label in a spreadsheet, only to discover they collapse at runtime. Conversely, an escaped newline can become a deliberate line break that changes a button height or screen-reader announcement.

Do not use spaces as a layout system. If two controls need alignment, the layout belongs in the UI implementation. If a message genuinely requires paragraph separation or a line break, the developers should specify how it is represented and how it behaves under accessibility and screen rotation. The translated language may need a different line-break position, but hardcoded breaks should be exceptional and tested.

Check leading and trailing spaces during review. They are often paste artifacts that create odd concatenation with neighboring elements. At the same time, do not auto-trim every value without reviewing context. Some resource values are deliberately joined by application code, though that design should ideally be repaired upstream because concatenation prevents natural grammatical reordering.

Preserve printf-style arguments and their intended types

Many Android strings contain formatting arguments. A message might show a name, amount or count using printf-style syntax. The placeholders are functional: the application passes data into them. The translator may move a placeholder to match target-language word order, but may not silently delete an essential argument or change an integer conversion into a string conversion without engineering agreement.

For languages that reorder arguments, positional specifiers such as %1$s and %2$d are often important. If a source says that a user received a certain number of messages, the target may need to mention the number before the user. A positional placeholder tells the formatter which argument belongs where. Without positions, moving phrases may accidentally associate the wrong value with a grammatical role.

Make a placeholder inventory per message. Include the identifier, conversion type, position and meaning, not merely the number of percent signs. Compare the inventory after translation and run a formatting test with representative input values. A string containing a percent sign that is literal text is another case to distinguish from an argument. Treat these as different contracts instead of counting every percent character as a variable.

Separate formatted strings from ordinary text containing a percent sign

Some source messages mention a percentage or a symbol literally; others include data inserted at runtime. If a translator sees 100% complete, the percent sign is probably part of the prose unless the application formats it. If the source contains %1$d%% complete, then one part is a numeric argument and the escaped percent is a literal output character in a formatting context.

Android supports a formatted attribute that can affect how format-like strings are treated. A resource declared formatted="false" has a different contract from a message intended for String.format-style substitution. A well-meaning reviewer who normalizes every percent sequence may introduce a crash or change a displayed percentage.

Trace the caller. Is the resource passed to getString with arguments, formatted by Java or Kotlin later, or displayed as-is? The correct translation must match the actual operation. A target QA routine should run the same operation as production rather than applying a home-grown regular expression and assuming the result is equivalent.

Translate plurals according to the target language, not English intuition

Android quantity strings use grammatical plural categories. Available category names include zero, one, two, few, many and other. The names are not universal numeric labels. A category is selected by locale-specific plural rules, and a language may use only some of them. English normally selects one for a count of one and other for other integer counts; another language can require substantially more distinctions.

For this reason, do not translate an English plural entry by copying exactly its two categories into every locale. A Polish, Russian or Arabic target may require additional forms to express the correct agreement. Equally, do not create arbitrary zero or two entries because their names sound useful. A target-language specialist should supply the forms that the platform actually uses for the locale.

Another subtlety is whether the number appears in the sentence. Android chooses a plural variant using a quantity argument, but that alone does not guarantee that the numeric value is inserted into the displayed text. If the resource says selected files and the product design requires 5 selected files, the numeric placeholder must be present and correctly formatted. Review selection and interpolation as separate questions.

Test plural cases with values that expose the rule

A single test at one and two is often insufficient. Build a sample matrix that includes zero, one, two, three, five, eleven, twenty-one, one hundred and larger values as relevant to the locale. The point is not that each language has a different word at every value. It is that several of those values can fall into unexpected grammatical categories for a reviewer accustomed only to English.

Use the Android APIs or framework path that the application actually employs to choose plural resources. If the project uses Compose, verify the plural resource within that route. If it uses a classic View, test Resources.getQuantityString or the equivalent caller. This avoids mistaking a manually chosen category for the category the platform selects.

When an Arabic example displays a wrong form for zero, do not automatically create a special zero phrase before identifying the current locale, resource qualifier and grammar. The failure may be a missing translated category, an unintended fallback, an incorrect target form or a wrong quantity passed by the code. Establish which layer is responsible before repairing the visible output.

Keep string arrays aligned with program behavior

A string-array often represents an ordered user choice. The array’s first target item should correspond to the source’s first semantic option when the application relies on indices. Alphabetically sorting a translated list may look elegant in a translation tool but can change which option is selected when an index is used elsewhere in the program.

Imagine a settings screen with three choices: Off, Automatic and Manual. The app stores 0, 1 or 2 and uses a translated array to display the label. If the target array is reordered, the setting may show the wrong word while the stored value remains unchanged. That is a functional localization defect, not just a style problem.

Ask developers whether arrays are positional or merely presentational. If the order may vary by locale, the application should map stable IDs to labels rather than assuming a position. If it is positional, automatically check cardinality and order. If any choice is intentionally absent from a locale, document the product decision and test the new behavior instead of quietly shortening the array.

Keep resource names stable across every language folder

Android locale resources commonly live under directories like res/values-fr or res/values-pt-rBR in resource qualifier syntax. The directory path controls selection; its precise qualifiers are not decorative. A file placed in the wrong folder may compile yet be used by the wrong audience or never selected at all.

Keep a locale routing table that maps the language tag used by the translation platform to the resource qualifier expected by the Android project. Distinguish Portuguese for Brazil from Portuguese for Portugal when the project supports both. Record script variants and complex locales using the supported qualifier conventions. Do not invent directory names from human-readable labels.

Test an intentionally unique marker for each supported locale in a development build. Change the device or app language setting as supported, open the relevant screen and verify that the marker from the intended resource is shown. Replace the marker with approved text before delivery. This small experiment checks the actual route instead of assuming that a folder with a plausible name is wired correctly.

Understand fallback without treating it as completion

An Android application can display a default resource when a localized entry is missing. Fallback protects the interface from some missing translations, but it does not make the local language complete. A target screen can contain fluent French labels interrupted by an English error message that no one noticed in the translation export.

Classify each resource according to intended coverage. Some messages may deliberately retain a fixed name; others require a full target translation. Track unresolved fallbacks by locale, severity and user journey. Pay special attention to sign-in, payment, permissions, accessibility, errors and urgent notices. Those are the screens where a fallback can be confusing or consequential.

Do not confuse a build passing with language coverage passing. The build verifies that resources can be compiled and resolved under its rules. It may not prove that a local user understands every word or that every sensitive workflow uses the right localized content. Both technical and linguistic evidence are necessary.

Give translators the screen, action and audience

The English word Open can be a verb on a button, an adjective describing a business, or a status in a support ticket. Without context, translators may select the wrong part of speech. Android keys sometimes help, but action_open is still not enough to determine the exact UI situation. Attach a screenshot and one sentence describing what happens when the control is activated.

Include surrounding text, space constraints, accessibility label, and whether the audience is a customer, teacher, child, administrator or developer. If the source uses terms such as account, profile, session and workspace inconsistently, resolve the product concept before translating. A termbase should define each concept and preferred target equivalent for that application, not just provide a list of English words.

Review the same message in the real screen after translation. A target may be linguistically correct as a standalone sentence yet wrong next to an icon or previous question. Contextual QA is a way to catch such mistakes at the point where they matter, instead of forcing translators to speculate from isolated string fragments.

Preserve markup, styling and clickable spans

Some Android strings contain supported inline styling or escaped HTML-like content. Others are processed later by code that applies spans. A translator may need to move emphasized words or a link label, but must not casually remove markup that the app relies upon. Determine whether the markup is parsed as an Android styled resource, as HTML text, or as a custom placeholder.

Consider a sentence with a clickable Terms of Service segment. The target-language word order may put that segment earlier in the sentence. If the app identifies it by a fixed character offset taken from English, the translated text can make the wrong words clickable. A better implementation locates and styles a distinct semantic span or resource annotation, with tests for the target order.

In QA, tap every link, inspect text emphasis and listen with a screen reader. A visual screenshot can show the words but still miss a broken interaction. Markup preservation belongs with the actual user action, not merely with an XML parser’s concept of valid tags.

Treat accessibility copy as real content

A screen-reader label may be more important than the visible icon caption. If an unlabeled control becomes clear only through an accessibility string, leaving that string in English compromises the translated experience. Inspect content descriptions, state announcements, error labels, input hints and descriptions that give meaning to charts or images.

Write for the person hearing the message, not just reading it. A button that says Next might need a longer accessible description in context, such as Next, billing details, though the precise phrasing depends on the design. Avoid redundant announcements that repeat the role of the element if the platform already supplies it. Test dynamic states, because an announcement may change after a successful save or failed request.

Accessibility is also where placeholder mistakes become obvious. A screen reader might vocalize a stray %1$s or awkwardly split a number and unit. Include assistive-technology testing for high-value paths, and have a target-language speaker judge whether the announcement is clear and polite.

Check right-to-left languages with actual numbers and links

Arabic and Hebrew interfaces can contain Latin URLs, product codes, account numbers and English brand names alongside right-to-left prose. Unicode bidirectional behavior can affect what readers see, especially around punctuation. Translators should not insert arbitrary invisible directional marks merely because a preview looks wrong in one editor.

First test with the platform’s bidi-aware rendering and locale configuration. Isolate dynamic content when needed through the application’s bidi-safe text utilities. Verify that the number sequence remains semantically correct, tap targets align with the intended segment, and copied text retains the right logical order. Test both short labels and long notifications.

A string is not complete merely because its words have been translated into Arabic. Visual order, accessibility, cursor behavior and copy-paste need the same scrutiny. Route low-level bidi problems to engineering, while language reviewers check the intended reading order and natural grammar.

Let the target language breathe in the layout

A phrase that fits in English may expand in German or French, while another language may have different word breaks or line-height requirements. Avoid asking translators to remove essential meaning just to match an English character count. Instead, test UI resilience using longer text and genuine target-language content before release.

An Android layout should handle wrapping, dynamic font sizes and device sizes thoughtfully. Fixed-width buttons, assumptions about one-line labels, and truncated errors are common sources of defects. Use pseudo-localized resources to expose fragile layouts early. Then test with actual target-language strings because pseudo-localization cannot prove good grammar or typography.

A layout failure has a responsible layer. If the screen cuts off a long but necessary safety instruction, shorten only with informed product and language approval; otherwise revise the interface. Quality is not achieved by hiding content that no longer fits. It is achieved when the user can understand and act on the complete message.

Separate dates, numbers and currency from translated sentences

One source string might combine a date, price and label through concatenation. That can cause both grammar and locale formatting errors. Displaying a currency with a source-locale decimal separator or placing a date in an unfamiliar order is not repaired by changing the surrounding English words into Spanish.

Prefer platform-supported locale-aware formatting for numbers, dates, currencies and units. Let the localized resource own the human sentence, while formatting APIs produce the data in the appropriate form. Then test the assembled result, especially when word order or noun agreement depends on the displayed value.

A useful QA example is a purchase summary. Check the item quantity’s grammatical form, the price’s currency code or symbol, decimal grouping, refund terminology and any clickable disclosure. Each is a separate contract, and each must work together in the final screen. One screenshot cannot substitute for exercising variable cases.

Build a compact translation test fixture

A test fixture is a tiny app screen or automated test that deliberately displays risky resource patterns. Include a plain label, a sentence with apostrophes, a string with an ampersand, positional format arguments, a literal percent sign, every plural category required by the target, a string-array menu, a link annotation and a right-to-left example if supported.

Give each test a known expected behavior. For example, a formatting test should verify that changing argument order does not swap a person’s name with a count. A plural test should show the target-language forms selected at several values. A resource-path test should show which locale folder supplied the string. A screen-reader test should verify that the announcement is intelligible.

This fixture makes translation faster because an editor can catch structural breakage before a full application regression. It does not replace real-screen QA, but it reduces the number of failures that reach that stage. Keep the fixture versioned with the code and translation resources so that it stays relevant as the application changes.

Use the Android build as a mandatory gate

The Android resource compiler can detect many forms of malformed or invalid resources. A translation that breaks XML, resource naming or certain formatting rules should fail the relevant build or resource-processing step before publication. Integrate localized resources into the actual module and variant, rather than testing only a detached file.

Run a representative build for the supported configuration and inspect errors rather than silently discarding them. If a failure points to a target string with a stray apostrophe or broken entity, repair the representation while keeping the approved meaning. After the build passes, run instrumented or UI tests for messages whose correctness cannot be inferred from compilation.

Version-sensitive behavior matters. Test the Android Gradle Plugin, dependencies and localization framework actually deployed, and document exceptions. A checklist that assumes every product uses exactly the same compiler and retrieval path can give false reassurance. The strongest evidence comes from building and running the target application.

Compare source and target structure automatically

Computers are better than humans at detecting missing resource names, malformed XML and some placeholder mismatches. Use a structural comparison that extracts resource names and types from source and target files. It should identify missing entries, surprising extra entries, type conflicts, array-count differences and incompatible formatting arguments.

Allow justified differences. Plural-category sets need not match the English source because the target language can have different grammatical categories. Some resources are intentionally excluded through a project policy. The correct automation understands the contract rather than requiring byte-for-byte identical files.

Reports should point to the smallest repairable unit: locale, resource name, error class and relevant file. A reviewer should be able to decide whether an issue is a legitimate locale variation, a developer defect or a translation mistake. Broad warnings such as translation invalid are too vague to accelerate correction.

Review the translation itself after structural checks pass

Technical validity is necessary, not sufficient. The resource can compile, select the right plural form and still tell the user the wrong thing. Ask a qualified target-language reviewer to check tone, terminology, politeness, inclusivity, reading level and the user’s likely task. Review high-impact messages against the original product intent, not merely against individual English word choices.

Pay special attention to negatives, conditions and obligations. A notification saying Payment could not be completed must not become Payment completed. A permission prompt must distinguish allowing access now from allowing access always. A privacy choice must preserve whether the setting is optional or required. These are meaning-preservation problems that automated XML checks do not solve.

Resolve errors through a shared issue log containing source, target, screenshot, intended action and owner. Note whether the repair changes wording only, code only or both. When a correction is accepted, add its lesson to the translation brief so future reviewers do not rediscover the same problem.

Run a complete screen-based regression in each priority locale

Choose paths that ordinary users actually take: install or open the app, sign in, change settings, submit a form, recover from an error, check notifications and sign out. For each supported priority locale, observe whether language selection works, text is complete, labels match controls and errors make sense.

Test unusual states as well as the happy path. What happens with no search results, a very long name, low connectivity, a full inbox, a refund, a missing permission or a plural count of zero? Screens often contain strings that static screenshots of the normal path never reveal. Error states are especially likely to expose fallback English or developer-facing keys.

Keep reproducible notes rather than a vague pass or fail. Record the app build, device, locale, action, expected result, actual result and screenshot or accessibility observation. This turns localization into a fixable engineering process instead of a subjective final glance.

Handle translation updates without losing the source contract

Applications change between translation export and import. A developer may rename a resource key, split one sentence into two, introduce a new placeholder or delete an obsolete screen. If a translation is imported without reconciling those changes, it can overwrite a newer source contract or create orphaned entries.

At each handoff, compare source revisions and mark messages as new, changed, unchanged or obsolete. Revalidate translations when their meaning or arguments change, even if the resource name stays constant. Do not assume a translation is safe simply because its string matches a previous text fragment; the surrounding screen can change the intended function.

Prefer a single controlled merge into version control, backed by automated checks, over manual copying between branches. A translator should know when a changed source invalidates a previous approval. A developer should know when an approved target is being replaced and why. This protects both language quality and release speed.

Three diagnostic examples that save hours

First, imagine a French build that fails after translators update dozens of strings. Find the earliest compiler error and inspect the indicated resource. If it is an apostrophe issue, correct its encoding, rebuild and test the actual text. Do not rewrite all French contractions out of the language to satisfy the parser. The root cause is a representation error.

Second, suppose a translated Settings menu chooses the wrong mode. Compare the translated string-array entries with their stable application meanings. If a translator sorted the array alphabetically and the caller indexes it, restore semantic alignment or change the UI architecture to separate IDs from labels. Rewording the labels cannot repair a wrong data mapping.

Third, imagine the Russian target says the same grammatical form at counts one, two and five. Check whether the resource contains the necessary target categories, whether the app passes the intended quantity and whether the locale selection is correct. Only after those facts are established should a language specialist adjust a grammatical form. Otherwise the same defect returns after the next export.

A release checklist a translator can use independently

Before handoff, confirm that every target resource belongs to the intended source revision, that identifiers remain stable, that no forbidden configuration values were translated, and that XML parses and compiles in the real application. Verify apostrophes, quotation marks, escaped characters, formatting arguments, percent literals and array alignment with a focused test fixture.

Next, check plural behavior using several numbers appropriate to the target language, verify locale folder routing and fallback behavior, and exercise real screens. Inspect lengthy messages, accessibility labels, hyperlinks, dates, amounts and right-to-left mixtures where relevant. Have a language reviewer approve meaning and tone, and record every intentional exception.

Finally, archive the source version, target files, QA report, reviewer decisions and tested build. These artifacts make the next update faster. If an issue appears after release, the team can reproduce it and determine whether the problem came from translation, extraction, encoding, resource selection, formatting or UI code rather than starting over.

Frequently asked questions

Can I just translate everything between XML tags?

No. Many XML files contain resource identifiers, markup, nontranslatable values and strings with special formatting. Translate approved user-facing values and preserve the surrounding contract. Use an extractor that knows Android resources or a controlled workflow with resource validation.

Why does a translated strings.xml file work in an editor but fail in Android Studio?

Text editors show characters, but the Android resource toolchain also processes XML, Android-specific escapes and formatting. An apostrophe, entity, placeholder or tag can break that process. Inspect the build error and repair the relevant representation, then run the app to confirm what the user sees.

Do I need the same plural categories in every language?

No. The grammatical categories required for selection vary by language. Choose the correct forms for each target locale using the platform’s supported rules and test multiple quantities. Category names are not instructions to map every number literally.

Should translators edit the name attribute?

Normally no. The name attribute identifies a resource used by application code. Changing it requires coordinated engineering work. Translate the displayed value unless the project deliberately calls for a separate identifier migration.

Is a successful build enough to publish?

No. Build checks can catch structural failures, but they do not prove correct meaning, natural phrasing, correct locale fallback, accessibility or full-screen behavior. Use the build as one gate, followed by target-language and runtime review.

Continue with Related Translation Guides

For iOS app resources, read Xcode .xcstrings String Catalog QA. For PO and POT workflows, read GNU gettext Translation QA. For React and JavaScript resource files, read i18next JSON Localization QA.

Explore the How People Translate Quickly series index and the Master Art of Translation.

How People Translate Quickly | Android strings.xml and Plurals QA: Translate App Text Without Breaking Resources