Apple ecosystem

The terrain

Apple maintains approved translations for every system concept in every supported locale. iCloud, AirDrop, Spotlight, Stage Manager, the Dock, the menu bar: each has an Apple-defined translation that Apple’s reviewers expect to see in your strings. These are not suggestions. Strings that use non-approved terminology for system concepts fail App Store review. The reviewer does not explain why; the app comes back rejected.

Character constraints compound this. Menu labels, button titles, and push notifications have limits that vary by locale. The German translation of “View all recent activity” is longer than the English. The abbreviated fallback has to be linguistically coherent, not just shorter. Choosing which words to cut requires translation judgment, not a character-counter.

The Apple ecosystem now spans more platforms than it did five years ago. Mac, iPhone, iPad, Apple Watch, Apple TV, and visionOS all have platform-specific UI conventions and (in visionOS’s case) new terminology for concepts that did not exist in the previous localization vocabulary. The spatial computing lexicon is still being established; getting it right early matters.

What we have learned

Apple HIG compliance is a vocabulary problem, not a translation problem. A translator who knows Japanese well but does not know that 「スポットライト」 is the approved Apple Japanese term for Spotlight will produce a perfectly good Japanese translation that gets the app rejected. The fix is a glossary aligned to Apple’s per-locale terminology resources, maintained as the platform evolves.

We have built and maintained Apple-aligned termbases for clients across the full Apple platform stack. The termbases include the Apple-approved term, the forbidden alternatives, the platform context (iOS only, macOS only, all platforms), and the version at which the term was introduced or changed.

Character constraints require a different kind of editorial judgment per locale. German, Finnish, and Hungarian tend to run long. Japanese and Korean can be more compact. The abbreviation strategy that works for German (dropping articles, using shorter synonyms) does not apply to Japanese. Each locale needs its own abbreviation logic, tested against the actual UI at the actual layout.

A typical engagement

We start with a glossary alignment pass: mapping the client’s existing terminology against Apple’s HIG resources for each target locale. For new apps or major redesigns, this happens before translation begins. For existing apps with a revision history, it is a compliance audit of the legacy strings.

Translation works against the aligned glossary and against Apple’s own resources. We flag character constraint violations as a separate QA step, with locale-specific fallback proposals rather than just flags.

For submissions, we do a pre-review pass specifically against App Store submission guidelines: not just translation quality, but compliance with Apple’s current reviewer expectations. The two hours spent on that pass reliably prevent a two-week rejection cycle.