Languages & URLs

Language setup lives on the Languages tab under LocaleReady → Settings. A translation API key should already be connected, or LocaleReady has nothing to send new strings to.

Source language

This is the language the site is actually written in — not a guess. LocaleReady tells your translation service what the source language is rather than asking it to detect one, because a wrong guess produces a translation that gets stored and reused every time that string appears again. Set this once, before you enable any target languages.

Target languages

Pick from a catalog of 130 languages. Each one you enable becomes a row with:

• The language, named in itself (native script) alongside its English name and code — the way the people who read it would recognize it, not the way an English admin screen defaults to.
• A URL prefix, defaulting to the language’s code (/es/, /fr/, /ja/). Change it and the old address redirects to the new one, so a link someone already published keeps working.
• A “not covered” notice when your connected translation services do not support that particular language pair — a rare gap between DeepL’s and Google Cloud Translation’s coverage, and one the two providers do not share.

A language that is not enabled here is simply not offered — LocaleReady never machine-translates into a language you have not chosen.

Archive URL segments

If a language is enabled, its archive and taxonomy base segments (/category/, /products/) can also be translated, so a French visitor sees /fr/categorie/ instead of /fr/category/. This is optional per language and per base — leave a field blank to keep the original segment in that language.

Changing your mind later

Disabling a target language does not delete anything it has already translated — the stored translations stay in your database, ready if you re-enable the language later. Changing a prefix after publishing is safe for the same reason: the old address redirects rather than breaking.