Should I use es-ES, es-MX, or es-419 for my app?

Pick the locale that matches your biggest market. Ship es-ES for Spain and es-MX for Mexico as distinct locales. Use es-419 (Latin America & Caribbean) only as a broad fallback when you can't maintain per-country string sets — it can't correctly handle country-specific vocabulary or Argentine voseo.

What's the actual difference between es-ES and es-MX in app strings?

Register (Spain leans on tú; Mexico varies between tú and usted), vocabulary (ordenador vs computadora, móvil vs celular, coche vs carro, añadir vs agregar), and formatting — Spain writes 1.234,56 € while Mexico writes $1,234.56. Same meaning, different words your users scan for in buttons and labels.

Does Spanish translation break my placeholders?

No. iOS placeholders (%@, %lld, %1$@) and Android placeholders (%s, %d, %1$s) are preserved verbatim, including positional indexes. Because Spanish frequently reorders arguments, positional forms like %1$@ and %2$@ are worth using so the translation can move them safely.

How much longer is Spanish text than English?

Spanish typically runs about 15–25% longer than English. A short English label like "Add to cart" becomes "Agregar al carrito," so leave room in fixed-width buttons and labels to avoid clipping or truncation.

How many plural forms does Spanish need?

Spanish has three CLDR plural categories: one, many, and other. "one" covers 1, "many" is used for large or compact numbers such as multiples of a million, and "other" handles everything else including 0 and counts like 5. Use a plurals block (.stringsdict on iOS) rather than concatenating a number into a sentence.

Translate Your App to Spanish: es-ES (Spain) vs es-MX (Mexico)

By The strings.dev team · Last updated 2026-07-17

"Spanish" is not a single target. A user in Madrid and a user in Mexico City read different words for phone, car, and computer — and expect different currency symbols and decimal separators. Ship one generic es and you get the register and vocabulary wrong for roughly half your audience.

This page is about picking the right Spanish locale to translate your app into — es-ES for Spain, es-MX for Mexico — inside your .xcloc or strings.xml, not just checking a "Spanish" box.

Pick the market first, then the locale

The BCP-47 codes you'll actually put in your project map to real markets. Start from where your installs are, then choose the locale that serves them:

Locale	Serves	App Store market
`es-ES`	Spain	Spain
`es-MX`	Mexico	Mexico
`es-419`	Latin America & Caribbean (regional fallback)	Wide LatAm reach
`es-US`	US Hispanic audiences	United States

es-419 is a UN M.49 region code meaning "Latin America and the Caribbean." It's a sensible fallback when you can't ship a per-country string set, but it papers over real differences — Argentine voseo, Chilean slang, Mexican vocabulary. If Mexico is your biggest LatAm market, ship es-MX explicitly rather than leaning on es-419 to guess.

App Store market reach (Spain vs Mexico vs US Hispanic vs wider LatAm) is context for which locales to prioritize — it's advisory. strings.dev localizes the strings inside your app, not App Store listing metadata.

Where the variants actually diverge

Register: tú, usted — and vos

Spain leans heavily on tú (informal) for consumer apps: "¿Quieres continuar?" Latin America is less uniform. Mexican apps often use tú too, but formal usted ("¿Desea continuar?") reads as more respectful in some flows. And a plain es translation can't produce voseo — the vos form used in Argentina and much of Central America ("¿Querés continuar?") — which is exactly the kind of thing a "just Spanish" tool silently drops.

Vocabulary changes by country

These aren't stylistic nuances; they're different words your users scan for in a button or label:

English	es-ES (Spain)	es-MX (Mexico)
computer	ordenador	computadora
mobile phone	móvil	celular
car	coche	carro
to add (to cart)	añadir	agregar
shopping cart	cesta	carrito
to drive	conducir	manejar

Note the trap in that table: carro means "car" in Mexico but "cart" in Spain. Ship ordenador to a Mexican user and it reads as foreign — correct Spanish, wrong country.

Numbers, currency, and dates

Formatting flips too, and it's easy to miss in QA:

Currency: Spain uses the euro (€); Mexico uses the peso (also written $, code MXN). Never hard-code a symbol into a translated string.
Decimal separator: Spain writes 1.234,56 € (comma decimal, period/space grouping). Mexico writes $1,234.56 (period decimal, comma grouping — like the US).
Dates: both use day-month-year (16/07/2026), but drive dates through the platform formatter, not the string.

One string, two markets

Here's an iOS .strings "added to cart" line — English source, then the two variants. Watch the %1$@ positional placeholder survive intact while the wording shifts:

/* English source (en) */
"cart.added" = "%1$@ added to your cart";

/* European Spanish (es-ES) */
"cart.added" = "Se ha añadido %1$@ a tu cesta";

/* Mexican Spanish (es-MX) */
"cart.added" = "Se agregó %1$@ a tu carrito";

Same placeholder, two deliberately different sentences: añadido / agregó (Spain reaches for the present-perfect se ha añadido, Mexico for the simple preterite se agregó), and cesta / carrito. A tool that offers only "Spanish" gives you one of these and the wrong register for the other market.

Placeholders, expansion, and plurals

Three things to plan for when Spanish enters your UI:

Placeholders survive. iOS %@, %lld, %1$@ and Android %s, %d, %1$s are preserved verbatim, including positional indexes — Spanish word order often reorders arguments, so positional forms (%1$@, %2$@) matter more than in English.
Text expands. Spanish typically runs about 15–25% longer than English. "Add to cart" becomes "Agregar al carrito"; a comfortable English button can clip. Give labels room to grow.
Plurals use three CLDR categories. Spanish has one, many, and other. one covers 1; many is reserved for large or compact numbers such as multiples of a million; other handles the rest, including 0 and everyday counts like 5. Most app strings only exercise one and other, but wire up an .stringsdict / plurals block rather than concatenating a count.

Shipping Spanish variants with strings.dev

strings.dev treats es-ES and es-MX as distinct, first-class locales — not a single "Spanish" dropdown — so each gets its own register, vocabulary, and formats. Your app description is fed into every translation as context, brand phrases are protected via placeholders, and per-string notes let you pin register ("use tú," "keep it formal") where it matters. Upload your native .xcloc or strings.xml, pick the Spanish locales your markets need, and get back files that drop straight into Xcode or your Android resources.

If Spanish is your first language, the free Indie tier covers one language at no cost — try it free. Adding Spanish as a second or additional locale (say, es-ES and es-MX alongside your existing language) needs Indie Plus — $20/mo, or $10/mo billed annually — which unlocks unlimited languages. See pricing for the full comparison.

For the exact BCP-47 codes to use in your project, see the iOS & Android locale codes reference, and the mobile app localization guide for the end-to-end workflow.