App Store vs Google Play Locale Codes: A Mapping Reference

Each store keeps its own list of listing languages. Apple's list comes from the App Store Connect API locale shortcodes (opens in a new tab) page, which says the App Store is available in 175 regions and 50 languages. Google's list sits under "View list of available languages" in Play Console Help: Translate and localize your app (opens in a new tab).

The two lists overlap heavily, but the codes do not match. A script or CI job that reuses one store's folder names for the other will fail or put assets in the wrong language. The fix is a mapping table you check once and then keep.

• Apple mostly uses bare language codes: ja, ko, tr, it, sv, and so on. Region suffixes appear only where Apple splits a language (en-US, en-GB, pt-BR, pt-PT, es-MX, es-ES, fr-FR, fr-CA) and on a few others such as de-DE, nl-NL and ar-SA.
• Google Play mostly adds a region: ja-JP, ko-KR, tr-TR, it-IT, sv-SE. A few languages stay bare, including ar, id, ro, sk, th, uk and vi.
• Chinese uses different schemes: Apple identifies Chinese by script (zh-Hans, zh-Hant). Google Play identifies it by region (zh-CN, zh-TW, zh-HK).
• Hebrew uses an older code on Google Play: iw-IL, not he. Apple uses he.

The table below lists every language StoreLocale can translate into, plus English as the source language. The codes are taken exactly from Apple's shortcode list and Google's Play Console language list. The first column is the code StoreLocale uses internally and for export folder names.

Codes match exactly on both stores for Catalan, Croatian, Indonesian, Malay (ms), Romanian, Slovak, Thai, Ukrainian and Vietnamese, plus nl-NL, de-DE, fr-FR, fr-CA, pt-BR, pt-PT, es-ES and the four shared English codes. Most other languages differ only by a region suffix, such as it versus it-IT, which is easy to miss in a folder listing.

Spanish needs the most planning. If you write one Latin American Spanish set, upload it to es-MX on Apple and to es-419 on Google Play. Add es-US on Google Play only if you want a separate US Spanish listing.

A locale code is not a country. Apple's App Store localizations reference (opens in a new tab) gives each storefront a default language and a list of additional languages. Some of these defaults are not obvious.

Two practical points follow from this table. First, es-MX is the default for most Spanish-speaking Latin American storefronts, not only Mexico; Uruguay, which defaults to English (U.K.), is the exception. Second, several markets such as Türkiye, Israel and Saudi Arabia default to English (U.K.), so an en-GB listing is worth reviewing even if your source copy is US English.

On Apple, when you add a language (opens in a new tab), its screenshots start as copies of the primary language's screenshots. Apple also says that if no localization matches a user's language setting, the next most relevant localization is used. Otherwise the metadata appears in the primary language.

For app previews, Apple's upload guide (opens in a new tab) says that when a localization has no preview, the preview from the next best available language is shown instead. The same page notes that if your UI is the same across sizes and localizations, you only need to provide the highest-resolution screenshots.

On Google Play, Play Console Help (opens in a new tab) says that if you translate text without adding localized images, your graphic assets are shown from the default language. Google Play users can also view an automated translation of your app's page. That translation applies to the listing text, while words baked into screenshot images stay as uploaded.

Pick one internal language code per screenshot set and keep a single mapping file that turns it into store codes. One set can feed several listings. For example, a Brazilian Portuguese set may go to pt-BR on both stores, and a Latin American Spanish set may go to es-MX and es-419.

1. List the store locales you plan to publish on each store, using the exact codes from the tables above.
2. Assign each store locale to one screenshot set (for example es for both es-MX and es-419).
3. Rename or copy export folders to the store code just before upload, not earlier, so your source stays language-based.
4. Check the upload for each locale in the console language menu, including the regional pairs (pt-BR and pt-PT, es-MX and es-ES).

StoreLocale exports a ZIP of PNGs organized as Platform / locale / size, with folders such as App Store (iOS) and Google Play. The locale folder uses the StoreLocale code from the first table (for example ja, zh or es), so map it to ja, zh-Hans or es-MX on Apple and to ja-JP, zh-CN or es-419 on Google Play. StoreLocale does not upload to either console, so the final upload is a manual step.

StoreLocale translates into 32 target languages plus English as the source. Simplified Chinese (zh) and Traditional Chinese (zh-TW) are separate targets, and Arabic and Hebrew are supported right-to-left languages.

Each project holds one Portuguese set (pt), one Spanish set (es) and one French set (fr). If you publish both pt-BR and pt-PT, or both es-MX and es-ES, you can export that one set for both listings. To tailor the second market, export the first set, then edit the text and export again, or build a separate project for that market.

Text that an AI repaint placed inside the app UI does not change when you edit captions, so it needs a new generation, which uses credits. Have a native speaker check regional vocabulary before you upload to a second variant. This matters most for European versus Brazilian Portuguese.

Both stores support languages beyond StoreLocale's target list. On Apple these are Bengali (bn-BD), Gujarati (gu-IN), Kannada (kn-IN), Malayalam (ml-IN), Marathi (mr-IN), Oriya (or-IN), Punjabi (pa-IN), Slovenian (sl-SI), Tamil (ta-IN), Telugu (te-IN) and Urdu (ur-PK).

Google Play's list is longer still, with languages such as Afrikaans (af), Filipino (fil), Persian (fa, fa-AE, fa-AF, fa-IR), and Swahili (sw). Also note that Google's code for Slovenian is sl, while Apple's is sl-SI. For these listings you need another translation workflow, or you can leave them on the default-language screenshots.