es_ES vs es_MX, pt_PT vs pt_BR: Regional WordPress Variants

A WooCommerce store owner in Barcelona asked us a question last month that cuts to the heart of a problem every multilingual site owner eventually faces. Her site ships to Spain, Mexico, and Argentina. She translated everything to es_ES, launched, and within a week a customer in Mexico City complained that the checkout copy sounded "weird and a little old-fashioned." A week later, another customer pointed out that one product description contained a word that is completely innocent in Spain but crude in Mexico. Her question: "Do I really need separate translations for every country?"
The short answer is sometimes. The long answer depends on what you are selling, where your customers are, and how much content you can realistically maintain. This guide covers when regional variants matter, how WordPress actually handles them under the hood, and how to translate them without multiplying your workload by the number of countries you serve.
We will focus on Spanish and Portuguese because these are the two language families where variant splits cause the most real-world problems. French, English, and Arabic also have regional variants, but the stakes are usually lower.
Why Regional Variants Matter
Spanish is the second most-spoken language in the world, but "Spanish" as a single language is a simplification. A sentence that reads naturally in Madrid can sound stiff, formal, or outdated in Buenos Aires. A perfectly appropriate word in Mexico City can be offensive in Lima. Portuguese has an even bigger split - the pronunciation, grammar, and vocabulary gap between pt_PT and pt_BR is wide enough that many publishers treat them as effectively separate languages.
The Words That Actually Change
A few concrete examples so this does not stay abstract.
The verb coger means "to take" in Spain and is used constantly in daily speech. In Mexico, Argentina, and most of Latin America, it is a crude verb for sex. Using it in checkout copy ("coger tu pedido") lands very differently in Madrid than in Buenos Aires.
Ordenador is the standard word for computer in Spain. In Latin America, almost everyone says computadora. Neither is wrong, but mixing them signals to the reader that your content was translated for a different market.
Móvil (Spain) vs celular (Latin America) for mobile phone. Conducir (Spain) vs manejar (Latin America) for driving. Patata (Spain) vs papa (most of Latin America) for potato. Dozens of these diverge at high frequency.
Portuguese is even more divided. Brazil uses você for "you" in nearly all contexts. Portugal uses tu in informal speech and você as a formal marker - close to a social class signal. Business Portuguese in Lisbon and São Paulo are functionally different registers.
The Business Cost of Ignoring Variants
Users make trust judgments in seconds. A shopper in Mexico reading Spain-Spanish product descriptions registers one of two things: either the site is not really local, or the brand does not care enough to localize. Conversion rates drop. Checkout abandonment goes up. Paid ads spend in LATAM countries yields worse return because landing pages feel foreign.
For content-heavy sites, the SEO cost is also real. Google recognizes hreflang tags that distinguish es-ES from es-MX, and competitive search queries in each market are dominated by content written in that region's dialect. A ropa interior page in Spain-Spanish will not rank against Mexican competitors using local terminology like ropa íntima.
How WordPress Handles Locale Codes
WordPress locales follow the pattern ll_CC - two-letter language code, underscore, two-letter country code. The full list is defined in WordPress core and maps to translation files named theme-es_ES.mo, plugin-es_MX.mo, and so on.
Core vs Site vs User Locale
WordPress distinguishes three different locale settings:
- Site language (
WPLANG/options.WPLANGhistorically, nowoption:WPLANG): The default for your site's front end. - User locale (
wp_usermeta.locale): Per-user preference for the admin dashboard. - Runtime locale: Can be filtered at request time by plugins like Polylang or WPML to serve different content per URL prefix.
If your site is es_ES but a user sets their profile to es_MX, the admin shows in Mexican Spanish while the front end stays in Spain Spanish. This is fine for admin UI but not useful for shipping content to customers - you need URL-based or domain-based switching.
The en_GB Example
WordPress itself ships en_US, en_GB, en_CA, en_AU, and en_ZA as separate locales. They share most content but diverge in spelling (colour vs color, organise vs organize) and idioms. You can use this as a pattern for Spanish and Portuguese variants - maintain separate .mo files per region, served via URL structure.
MO File Naming for Variants
For a theme named mytheme and three Spanish variants:
wp-content/languages/themes/mytheme-es_ES.mo
wp-content/languages/themes/mytheme-es_MX.mo
wp-content/languages/themes/mytheme-es_AR.mo
WordPress picks the file matching the active locale. If es_AR is requested but no file exists, it falls back to es_ES by default (base language match) - which is exactly the behavior you want to avoid for the words we listed above.
Spanish Variants in Practice
Most publishers target one to three Spanish variants. Here is the practical decision tree.
One Variant Only
Ship es_ES if your customer base is exclusively Spain, or es_MX / es (neutral) if your customer base is primarily Latin America. Using es as the locale signals neutral Spanish and avoids the regional baggage of either extreme.
Two Variants: Spain and Latin America
The most common split. Serve es_ES for Spain and a single Latin American variant (es_MX or a neutralized es) for all LATAM countries. This is the 80/20 solution - you get most of the localization benefit without maintaining 20 separate files.
Three or More Variants
If you are running a large e-commerce site with significant revenue in Argentina, Mexico, and Chile specifically, you may want es_AR, es_MX, and es_CL in addition to es_ES. The translation cost goes up, but so does the conversion lift per market.
Region-Specific Word Lists
Maintain a small glossary per variant. Even if 95% of your translated content is shared, a glossary of 50-100 high-frequency divergent words covers most of the perceptual "this sounds wrong" issues. For more on handling domain-specific vocabulary, see our ultimate guide to WordPress localization.
Portuguese Variants (pt_PT vs pt_BR Is a Real Split)
Treat Portuguese as two languages, not two variants. Brazilian Portuguese (pt_BR) has 215 million speakers. European Portuguese (pt_PT) has 10 million. Grammar differs. Verb conjugation differs. Pronouns differ. A sentence written for Lisbon will feel distinctly foreign in São Paulo, and vice versa.
If you can only afford one, pick pt_BR - it has the larger speaker base and stronger e-commerce market. But never ship pt_PT content to Brazilian users or the reverse. The perception cost is too high.
When You Should (and Shouldn't) Create a Variant
Create a regional variant when:
- You have measurable revenue or traffic from that region (rule of thumb: 10%+ of total).
- Your product category has region-specific terminology (fashion, food, legal, finance).
- You run paid acquisition in that region and want landing page quality to match.
- You are doing local SEO and need hreflang targeting.
Skip the variant when:
- Your site is mostly transactional UI with minimal copy.
- Your traffic from the region is under 5% and you cannot maintain the extra files.
- You are launching new and can iterate based on actual customer feedback later.
A common anti-pattern: creating 15 Spanish variants "just to be safe" and then letting 12 of them drift out of sync. Out-of-date content is worse than slightly off-dialect content. Commit to maintaining what you ship.
Efficient Variant Translation Workflow
Manually maintaining five variants of a 2,000-string .po file is a recipe for drift. The workflow that scales:
1. Translate the Primary Variant Well
Pick your highest-traffic variant (usually es_ES or es_MX for Spanish, pt_BR for Portuguese) and translate that one with care. This becomes your base.
2. Derive Other Variants Automatically
Upload the primary variant .po to SimplePoTranslate and request translation to the other variant. A context-aware translator understands es_ES -> es_MX as a "regionalization" task rather than a from-scratch translation. Key vocabulary swaps (coger -> tomar, ordenador -> computadora) happen automatically while identical phrases pass through unchanged.
3. Apply a Regional Glossary Override
Keep a short glossary file with your brand's region-specific term choices. Apply it as a final pass after AI translation. This locks product names, brand terminology, and contentious vocabulary to your preferred choices per region.
4. Generate All Output Formats
Variants need both .po (for editing) and .mo (for WordPress runtime). SimplePoTranslate outputs both in a single ZIP, along with .json and .php formats if you also serve headless or custom PHP code. See our post on one file in, five formats out for why multi-format output matters.
5. Deploy per Locale
Upload the resulting .mo files to wp-content/languages/themes/ with the right locale suffix. Set up hreflang tags. Test with real users in each region if possible - native speakers catch things no tool can.
Putting It All Together
Regional variants are not a nice-to-have for serious multilingual sites - they are the difference between "translated" and "localized." But you also do not need to ship every possible variant on day one. Start with one Spanish and one Portuguese variant that matches your largest market. Add variants as your traffic and revenue in each region justify the maintenance cost.
The good news is that the translation workflow for variants is dramatically faster than building each from scratch. AI-assisted regional conversion takes an hour per variant instead of weeks. The hard part is the editorial discipline - picking which variants to maintain and committing to keep them fresh.
Ready to translate your WordPress site into multiple Spanish or Portuguese variants? Try SimplePoTranslate free - no credit card required. Upload once, generate regional variants in minutes.