AI Can Translate App Strings. That’s Not the Hard Part Anymore.

When people talk about app localization, the conversation usually starts with translation.

That makes sense. For years, translation was the slow and expensive part. You would gather your strings, upload them to a translation service, wait for human translators, download the finished files, review them, and then hope nothing broke when you merged the translations back into your app.

AI has changed that.

Today, if you paste a file full of app strings into an AI tool and ask for translations, you can often get decent output in seconds. Modern coding agents can help too. Xcode has improved its localization tooling. Claude, Cursor, Codex, and other agentic tools can be guided with custom prompts, skills, or workflows.

That is all real.

For some projects, it may even be enough.

But after working on localization tooling, I have become convinced that translation itself is no longer the most interesting problem.

The harder problem is making AI-generated localization safe enough to use in a real codebase.

App strings are not just sentences

A lot of app strings look simple:

Settings
Save
Cancel
Welcome back

Those are easy.

But real localization files also contain strings like this:

Hello, %@!

You have {count} new messages.

<strong>Continue</strong>

%{name} invited you.

Your trial ends in %1$d days.

Those strings are not just human language. They contain pieces of code, syntax, framework contracts, markup, placeholders, interpolation tokens, escaping rules, and pluralization behavior.

If an AI model translates the words but changes the wrong part of the string, your app can break.

A placeholder can disappear. A format specifier can change. A plural form can stop matching what the framework expects. Markup can become malformed. Escaping can change in ways that break JSON, XML, .strings, .arb, Gettext, or another resource format.

The translation may look fine to a human reviewer and still be technically wrong.

“Just use an AI agent” is a reasonable answer — sometimes

One of the fair objections to a dedicated localization tool is:

Why not just use Claude, Cursor, Codex, or another AI coding agent?

That is a good question.

For a small project, a one-off translation task, or a developer who is comfortable maintaining their own workflow, a general AI agent may be enough. You can write a careful prompt. You can tell it not to touch placeholders. You can ask it to preserve syntax. You can review the diff.

That can work.

The issue is repeatability.

Localization is rarely a one-time task. Apps change. Strings are added. Existing copy is edited. New languages are introduced. Frameworks have different file formats and rules. A workflow that worked once in a chat window may not be the workflow you want to trust every time your app changes.

That is where a purpose-built tool can still matter.

Forthwith’s thesis

Forthwith is built around a simple thesis:

AI translation is easy now. Safe production localization is still hard.

Forthwith is not trying to prove that general AI tools are useless. They are not. In fact, Forthwith exists because AI has made app localization dramatically more accessible.

But Forthwith is designed for the part that comes after “translate this.”

It is meant to help developers:

• find translatable strings in real projects
• translate only what changed
• preserve placeholders and interpolation tokens
• protect markup and escaping
• respect framework-specific localization formats
• validate output before writing changes
• produce clean diffs that can be reviewed and committed

The goal is not just to generate translated text.

The goal is to make localization feel like a normal developer workflow.

Cross-platform localization is messy

Another reason this problem is still interesting is that not every app lives inside a single ecosystem.

Some teams have iOS and Android apps. Some have React or React Native frontends. Some use Flutter. Some have Phoenix apps using Gettext. Some use Go. Some have older projects that do not use the newest framework conventions.

Each stack has its own expectations.

A tool built only for one IDE or one file format may be helpful, but it does not solve the broader problem for teams working across multiple platforms.

Forthwith currently supports localization workflows across:

• iOS
• Android
• Flutter
• React
• React Native
• Phoenix
• go-i18n

That cross-platform focus is intentional. Forthwith is for developers whose localization files live in real codebases, not only in a translation dashboard or a single vendor-specific IDE.

This is not necessarily a replacement for human translators

There are still plenty of cases where human translators matter.

Brand voice matters. Cultural nuance matters. Legal and regulatory language matters. High-stakes user flows deserve review. Some languages and domains need extra care.

Forthwith is not built on the assumption that humans are obsolete.

It is better thought of as a developer-first localization workflow. It can help generate translations quickly, prepare reviewable diffs, and catch mechanical errors before human review or release.

For many projects, that may be enough to ship. For others, it can be the first pass before a reviewer gets involved.

Either way, the developer should not have to manually babysit every placeholder, plural form, and resource file.

Where Forthwith fits

If your app has only a few strings, you may not need a tool like Forthwith.

If you are fully inside one ecosystem and your existing tools handle localization well, you may not need Forthwith.

If you already have a carefully maintained AI-agent workflow that validates your localization files exactly the way you need, you may not need Forthwith.

But if you want a repeatable CLI workflow that understands app localization files, updates only what changed, validates fragile syntax, and writes clean changes back into your repo, that is the space Forthwith is trying to serve.

The question is not whether AI can translate strings.

It can.

The better question is whether your localization workflow can be trusted after the translation is done.

That is what Forthwith is for.