To find an outdated translation that still shows as translated, trace the changed source message to its String Catalog entry, rebuild, and compare the wording. A green checkmark alone cannot resolve a mismatch you have already identified.
This workflow is for someone maintaining a Mac app in Xcode with an existing .xcstrings catalog. The task is to identify which translations need attention after an English source edit, preserve useful existing text, and verify the corrected message in the running app.
What should happen when a source message changes?
Apple documents that changing a source string marks its translations for review. Its catalog states distinguish untranslated strings (New), strings requiring attention (Needs Review), and translated strings with a green checkmark. The separate Stale state means that Xcode could no longer find a previously translated string in code. Discover String Catalogs
That terminology matters when diagnosing this problem. An outdated translation of a message still used by your app is a review task. Searching only for the catalog’s Stale state could miss it.
Apple’s documented source-change behavior provides an expected result, but it does not establish why a particular entry retained its translated status. When that happens, investigate the relationship between the edited source and the catalog before treating the checkmark as sufficient evidence that the wording is current.
Locate the exact message before reviewing translations
Start with one changed message. Record its previous English wording, current wording, lookup key if separate, and catalog name. This small comparison record is a recommended diagnostic aid, rather than an Xcode feature. It gives you something concrete to check when several entries look similar.
For example, suppose a desktop button previously displayed Open item and now displays Open selected items. The review question is whether each translation still describes opening the current selection, including a possible multiple-item selection. Merely finding a translation for the word Open would not answer that question.
Separate the lookup key from the displayed wording
Swift supports an explicit static lookup key with a separate defaultValue. That default is typically development-language text and is used when lookup fails. A comment provides context for the translator. If no table is specified, lookup uses Localizable; if no bundle is specified, it searches the app’s main bundle. Swift’s explicit-key string initializer
Use this illustrative message record to distinguish those components. These are synthetic values, not a catalog file or executable program.
| Component | Before the edit | After the edit |
|---|---|---|
| Lookup key | selection.open |
selection.open |
| English source value | Open item |
Open selected items |
| Translator context | Button that opens one item |
Button that opens every item in the current selection |
| Catalog table | Localizable |
Localizable |
Here the identifier stays the same while the message changes. An audit that compares only key names would overlook this edit. Compare the source value and context as well.
Some Swift localization calls instead use the development-language wording as the key. Apple describes String.LocalizationValue as supporting that model, including interpolation. With that arrangement, changing the wording may also change the lookup key, so check both the old and new entries rather than assuming the translation remains attached to one identifier. String.LocalizationValue
Rebuild and inspect the source location
In Xcode, choose Product > Build, then select the relevant catalog in the Project navigator. Apple documents that builds update catalogs with changes to localizable strings in code. Choose Editor > Assistant and select the key to inspect its source location. Localizing and varying text with a string catalog
Compare the catalog’s source text with the intended edit. If the catalog still contains Open item, first resolve why the new source has not reached that entry. Reviewing a target translation against the old source would leave the original problem unresolved.
Check the localization call’s table and bundle, especially when the project contains several catalogs or modules. Apple documents passing a table name to select a catalog and an appropriate bundle for strings outside the main app bundle. It also recommends localizable APIs so Xcode can discover user-facing text. Preparing your app’s text for translation
For a manually managed entry, inspect and maintain its source directly: Apple states that build synchronization does not update or remove manually managed strings. Do not expect rebuilding alone to refresh one. Discover String Catalogs
Compare meaning with a source-change decision table
Once the current source is present, select each target language and examine the affected entry. Xcode supports filtering text and sorting by state, which can help locate review work. Also inspect the specific changed message even if its status remains translated. Discover String Catalogs
The following decision aid is derived from comparing message meaning, rather than from an automatic translation assessment. Its English labels are synthetic examples. It helps determine what to ask a localizer to check without assuming that every source edit requires different target wording.
| Illustrative source change | What to examine | Review decision |
|---|---|---|
Open item → Open selected items |
Selection scope and singular or plural meaning | Check whether the translation still describes the full action. |
Show details → Hide details |
The direction of the action | Check that the translated action changes accordingly. |
Items → Items: |
Punctuation and the label’s placement | Retain the wording only if it remains appropriate in context. |
Open stays Open, but its use changes |
Whether the label now names a different action | Review the context even though the source text is identical. |
For each candidate, compare three things: what the old message meant, what the current message means, and what the translation communicates now. A visible source difference establishes a review candidate; it does not by itself prove that the target wording must change.
Context-only changes deserve an explicit check. Apple documents comments as translator guidance, but the retrieved documentation does not establish that every comment edit automatically invalidates existing translations. If an unchanged English label acquires a different meaning, place it in the review queue yourself. Preparing your app’s text for translation
If the message contains a count or a device-specific variant, expand those variants rather than inspecting only the parent row. Apple documents plural and device variations within catalogs. For English, a count might require 1 item and 2 items; review the applicable forms for each target language rather than copying English grammar mechanically. Localizing and varying text with a string catalog
Resolve the review without discarding useful translations
Use the entry’s context menu to mark a questionable translation for review. When the existing wording has been checked and remains suitable, choose Mark as Reviewed; otherwise, update the translation. These review actions are documented in Apple’s String Catalog walkthrough. Discover String Catalogs
Keep the existing wording available while comparing it with the changed source. Clearing translations merely to reduce ambiguity removes useful comparison material. Likewise, avoid deleting an entry solely because its translation is outdated: first establish whether the app still uses its key.
For the synthetic selection example, a useful handoff would contain the key selection.open, the change from Open item to Open selected items, and the explanation that the button opens every selected item. That gives the localizer a specific action and scope to evaluate.
There is a practical boundary here: the Apple documentation retrieved for this workflow does not describe a retrospective command that reconstructs every missed source change behind translated entries. If the earlier wording is unavailable, you can review the current source against the current translation, but cannot establish precisely when the mismatch began. Use an available earlier project revision or saved source copy when the before-and-after comparison matters.
Verify the corrected message in the Mac app
After editing, test the actual interface. Choose Product > Scheme > Edit Scheme, select Run, open Options, and choose the target language under App Language. Close the dialog, select the Mac run destination, and run the app. Apple documents this scheme-based localization test. Testing localizations when running your app
Return to the exact control that prompted the investigation. For Open selected items, try a single selection and a multiple selection. Check whether the label describes the action in both situations and whether the displayed wording matches the catalog entry you edited. A mismatch at this stage is a reason to revisit the lookup key, table, bundle, or applicable variant.
Finish with a clear disposition for each affected language: the existing wording remains suitable, the translation was updated, or review is still pending. This closes the task around the changed message and its behavior in the interface, with the catalog state supporting that decision.