Translate a React or Next.js App into Spanish

What changes when your UI switches to Spanish

Spanish strings usually run longer than English ones, much like French. In a React interface this shows up first on short labels: Save becomes Guardar, Sign in becomes Iniciar sesión, Settings becomes Configuración. Fixed-width buttons, tabs and table columns may overflow or be cut off by text-overflow: ellipsis. If your source locale is German or French, the gap is smaller but still worth testing.

• Inverted punctuation: questions open with ¿ and exclamations with ¡. Delete this file? becomes ¿Eliminar este archivo?. If a sentence is split across two keys and joined in JSX, the opening mark lands in the wrong key or goes missing.
• Capitalisation: Spanish uses sentence case for headings. Account Settings becomes Configuración de la cuenta. Days and months are lower case.
• Grammatical gender: Welcome, {{name}} becomes Bienvenido or Bienvenida depending on the person. A neutral phrasing such as Te damos la bienvenida, {{name}} avoids the issue when the app does not know the user's gender.

Accented characters (á, é, í, ó, ú, ñ, ü) need nothing special if your files are UTF-8 and your fonts are complete; do check any custom font subset.

Plurals: one, many, other in each library

CLDR defines three plural categories for Spanish: one, many and other. Zero takes other, so it is 0 archivos. The many category is recent and covers large round numbers such as a million, which take "de" in Spanish (1 millón de usuarios). Recent browsers return it from Intl.PluralRules.

• react-intl and next-intl (ICU syntax): {count, plural, one {# archivo} other {# archivos}} works because ICU falls back to other when a branch is missing. The message structure is preserved; only the branch texts are translated and # stays where it is.
• i18next (key suffixes): each form is a separate key, items_one and items_other. For a number classed as many, i18next looks for items_many. If your source file has only two forms, the Spanish file will too, because keys are never changed. Add items_many afterwards by copying the items_other value, or test with count: 1000000.

Watch out for plurals built in code, such as item{count > 1 ? 's' : ''}: Spanish also inflects articles and adjectives (los archivos seleccionados), so appending an "s" will not do.

What Manuce returns, and what it does not do

You upload the JSON file exactly as it sits in the project: locales/en/common.json for i18next, messages/en.json for next-intl, or your react-intl catalogue, whatever the source language. Manuce returns the same file in the same format: indentation, key order, quotes, comments, line endings, encoding and BOM are preserved. Only the values change; nested keys stay intact.

• Interpolations such as {{name}}, ICU messages and tags (for instance <bold> or the <1> placeholders of a Trans component) are kept. Each translated value is checked against the source; if a variable or tag mismatch persists, the source value is kept and the report says so.
• Not translated: keys, empty values, URLs (a path like /pricing stays as it is), email addresses, numbers, colours, date formats, identifiers and anything marked as non-translatable.
• The report lists translated strings and those left unchanged, with the reason.

Manuce does not add keys (so no _many forms), does not touch your Next.js routing configuration or component code, and does not rename the file. Pricing is based on the words in the values; keys and tags are excluded.

Spain or Latin America, tú or usted

There is no single Spanish for interfaces. Vocabulary differs: ordenador in Spain, computadora across most of Latin America; móvil versus celular. In the project this means choosing a locale: es, es-ES or es-419 (Latin America) in your routing's locale list. Decide before you order, as you name the file and folder yourself.

Register matters just as much. Many consumer apps use informal tú (Guarda tus cambios), while banking or public-sector software tends towards usted (Guarde sus cambios). In Argentina and Uruguay, vos is common (Guardá tus cambios). Mixing them in one interface is immediately noticeable.

The free sample, one paragraph of your file translated at the chosen level before you pay, lets you judge the register and vocabulary. For a released app, the Professional level, handled by the domain specialist, is intended for strings ready to ship.

Preparing the files and checking the result

• Merge sentences split across several keys: one key with a variable (Delete {{file}}?) lets ¿ sit in the right place and the word order change.
• Mark brand names, displayed error codes and product terms you keep unchanged as non-translatable.
• Make sure the JSON is valid (no trailing commas) and UTF-8 encoded.
• After delivery, place the file in locales/es/ or messages/es.json, add _many keys if you use i18next, then go through the busiest screens: navigation bar, buttons, modals, form validation messages.
• Let Intl format numbers and dates rather than hard-coding them in strings: in es-ES, 12345.5 displays as 12.345,5, whereas Mexico uses a decimal point (12,345.5).

Finally, read the report: any string left in the source language is listed with its reason, such as a variable that no longer matched.

In practice

1. Export your source locale file (for example messages/en.json) without editing it.
2. Upload it: you get an instant quote based on the words in the values, and a free sample showing the register.
3. Download the Spanish file and its report from your client area.
4. Drop it into the es locale folder, add _many keys if you use i18next, then test the screens.