Store Localisation for Ten to Fourteen Revenue Locales

Locale selection is a commercial decision, and we make it before anyone translates a word. A locale earns metadata only if you can take payment there, answer support in that language and legally operate. For a BaFin-licensed client that removes most of the world map in one meeting, and the honest version of a ten-store project is often seven stores done properly plus three you were about to waste money on. We charge for that meeting, and it is the part of the engagement that saves the most. Keyword-first, not translation: Each locale gets its own demand research in-market. Translating the German set produces terms nobody types: the German term is a compound with no natural equivalent, the French user searches something structurally different, and Brazilian and European Portuguese share almost none of the query vocabulary in finance or beauty. So the sequence per locale is demand research, then metadata written natively against it, then review by somebody who did not write it. Spanish for Mexico and Spanish for Spain are two locales rather than a checkbox, and es-MX is worth holding on Apple even for a US-facing app, because the US storefront indexes it alongside English. Who writes and who checks: A native writer in-market who has worked in your sector, and a second in-market reviewer. Before either starts we agree a glossary and a do-not-translate list: product names, regulated terms, feature names that exist in your app interface in English. Insurance is where this earns its fee. The same product carries different statutory names in Germany, Austria and Switzerland, and a listing using the German one in the Swiss store reads as a company that does not operate there. Screenshots are part of the locale: Metadata in French over screenshots in German is a listing that announces nobody is looking after this market. Screenshot text, currency, date format and regulatory footers get localised alongside the copy, and where the app interface itself is localised we recapture rather than overlay. This is priced per locale and it is usually the largest line on the quote, which is exactly why most localisation projects quietly skip it. Translation memory goes to you: You receive the TMX, the glossary and the source files at the end of every engagement. If you replace us next year, the next team starts from your assets rather than from scratch. A vendor who keeps the memory is managing an exit cost, not running a language programme. Not included: In-app string localisation. That is a different discipline with an XLIFF pipeline, a string freeze and QA on device, and it belongs with a language services vendor or inside your own build process. We will write the specification and hand it over, but we will not become your ongoing string vendor. Also excluded: legal translation of terms and conditions, which needs a sworn translator and a different kind of liability. Not for you if: You want thirty stores. We work at ten to fourteen, because past that the locales contribute single-digit install counts and the review load stops being real review. Not for you if you want machine translation with a human pass over it, which produces text that is not wrong and is not yours, and in regulated categories produces text that is quietly wrong in a way nobody catches for a year. And not for you if the plan is to open a market before support and payments are ready. The listing is not your constraint there, and localising it will not become one.