morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #4309] [Feature] Inventory .lproj localizations and decode string tables per bundle #1712

New issue

Open

opened 2026-10-16 21:09:19 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-16 21:09:19 +00:00

Owner

Originally created by @coygeek on GitHub (Oct 16, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/4309

Before submitting

I searched the open and closed issues and pull requests for a related proposal.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This request does not include credentials, private samples, or sensitive target data.

Area

Native analysis or decompilation

Current limitation

Add an execution-free Apple operation that inventories each bundle's .lproj localizations and decodes its .strings (old-style text, XML plist, binary plist), .stringsdict, and .xcstrings (String Catalog JSON) files into keyed string tables. Each entry reports table name, key, value, localization, source file, source format, translator comment, and plural or device variants. Interface Builder tables also report the object ID and property that the key names, and InfoPlist tables report which Info.plist key each entry localizes. The result supports two analyst tasks: searching user-visible text across localizations, and mapping a UI string to the nib object and code that display it.

An analyst who sees a string in an app's UI, such as a menu title, a permission prompt, or a localized app name, wants to know which table and key it comes from, which nib object shows it, and how it reads in each shipped language. REA cannot answer this as one question today.

At release rea-agents-6.5.0 (commit 3b79af28e80785afce9f5998d8f03289402a1847), git grep over src/ for lproj, stringsdict, xcstrings, and InfoPlist.strings finds only one test fixture path (Base.lproj/Main.nib), and current main adds no localization handling. What the release build does with these files:

Artifact inventory gives .strings no path role, so it falls to the generic resource role (ArtifactGraphConstruction.ts#L445-L467). Content sniffing turns binary-plist .strings and .stringsdict into plist (L470-L494, L523). No keys or values are reported, and nothing records which localization or table a file belongs to.
inspect_plist decodes one file at a time when the caller supplies its path. It returns the raw value through plutil, so translator and Interface Builder comments are lost. It reports a UTF-16 old-style text .strings file as format: "xml" because any file output containing "text" maps to xml (NativeMacOSProvider.ts#L819-L824). That format label is reported separately in #4294.
decode_interface_builder already returns NSLocalizableString objects whose raw nibValues carry NSKey (for example "7Rn-sG-NZb.title" in stock Stickies' MainMenu.nib) and NSDev (the development-language text) (InterfaceBuilderAnalysis.ts#L490-L512). The node's interface_builder_object_id is the archive object index, not the authored object ID (interfaceBuilderGraph.ts#L117-L121). Nothing connects those keys to a localized table.

Observed on macOS 27.0.1 (26A434) arm64 with Xcode 27.0 (27A266a) and npx -y rea-agents@6.5.0 (--version prints 6.5.0), using the fixture under Acceptance criteria. inspect-artifact ./Fixture.app lists the binary .strings and .stringsdict files as plist and fr.lproj/Main.strings (UTF-16 text) as resource, and its output contains none of Bonjour, Démo, or gfa-oA-9cr. inspect-plist --relative-path Contents/Resources/fr.lproj/Main.strings returns {"abc-12-xyz.title":"Main","gfa-oA-9cr.title":"Scan Document"} with format: "xml" and without the /* Class = "NSMenuItem"; ... ObjectID = "gfa-oA-9cr"; */ comments. decode-interface-builder ./Fixture.app reports an NSLocalizableString node with NSKey: "gfa-oA-9cr.title" for Base.lproj/Main.nib.

Use cases

No response

Desired outcome and success criteria

A new read-only operation, or a mode of an existing Apple tool (maintainers' choice), is available on CLI and MCP. It accepts an app bundle or a directory, or a single .strings, .stringsdict, or .xcstrings file, and returns one Evidence record with coverage, limitations, and provenance:

Localization inventory per bundle. For the target bundle and each nested bundle REA already recognizes, report its CFBundleDevelopmentRegion and CFBundleLocalizations values as declared (raw, absent stays absent), the observed .lproj directories including Base.lproj, and the table files in each one.
Entries. One entry per key with bundle path, localization, table name (file base name), key, value, source file, and source format. The source format distinguishes old-style text (with its encoding: UTF-8 or UTF-16 and byte order), XML plist, binary plist, and String Catalog JSON. Old-style text keeps its comments. String Catalog entries keep comment, per-localization state, and the catalog's sourceLanguage and version.
Variants. .stringsdict entries report NSStringLocalizedFormatKey, each variable's NSStringFormatSpecTypeKey and NSStringFormatValueTypeKey, and their plural categories (zero, one, two, few, many, other). Device (NSStringDeviceSpecificRuleType) and width (NSStringVariableWidthRuleType) rules are reported by their keys. String Catalog variations (plural, device) are reported the same way. A missing other category is flagged.
Interface Builder keys. When a key has the form <ObjectID>.<property> and a comment /* Class = "..."; ... ObjectID = "..."; */ is present, the entry reports object_id, property, and class. Without a comment, the split is reported as a key-shape inference. A Base-localized nib with the same table name is named as the candidate document. The match to decode_interface_builder's NSKey is an observed convention, not documented Apple behavior, and is labeled that way.
InfoPlist tables. Entries from InfoPlist tables carry the bundle's base Info.plist value for the same key, if present, without interpreting it.
Search. Optional key and value filters, with total and returned counts. Limits on files and entries report truncation and never drop data silently.
Fail closed per file. An undecodable file, an unsupported encoding, a duplicate key within one file, or a String Catalog that shares its name with a .strings or .stringsdict file in the same bundle each produce a limitation naming the file. Other tables are still reported. Files the operation sees but does not decode, such as .loctable, are counted and listed, never omitted.

Acceptance criteria

Fixture, built with stock Xcode tools. src/Localizable.xcstrings holds greeting (en Hello, fr Bonjour) and %lld files with en/fr plural variants one/other. src/InfoPlist.xcstrings holds fr CFBundleDisplayName Démo and NSCameraUsageDescription. src/Base.lproj/Main.xib is a macOS xib with one NSMenuItem titled Scan Document, id gfa-oA-9cr. Info.plist sets CFBundleDevelopmentRegion en and CFBundleDisplayName Demo.

A=./Fixture.app/Contents; mkdir -p $A/MacOS $A/Resources/Base.lproj; cp /bin/ls $A/MacOS/Fixture
xcrun xcstringstool compile src/Localizable.xcstrings -o $A/Resources --serialization-format binary
xcrun xcstringstool compile src/InfoPlist.xcstrings -o $A/Resources --serialization-format binary
xcrun ibtool --compile $A/Resources/Base.lproj/Main.nib src/Base.lproj/Main.xib
xcrun ibtool --export-strings-file $A/Resources/fr.lproj/Main.strings src/Base.lproj/Main.xib   # UTF-16 text with IB comments

On ./Fixture.app, localizations Base, en, and fr are reported with development region en. Tables are reported as Localizable (en, fr), InfoPlist (fr), and Main (fr).
fr Localizable / greeting = Bonjour, source format binary plist.
fr %lld files reports format key %#@value@, variable value with NSStringPluralRuleType and value type lld, and categories one = %lld fichier and other = %lld fichiers.
fr InfoPlist / CFBundleDisplayName = Démo, with base Info.plist value Demo.
fr Main / gfa-oA-9cr.title reports source format old-style text UTF-16 little-endian, class NSMenuItem, object_id gfa-oA-9cr, and property title. The key equals the NSKey of an NSLocalizableString node that decode_interface_builder reports for Base.lproj/Main.nib.
Given src/Localizable.xcstrings directly, entries report source language en, per-localization state translated, and the same plural variants as the compiled .stringsdict.
On /System/Applications/Stickies.app (macOS 27.0.1), each of its ServicesMenu.strings files is decoded as a binary plist. fr Make Sticky = Créer une nouvelle note. Its .loctable files are listed as not decoded.
A .strings file with invalid content produces a limitation naming it, and the other tables are still reported. A same-name .xcstrings plus .strings pair in one bundle is reported with a limitation.
The operation launches nothing and writes nothing.

Expected interaction with targets

Read existing files or captured data

Target and scope details (optional)

Affected area

Apple static analysis: artifact inventory and bundle resources, the Apple tool family next to decode_interface_builder and inspect_asset_catalog, the CLI and MCP contracts, and the native investigation guide.

Non-goals

Interpreting Info.plist key semantics, such as usage-description meaning or entry points.
Translating, machine-translating, editing, or recompiling strings or catalogs, or any source .xcstrings editing workflow.
Decoding Assets.car or nib archives themselves, beyond reading the existing decode_interface_builder output for the join.
Apple's .loctable files (binary plists keyed by localization, observed in stock macOS apps such as Stickies, with no documentation found in Apple's developer documentation), beyond listing them as not decoded. These could be a follow-up.
Runtime string lookup, locale fallback resolution, or proof that code ever requests a given key.

Verification available so far

I have a prototype or observed results

Verification details (optional)

No response

Alternatives considered

Extend inspect_plist: it drops comments, has no table or localization context, and needs one call per file per language.
Add string nodes to the Apple application graph: graphs suit relationships, not thousands of text rows; a graph could reference this Evidence later.

Possible direction

No response

References

Apple documentation (contract):

The archived Information Property List Key Reference says: "Localized values are not stored in the Info.plist file itself. Instead, you store the values for a particular localization in a strings file with the name InfoPlist.strings" (https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/AboutInformationPropertyListFiles.html).
The archived "Managing Strings Files Yourself" says Xcode "inserts a comment before each key-value pair that identifies the view that displays the text", for example /* Class = "NSTextFieldCell"; title = "Address:"; ObjectID = "gfa-oA-9cr"; */ followed by "gfa-oA-9cr.title" = "Address:"; (https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPInternational/MaintaingYourOwnStringsFiles/MaintaingYourOwnStringsFiles.html).
The build settings reference (https://developer.apple.com/documentation/xcode/build-settings-reference) defines three relevant settings. STRINGS_FILE_OUTPUT_ENCODING: "Specify the output encoding to be used for Strings files - the default is UTF-16." STRINGS_FILE_INFOPLIST_RENAME: "renames .strings files whose basename matches that of the target's Info.plist file, to InfoPlist.strings in the built product." LOCALIZATION_PREFERS_STRING_CATALOGS: "string tables generated in a localization export will prefer the String Catalog format."
"Localizing and varying text with a string catalog" names Localizable.xcstrings as the default and covers "plural variants" and "Vary by Device" (https://developer.apple.com/documentation/xcode/localizing-and-varying-text-with-a-string-catalog).
"Localizing strings that contain plurals" defines NSStringLocalizedFormatKey and NSStringFormatSpecTypeKey, and says "The other category is a requirement" (https://developer.apple.com/documentation/xcode/localizing-strings-that-contain-plurals). "Creating width and device variants of strings" defines NSStringDeviceSpecificRuleType and NSStringVariableWidthRuleType (https://developer.apple.com/documentation/xcode/creating-width-and-device-variants-of-strings).
CFBundleDevelopmentRegion: "The default language and region for the bundle, as a language ID", default en-US (https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundledevelopmentregion). CFBundleLocalizations: "The localizations handled manually by your app" (https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundlelocalizations).
Xcode 15 release notes: "The build system will now consistently produce an error if a String Catalog coexists with .strings or .stringsdict files of the same name, within the same target" (https://developer.apple.com/documentation/xcode-release-notes/xcode-15-release-notes). Xcode 26 release notes: catalogs using comment or symbol generation "will auto-update their version number to 1.1" (https://developer.apple.com/documentation/xcode-release-notes/xcode-26-release-notes).

Documented versus observed:

Apple's pages do not state that .xcstrings compiles to .strings and .stringsdict. The same-name conflict error is the strongest documented hint. Observed with Xcode 27.0: xcstringstool compile emits <lang>.lproj/<table>.strings and .stringsdict, as XML plists by default (not old-style text) or binary plists with --serialization-format binary. A device variant compiles to NSStringDeviceSpecificRuleType in .stringsdict, with the other value in .strings.
The .xcstrings JSON schema (sourceLanguage, strings, localizations, stringUnit, variations) is not documented in the pages above. It is observed from Xcode-produced files.
Shipped .strings files come in several encodings: old-style text in UTF-16 (the documented build default; ibtool --export-strings-file writes UTF-16 little-endian), XML plists, and binary plists. Stock Stickies on macOS 27.0.1 ships 42 ServicesMenu.strings files, all binary plists.
Compiled nib internals are undocumented. Nibs that Xcode 27.0 compiles from Base.lproj xibs (AppKit and UIKit) contain NSLocalizableString objects whose NSKey equals the IB table key; a UIKit nib carries NSKey: "Lbl-aa-123.text". So the join key works on these samples but is not an Apple contract.

Related: #480 (closed) delivered compiled nib decoding, and this request consumes its output without changing it. #496 (closed) delivered asset catalog inspection, including rendition localization, which covers a different file type. Searches for "stringsdict", "xcstrings", "lproj", "localization", and "InfoPlist.strings" found no matching issue or PR.

Originally created by @coygeek on GitHub (Oct 16, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/4309 ### Before submitting - [X] I searched the open and closed issues and pull requests for a related proposal. - [X] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. - [X] This request does not include credentials, private samples, or sensitive target data. ### Area Native analysis or decompilation ### Current limitation Add an execution-free Apple operation that inventories each bundle's `.lproj` localizations and decodes its `.strings` (old-style text, XML plist, binary plist), `.stringsdict`, and `.xcstrings` (String Catalog JSON) files into keyed string tables. Each entry reports table name, key, value, localization, source file, source format, translator comment, and plural or device variants. Interface Builder tables also report the object ID and property that the key names, and `InfoPlist` tables report which Info.plist key each entry localizes. The result supports two analyst tasks: searching user-visible text across localizations, and mapping a UI string to the nib object and code that display it. An analyst who sees a string in an app's UI, such as a menu title, a permission prompt, or a localized app name, wants to know which table and key it comes from, which nib object shows it, and how it reads in each shipped language. REA cannot answer this as one question today. At release `rea-agents-6.5.0` (commit `3b79af28e80785afce9f5998d8f03289402a1847`), `git grep` over `src/` for `lproj`, `stringsdict`, `xcstrings`, and `InfoPlist.strings` finds only one test fixture path (`Base.lproj/Main.nib`), and current `main` adds no localization handling. What the release build does with these files: - Artifact inventory gives `.strings` no path role, so it falls to the generic `resource` role ([ArtifactGraphConstruction.ts#L445-L467](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/artifacts/inventory/ArtifactGraphConstruction.ts#L445-L467)). Content sniffing turns binary-plist `.strings` and `.stringsdict` into `plist` ([L470-L494](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/artifacts/inventory/ArtifactGraphConstruction.ts#L470-L494), [L523](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/artifacts/inventory/ArtifactGraphConstruction.ts#L523)). No keys or values are reported, and nothing records which localization or table a file belongs to. - `inspect_plist` decodes one file at a time when the caller supplies its path. It returns the raw value through `plutil`, so translator and Interface Builder comments are lost. It reports a UTF-16 old-style text `.strings` file as `format: "xml"` because any `file` output containing "text" maps to `xml` ([NativeMacOSProvider.ts#L819-L824](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/native/NativeMacOSProvider.ts#L819-L824)). That format label is reported separately in #4294. - `decode_interface_builder` already returns `NSLocalizableString` objects whose raw `nibValues` carry `NSKey` (for example `"7Rn-sG-NZb.title"` in stock Stickies' `MainMenu.nib`) and `NSDev` (the development-language text) ([InterfaceBuilderAnalysis.ts#L490-L512](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/artifacts/apple/InterfaceBuilderAnalysis.ts#L490-L512)). The node's `interface_builder_object_id` is the archive object index, not the authored object ID ([interfaceBuilderGraph.ts#L117-L121](https://github.com/morluto/rea/blob/3b79af28e80785afce9f5998d8f03289402a1847/src/domain/apple/interfaceBuilderGraph.ts#L117-L121)). Nothing connects those keys to a localized table. Observed on macOS 27.0.1 (26A434) arm64 with Xcode 27.0 (27A266a) and `npx -y rea-agents@6.5.0` (`--version` prints `6.5.0`), using the fixture under Acceptance criteria. `inspect-artifact ./Fixture.app` lists the binary `.strings` and `.stringsdict` files as `plist` and `fr.lproj/Main.strings` (UTF-16 text) as `resource`, and its output contains none of `Bonjour`, `Démo`, or `gfa-oA-9cr`. `inspect-plist --relative-path Contents/Resources/fr.lproj/Main.strings` returns `{"abc-12-xyz.title":"Main","gfa-oA-9cr.title":"Scan Document"}` with `format: "xml"` and without the `/* Class = "NSMenuItem"; ... ObjectID = "gfa-oA-9cr"; */` comments. `decode-interface-builder ./Fixture.app` reports an `NSLocalizableString` node with `NSKey: "gfa-oA-9cr.title"` for `Base.lproj/Main.nib`. ### Use cases _No response_ ### Desired outcome and success criteria A new read-only operation, or a mode of an existing Apple tool (maintainers' choice), is available on CLI and MCP. It accepts an app bundle or a directory, or a single `.strings`, `.stringsdict`, or `.xcstrings` file, and returns one Evidence record with coverage, limitations, and provenance: - **Localization inventory per bundle.** For the target bundle and each nested bundle REA already recognizes, report its `CFBundleDevelopmentRegion` and `CFBundleLocalizations` values as declared (raw, absent stays absent), the observed `.lproj` directories including `Base.lproj`, and the table files in each one. - **Entries.** One entry per key with bundle path, localization, table name (file base name), key, value, source file, and source format. The source format distinguishes old-style text (with its encoding: UTF-8 or UTF-16 and byte order), XML plist, binary plist, and String Catalog JSON. Old-style text keeps its comments. String Catalog entries keep `comment`, per-localization `state`, and the catalog's `sourceLanguage` and `version`. - **Variants.** `.stringsdict` entries report `NSStringLocalizedFormatKey`, each variable's `NSStringFormatSpecTypeKey` and `NSStringFormatValueTypeKey`, and their plural categories (`zero`, `one`, `two`, `few`, `many`, `other`). Device (`NSStringDeviceSpecificRuleType`) and width (`NSStringVariableWidthRuleType`) rules are reported by their keys. String Catalog `variations` (plural, device) are reported the same way. A missing `other` category is flagged. - **Interface Builder keys.** When a key has the form `<ObjectID>.<property>` and a comment `/* Class = "..."; ... ObjectID = "..."; */` is present, the entry reports `object_id`, `property`, and `class`. Without a comment, the split is reported as a key-shape inference. A Base-localized nib with the same table name is named as the candidate document. The match to `decode_interface_builder`'s `NSKey` is an observed convention, not documented Apple behavior, and is labeled that way. - **InfoPlist tables.** Entries from `InfoPlist` tables carry the bundle's base Info.plist value for the same key, if present, without interpreting it. - **Search.** Optional key and value filters, with total and returned counts. Limits on files and entries report truncation and never drop data silently. - **Fail closed per file.** An undecodable file, an unsupported encoding, a duplicate key within one file, or a String Catalog that shares its name with a `.strings` or `.stringsdict` file in the same bundle each produce a limitation naming the file. Other tables are still reported. Files the operation sees but does not decode, such as `.loctable`, are counted and listed, never omitted. **Acceptance criteria** Fixture, built with stock Xcode tools. `src/Localizable.xcstrings` holds `greeting` (en `Hello`, fr `Bonjour`) and `%lld files` with en/fr plural variants `one`/`other`. `src/InfoPlist.xcstrings` holds fr `CFBundleDisplayName` `Démo` and `NSCameraUsageDescription`. `src/Base.lproj/Main.xib` is a macOS xib with one `NSMenuItem` titled `Scan Document`, id `gfa-oA-9cr`. `Info.plist` sets `CFBundleDevelopmentRegion` `en` and `CFBundleDisplayName` `Demo`. ```sh A=./Fixture.app/Contents; mkdir -p $A/MacOS $A/Resources/Base.lproj; cp /bin/ls $A/MacOS/Fixture xcrun xcstringstool compile src/Localizable.xcstrings -o $A/Resources --serialization-format binary xcrun xcstringstool compile src/InfoPlist.xcstrings -o $A/Resources --serialization-format binary xcrun ibtool --compile $A/Resources/Base.lproj/Main.nib src/Base.lproj/Main.xib xcrun ibtool --export-strings-file $A/Resources/fr.lproj/Main.strings src/Base.lproj/Main.xib # UTF-16 text with IB comments ``` - [ ] On `./Fixture.app`, localizations `Base`, `en`, and `fr` are reported with development region `en`. Tables are reported as `Localizable` (en, fr), `InfoPlist` (fr), and `Main` (fr). - [ ] fr `Localizable` / `greeting` = `Bonjour`, source format binary plist. - [ ] fr `%lld files` reports format key `%#@value@`, variable `value` with `NSStringPluralRuleType` and value type `lld`, and categories `one` = `%lld fichier` and `other` = `%lld fichiers`. - [ ] fr `InfoPlist` / `CFBundleDisplayName` = `Démo`, with base Info.plist value `Demo`. - [ ] fr `Main` / `gfa-oA-9cr.title` reports source format old-style text UTF-16 little-endian, `class` `NSMenuItem`, `object_id` `gfa-oA-9cr`, and `property` `title`. The key equals the `NSKey` of an `NSLocalizableString` node that `decode_interface_builder` reports for `Base.lproj/Main.nib`. - [ ] Given `src/Localizable.xcstrings` directly, entries report source language `en`, per-localization state `translated`, and the same plural variants as the compiled `.stringsdict`. - [ ] On `/System/Applications/Stickies.app` (macOS 27.0.1), each of its `ServicesMenu.strings` files is decoded as a binary plist. fr `Make Sticky` = `Créer une nouvelle note`. Its `.loctable` files are listed as not decoded. - [ ] A `.strings` file with invalid content produces a limitation naming it, and the other tables are still reported. A same-name `.xcstrings` plus `.strings` pair in one bundle is reported with a limitation. - [ ] The operation launches nothing and writes nothing. ### Expected interaction with targets Read existing files or captured data ### Target and scope details (optional) **Affected area** Apple static analysis: artifact inventory and bundle resources, the Apple tool family next to `decode_interface_builder` and `inspect_asset_catalog`, the CLI and MCP contracts, and the native investigation guide. **Non-goals** - Interpreting Info.plist key semantics, such as usage-description meaning or entry points. - Translating, machine-translating, editing, or recompiling strings or catalogs, or any source `.xcstrings` editing workflow. - Decoding `Assets.car` or nib archives themselves, beyond reading the existing `decode_interface_builder` output for the join. - Apple's `.loctable` files (binary plists keyed by localization, observed in stock macOS apps such as Stickies, with no documentation found in Apple's developer documentation), beyond listing them as not decoded. These could be a follow-up. - Runtime string lookup, locale fallback resolution, or proof that code ever requests a given key. ### Verification available so far I have a prototype or observed results ### Verification details (optional) _No response_ ### Alternatives considered - Extend `inspect_plist`: it drops comments, has no table or localization context, and needs one call per file per language. - Add string nodes to the Apple application graph: graphs suit relationships, not thousands of text rows; a graph could reference this Evidence later. ### Possible direction _No response_ ### References Apple documentation (contract): - The archived Information Property List Key Reference says: "Localized values are not stored in the `Info.plist` file itself. Instead, you store the values for a particular localization in a strings file with the name `InfoPlist.strings`" (https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/AboutInformationPropertyListFiles.html). - The archived "Managing Strings Files Yourself" says Xcode "inserts a comment before each key-value pair that identifies the view that displays the text", for example `/* Class = "NSTextFieldCell"; title = "Address:"; ObjectID = "gfa-oA-9cr"; */` followed by `"gfa-oA-9cr.title" = "Address:";` (https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPInternational/MaintaingYourOwnStringsFiles/MaintaingYourOwnStringsFiles.html). - The build settings reference (https://developer.apple.com/documentation/xcode/build-settings-reference) defines three relevant settings. `STRINGS_FILE_OUTPUT_ENCODING`: "Specify the output encoding to be used for Strings files - the default is UTF-16." `STRINGS_FILE_INFOPLIST_RENAME`: "renames .strings files whose basename matches that of the target's Info.plist file, to InfoPlist.strings in the built product." `LOCALIZATION_PREFERS_STRING_CATALOGS`: "string tables generated in a localization export will prefer the String Catalog format." - "Localizing and varying text with a string catalog" names `Localizable.xcstrings` as the default and covers "plural variants" and "Vary by Device" (https://developer.apple.com/documentation/xcode/localizing-and-varying-text-with-a-string-catalog). - "Localizing strings that contain plurals" defines `NSStringLocalizedFormatKey` and `NSStringFormatSpecTypeKey`, and says "The `other` category is a requirement" (https://developer.apple.com/documentation/xcode/localizing-strings-that-contain-plurals). "Creating width and device variants of strings" defines `NSStringDeviceSpecificRuleType` and `NSStringVariableWidthRuleType` (https://developer.apple.com/documentation/xcode/creating-width-and-device-variants-of-strings). - `CFBundleDevelopmentRegion`: "The default language and region for the bundle, as a language ID", default `en-US` (https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundledevelopmentregion). `CFBundleLocalizations`: "The localizations handled manually by your app" (https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundlelocalizations). - Xcode 15 release notes: "The build system will now consistently produce an error if a String Catalog coexists with .strings or .stringsdict files of the same name, within the same target" (https://developer.apple.com/documentation/xcode-release-notes/xcode-15-release-notes). Xcode 26 release notes: catalogs using comment or symbol generation "will auto-update their version number to 1.1" (https://developer.apple.com/documentation/xcode-release-notes/xcode-26-release-notes). Documented versus observed: - Apple's pages do not state that `.xcstrings` compiles to `.strings` and `.stringsdict`. The same-name conflict error is the strongest documented hint. Observed with Xcode 27.0: `xcstringstool compile` emits `<lang>.lproj/<table>.strings` and `.stringsdict`, as XML plists by default (not old-style text) or binary plists with `--serialization-format binary`. A device variant compiles to `NSStringDeviceSpecificRuleType` in `.stringsdict`, with the `other` value in `.strings`. - The `.xcstrings` JSON schema (`sourceLanguage`, `strings`, `localizations`, `stringUnit`, `variations`) is not documented in the pages above. It is observed from Xcode-produced files. - Shipped `.strings` files come in several encodings: old-style text in UTF-16 (the documented build default; `ibtool --export-strings-file` writes UTF-16 little-endian), XML plists, and binary plists. Stock Stickies on macOS 27.0.1 ships 42 `ServicesMenu.strings` files, all binary plists. - Compiled nib internals are undocumented. Nibs that Xcode 27.0 compiles from `Base.lproj` xibs (AppKit and UIKit) contain `NSLocalizableString` objects whose `NSKey` equals the IB table key; a UIKit nib carries `NSKey: "Lbl-aa-123.text"`. So the join key works on these samples but is not an Apple contract. Related: #480 (closed) delivered compiled nib decoding, and this request consumes its output without changing it. #496 (closed) delivered asset catalog inspection, including rendition localization, which covers a different file type. Searches for "stringsdict", "xcstrings", "lproj", "localization", and "InfoPlist.strings" found no matching issue or PR.

bsakaguchi referenced this issue

2026-10-31 00:55:13 +00:00

[PR #1764] [MERGED] fix(ida): declare GUI navigation for attached legacy analysis #4801

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#1712

No description provided.

Rows
Columns