Machine-generated translations can remove a large amount of setup work. They do not remove the need to decide what a string means, where it appears, or whether it still fits the interface. A localization workflow is reliable when generation is followed by a small, deliberate review loop.
Xcode 27 agents can prepare a project for localization, update the code where needed, create String Catalogs, and generate translations. The useful shift is not that a prompt can produce many translated strings. It is that the String Catalog and the running app give you two places to review the result.
Make strings localizable before translating them
Start with localizable APIs, not a bulk translation request. In SwiftUI, string literals that resolve to LocalizedStringKey are automatically localizable. For code that produces a String, use String(localized:) rather than leaving a user-facing literal buried in a model or service.
struct WelcomeView: View {
let userName: String
var body: some View {
VStack(alignment: .leading) {
Text("Welcome back")
Text(userName)
Button("View all projects", action: openProjects)
}
}
}
func makeDefaultFolderName() -> String {
String(localized: "Untitled Folder")
}Build after preparing the code so Xcode can extract the localizable strings into the catalog. If the project is large, separate domains into named tables, such as Navigation or Errors. A catalog that mirrors product areas is easier to review than one long list of unrelated keys.
Ask the agent for one reviewable unit of work
Start with one or two target languages. Ask the agent to prepare the project and translate a defined area, then inspect the changed source and catalog before expanding the request. Xcode provides code context and language-specific guidance to the agent, but the product's terminology still belongs to the team.
The review should look for problems that are not translation quality alone:
- a label that uses the wrong product meaning of an overloaded word;
- a plural or device variant missing from a count-based message;
- a string that should interpolate a formatted value rather than concatenate fragments;
- an informal tone where the product requires a formal one.
Give the agent terms to preserve, tone requirements, and any words that should stay in English. Those constraints make the generated text more consistent, and they leave a useful record for future additions.
Use the catalog for targeted corrections
The String Catalog editor is the right place for a focused correction. You can select a language or a subset of strings and use Generate Translations for the missing values. This is safer than regenerating an entire catalog after every small change, because reviewed translations remain stable while the new work stays visible.
Review the catalog’s state and variation columns as well as the translated text. A language can be one hundred percent complete and still have an unsuitable phrase, a missing plural form, or a label that works only on a large screen.
Test the generated build in context
Set the language and region in the run scheme, then test the translated build in a preview, simulator, or physical device. Look for cropped titles, unexpected line wrapping, mirrored layout problems, and text that no longer fits a compact control.
Do this even when nobody on the team reads the language fluently. Visual review finds structural issues, and TestFlight feedback from native speakers can catch wording that is technically correct but wrong for the product.
The best loop is small: generate, inspect the catalog, run the app, collect feedback, and correct the affected strings. It is faster than treating localization as a one-time export immediately before release.
Key takeaway
Agents make String Catalog setup and translation faster, but they should not become the source of product language. Use them to produce a reviewable first pass, keep terms and tone explicit, and verify every new language in the actual interface.