Localize in your own language, not just English

The unspoken assumption

Open POEditor, Phrase, Lokalise, or Crowdin and pick a starting language. You will be nudged toward English. Their UIs, their documentation, their example screenshots — all assume the strings you are localizing from are written in English.

For a lot of teams, that assumption is wrong.

If your developers think and write in Czech, German, Polish, or Portuguese, asking them to author every string in English first is friction at best. At worst, it is a quality tax: every string passes through two translations instead of one — dev’s language → English (by hand) → target languages (by the model) — and errors compound.

We hit this on our own team. The fix turned out to be smaller than the workarounds.

What changed

A LangSync namespace has a default language — say en-US. This is metadata. It tells the namespace which language file is the canonical export, the one your CI pipeline pulls into the build.

In your project, you create a .langsync.json and add one field:

{
	"default_local_language": "cs"
}

Now nrc langsync sync from that project tells the server: for this run, treat the Czech file as the source of truth. Translate from Czech into every attached language, including the namespace’s English default.

The namespace metadata does not change. Your build pipeline keeps pulling en-US. Colleagues who write in English keep working the way they always did. The override applies per sync run, scoped to the project — not the namespace.

A worked example

You are a Czech developer on a team whose namespace default is en-US. Your repo looks like this:

i18n/
├── cs.json    # 47 keys, all written by you in Czech
├── en.json    # the team's canonical English copy
├── de.json    # generated
└── pl.json    # generated

You run nrc langsync sync. Three things happen:

1. The server reads your cs.json and updates the Czech translation for every key.
2. The autotranslate phase uses Czech as the source language for the LLM and fills the empty cells in en.json, de.json, pl.json from there.
3. Once sync finishes, your colleague pulls the repo and sees the new keys ready to use in all four languages — English included.

You never wrote a word of English. The English copy on the dashboard is exactly what the model produced from your Czech.

Mixed teams work too

The override lives in .langsync.json, which lives in the project. Two developers on the same team can have completely different sources:

• Czech developer: default_local_language: cs, edits cs.json.
• English developer: no override (or default_local_language: en), edits en.json.

Both push into the same namespace. Neither overrides the other. The server tracks which language each value came from and translates from that one.

If the same key gets edited from both sides, there is no global “who wins?” question — they were never touching the same cell. The Czech edit updates the Czech row; the English edit updates the English row.

Why it matters

We built Norcube for ourselves, and we are a Czech company. Half of our internal copy is written in Czech first and translated into English second. Every TMS we tried before LangSync forced us to invert that.

The principle behind the change is simple: your tool should not impose a workflow that the underlying problem does not require. There is no engineering reason a translation pipeline needs English as the source. The constraint is a convention that got baked into product UIs years ago and stuck around.

So we took it out.

Try it yourself

If your team writes in a language other than English and you are tired of translating twice, create a free account and try LangSync. The first 1,000 strings are free, no credit card required.

The full design notes for the source-language flow live in our developer documentation. For the CLI side, the LangSync CLI page walks through norcube langsync init and norcube langsync sync — both have the source-language override built in. The wider norcube CLI covers every other product command namespace.

If you are evaluating LangSync against a more traditional TMS, our Smartsupp case study walks through one team’s migration off POEditor and what the bill looked like on the other side.

---

LangSync is part of the Norcube platform. Learn more about LangSync.