Localization-first development

Every language you add to your app lets you reach more people – Ulysses, for example, ships in twelve. Yet every language you add complicates your release cycle – every interface change needs to be translated, every time.

A developer might be fluent in two or three languages, but hardly anyone can translate into a dozen. So until recently, you depended on humans for translations. No matter if you crowdsourced or bought from a service, a round of localization had to be planned and took at least a few days. People live in different time zones, results need a technical review, and so on. We usually allowed a week for it.

Worse, every interface change that came out of beta testing required the same manual process. Over the years, localization naturally moved to the end of the cycle, right before submission.

However, machine translation has improved significantly lately. LLMs can’t quite match human quality: they lack taste, and judgment is occasionally weak. But for software, given enough context and guidance, they now come really close. Apple took note and added LLM-based translation right into Xcode 27.

Translation skills in Xcode

If you’re using String Catalogs, Xcode now has a “Generate translations” button that starts a chat with the agent of your choice. But it’s not just a button. It’s a full suite of skills, tools, and guidelines, available inside the app or through MCP.

Here’s a short overview of the components:

• Tools to read from and write to String Catalogs. Translations set this way are marked as “machine-translated”, so they can be told apart from ones written or reviewed by humans.
• Skills with guidelines on the general process, translating multiple languages at once, finding context, and reusing existing translations from elsewhere in the project.
• Guidelines on when and how to vary strings by device and plural form.
• Language-specific translation guidelines for an impressive 56 languages and variants (more than Apple ships itself).

Apple may not be the first to do this, but it seems like a really well-done take.

Localization-first

That got us thinking: could these new abilities get rid of the localization bottleneck? I think they can.

The idea is simple:

• We use LLMs for the initial localization and keep those strings marked as such.
• Localization happens right during feature development.
• A linter rule ensures that no merge request is merged without complete localization.
• Later on, a human reviews all machine translations.

For this to work, machine translations need to be “probably good enough”. So it’s advisable to use only very smart models that can handle nuances in context, tone, and the like. We, for example, only use Opus or Fable for this task.

By using Xcode’s tools, all automatic translations are stored as “machine-translated” in the String Catalog. That keeps the source code the single source of truth and makes them easy to find (with a script or agent at least, because Xcode has no interface for this). A human reviewer then goes through them, makes changes where needed, and marks each string as “translated”. That way, reviewed strings become regular translations, and new machine translations stand out again.

The second-language superpower

There’s more, though – a sort of localization-first superpower. If you develop in English but are fluent in another language, as most non-native English speakers are, you can dramatically raise the quality. I’m a native German speaker, so for me that second language is German.

This idea is simple as well:

• First, translate into just your second language.
• Review the results and discuss with the agent what is off or outright wrong.
• Record the insights from that as comments on the strings.
• Only then do the other languages.

In a more refined version, have the agent research context for each string before translating, and let it fill in missing comments as well. Both this step and the translation review have surfaced quite a few misconceptions the agent had about a term or feature. This way, you can correct them before every other language repeats the same mistake.

After a thorough alignment on two languages, we’ve seen solid results in the remaining languages so far. So much so that we’ve moved the review to after the release, where it can happen in a more relaxed setting. This works well for updates, but probably not when adding a new language.

Verdict

For us, this approach has paid off already. Localization issues now show up the moment a feature is built. Gone are the days of interfaces that look great in English but need hotfixes before release because they don’t work in some languages. Now we immediately spot layout, spacing, and truncation problems, as well as sentences that fall apart around placeholders, or broken pluralization.

Timing matters, too. The discussion with the agent happens while the developer’s mind is still on the feature and the decisions made while building it. Contrast that with translations coming back weeks or months later, shortly before release. In a team, chances are that the person handling localization wasn’t even involved in the feature. Plus, all betas now go out fully localized, so testers don’t have to put up with half-translated features anymore. That also means possible earlier feedback on translations (though we haven’t seen it yet).

I haven’t read much about localization elsewhere lately. So let me know what you think, or what your process looks like!