Keyword Localization Helper

App Store search queries are habits, not prose. Users type the shortest string that has worked for them before, and that string is shaped by local app culture: which loanwords took hold, which brand became a generic term, which script variant the keyboard favors. A fitness app localizing “meal planner” into German must choose between “Essensplaner”, “Mahlzeitenplaner”, and the English loan “Meal Planner” — three defensible translations with wildly different search volumes.

Script adds another layer. Japanese users may search the same concept in kanji, katakana, or romaji; Korean mixes Hangul with English fragments; Arabic users often search Latin-script brand names inside Arabic queries. A localization workflow that outputs one “correct” translation per keyword systematically misses the variants where the volume actually lives, which is why this tool returns intent-matched alternatives rather than a single rendering.

Once you have native terms, treat the target locale as a first-class keyword project, not a copy of your English field. Each localization owns an independent 100-character keyword field, so build it from scratch: singular forms, no spaces after commas, no terms already present in that locale’s name or subtitle. Duplicating a word across fields wastes characters in any language.

Also decide deliberately what stays in English. High-recognition category terms — “VPN”, “AI”, “PDF”, “fitness” in many European locales — often outperform their translations and should be kept verbatim, freeing budget for terms where the native word dominates. The helper marks these keep-in-English candidates explicitly, because they are the cheapest wins in any localization pass.