Translate a JSON i18n file into English

What changes when your strings become English

English has only two CLDR plural categories: one and other. If your source language has more (Polish and Russian use few and many, French has many for large round numbers), English simply never selects them. The real trap is zero. In French, one covers 0 and 1; in English, one means exactly 1 and zero falls into other:

• ICU message: {count, plural, one {# file} other {# files}} displays « 0 files ». If you want « No files », that needs an explicit =0 branch in the source.
• i18next suffix keys: files_one and files_other stay exactly as they are; only their values are translated. In English, files_one will only ever show for a count of 1.

Punctuation shifts too. A French « Mot de passe : » becomes Password: with no space before the colon; « 10 % » becomes 10%, and non-breaking spaces (\u00a0) disappear. Angle quotes or low quotes from German and Polish give way to English quotation marks; inside a JSON value, a straight double quote must stay escaped (\").

English text usually runs shorter than Romance-language or German sources (around 10 to 15 % shorter than French), so buttons and tabs rarely overflow. One-word labels are the weak spot: « Ouvrir » or « Abrir » isolated in a file could be Open as a verb or an adjective. A descriptive key such as menu.file.open helps resolve it.

British or American English: what the file does not decide

An English UI usually targets a market. The differences show in short strings: colour/color, cancelled/canceled, organise/organize, postcode/ZIP code. Check which spelling the free sample uses before paying, and match it to your target file name (en.json, en-GB.json or en-US.json).

Date formats stored as values, such as "dateFormat": "DD/MM/YYYY", are not translated. For a US audience, switching to MM/DD/YYYY is your call, or better, let Intl.DateTimeFormat format by locale. The same applies to decimal commas hard-coded into a string.

Capitalisation is another decision your source language may not have made for you. English interfaces use either sentence case (« Save changes ») or title case (« Save Changes »). Pick your product’s convention and check it holds from screen to screen.

Register becomes simpler: formal and informal address (vous/tu, Sie/du, usted/tú) both become you. A gender select keeps all its branches and its variable even when the English text is identical in each: Signed in.

Exactly what Manuce returns, and what it does not do

The file you get back is the file you uploaded: indentation, key order, quotes, comments, line endings, encoding and BOM preserved. Only the values change. Flat and nested JSON and arrays of strings are supported.

• Placeholders {name}, {{count}}, %s and ICU messages (plural, select) are checked string by string: same variables, same number of times.
• The plural categories English requires (one, other) are present; any missing one is added.
• Every translated value is compared with its source (variables, tags). If a mismatch persists, the source value is kept and the report says so.
• Left untranslated: keys, empty values, URLs, email addresses, numbers, colours (#1A73E8), date formats, identifiers, and anything marked as non-translatable.

The report lists translated strings and those left as is, with the reason. You pay for the words in the values only, keys and tags excluded; English is charged at the base rate (×1 coefficient).

What Manuce does not do: rename or restructure keys, adapt your date formats to the target market, or accept a glossary or term list. It does not produce certified (sworn) translations either, which would not apply to a UI file anyway.

Preparing the file and checking it afterwards

Before uploading:

• Make sure the file loads cleanly in your project: a stray trailing comma breaks parsing.
• Remove obsolete keys: you pay for value words, so there is no point translating screens that no longer exist.
• Mark values that must stay as they are (product name, plan code) as non-translatable.
• If a term must come out one way (Sign in rather than Log in), check it in the free sample and again in the delivered file.

When it comes back:

1. Diff the two versions (git diff): only values should move, never a key.
2. Run the app with the en locale and test a counter at 0, 1 and 2 to see both one and other.
3. Read the report: every value kept in the source language is listed with its reason and can be fixed by hand.
4. Review one-word labels on their actual screens, where context was missing.

In practice

1. Export the source-locale JSON file and confirm it loads without errors.
2. Upload it to Manuce: the quote counts only the words in the values.
3. Read the free English sample (spelling, key terms), then choose a level.
4. Download the translated file and report, diff it against the source, then test the app in the en locale.