String Catalog picks a parser based on app localization file shape and path signals, then runs parser-specific logic for extraction, state updates, and write-back.
When To Use This Page
Use this page when you need to understand which parser handles a file and why.
It is especially useful if:
- A file is not being localized as expected.
- You are mixing iOS XCStrings, Android XML, and TestFlight files.
- You want predictable behavior across repository and manual flows.
Supported Detection Signals
- TestFlight files following
TestFlight/WhatToTest.<locale>.txt .xcstringsfiles for XCStrings parser.xmllocalization files in supported Android resource paths for Android XML parser
Unsupported formats are rejected with explicit errors.
Standard Parser Responsibilities
Each parser page follows the same core responsibilities:
- Detection rules
- Supported file patterns
- Parsing behavior
- Locale normalization behavior
- Review state handling
- Rename handling
- Write-back normalization
- Edge cases handled
Why This Matters
Consistent parser behavior keeps sync runs predictable across different localization file formats.
Quick Dispatch Examples
Localizable.xcstrings-> iOS XCStrings parser.app/src/main/res/values-es/strings.xml-> Android XML parser.TestFlight/WhatToTest.fr-FR.txt-> TestFlight parser.
If a file does not match one of the supported parser patterns, it is rejected instead of being parsed ambiguously.
Common Misclassification Signals
- File extension is valid, but directory or naming pattern is not.
- Locale code shape does not match supported parser conventions.
- Parser-specific structure is missing (for example invalid Android resource XML).
When this happens, validate both the file content and file path, not only the extension.