Store Localisation for the Markets You Can Legally Serve

Locale count is the wrong unit: I do not take a mandate for ten stores. I take a mandate for the markets where the app has a legal route to market and somebody who can answer a support ticket in the language. In most engagements that turns out to be between four and nine of the ten a client arrives asking for. The first deliverable is that shortlist with the reasoning behind each exclusion, because a localised listing in a market you cannot serve buys you refund requests and a regulatory conversation you did not budget for. What localisation is, in this discipline: It is a ranking act. Each App Store localisation you add gives you another thirty-character title, thirty-character subtitle and hundred-character keyword field, indexed separately. On Google Play each localised long description is indexed on its own. Translating the English metadata captures none of that value, because the terms people search in German, Polish or Spanish are usually not translations of the English terms, and the character budget forces different trade-offs in each language since the same idea is a different length. The second keyword field most teams never fill: Apple indexes more than one locale in several storefronts. In the United States storefront, Spanish (Mexico) metadata is indexed alongside English. In Canada, French sits beside English the same way. That is an additional indexed keyword field in your largest market, available for the cost of one locale's work, and it sits empty on most accounts I open. Polish, done properly: Play's handling of Polish inflection is uneven, so the long description carries the case forms that matter rather than a nominative list. Beyond search, Polish store copy written by a translator without category knowledge reads as translated, and in medtech and energy, both categories where the user is deciding whether to trust an institution, that costs conversion in a way no keyword gain repays. Regulatory, per market: For an MDR-regulated app, store metadata is labelling, and several member states require specific language covering instructions for use and the device's intended purpose. A listing that is linguistically correct and regulatorily wrong is worse than no listing. Each locale here is reviewed by someone with domain knowledge in that market, and where you do not have that person I will tell you the locale is not ready rather than ship it on a translator's word. How the work runs: Source metadata is finalised first. Each locale is then built as its own keyword and copy exercise rather than a translation pass. Each is reviewed in-market. Then Play locales go live and are read for two to three weeks before the equivalent iOS text is committed to a release, because iOS text costs a review cycle to change and Play text does not. Screenshots carrying text are flagged for recapture per locale, and where budget does not stretch, I will tell you which locales it matters in and which it does not. Not included: In-app string localisation, support and legal document translation, machine translation of any kind, and locale-specific paid media. Who should not buy this: Anyone who wants the markets priced per language, because the cost here is not in the words. Teams unwilling to fund an in-market reviewer for regulated locales, since without one the risk sits with you and I will not carry it silently. And anyone wanting a locale live next week. The review path in these categories does not compress, and quoting you a date that ignores it would be the first of several things I got wrong.