iOS Internationalization: Designing for Translators
Article Summary
Lou Franco from Atlassian learned the hard way: internationalizing Trello's iOS app wasn't just about code. The translation files themselves became a critical UX layer that could make or break the entire localization effort.
When Trello internationalized their iOS app, they discovered that poor translation comments led to an avalanche of translator questions. This article shares how they transformed their localization workflow by treating translation files as a user interface, not just technical artifacts.
Key Takeaways
- Trello enforces 100% translation comment coverage as a coding standard
- Custom placeholder system replaced stringWithFormat to prevent crashes from translation errors
- Simple tagging mechanism for formatting avoids security risks of parsing HTML
- Post-process script adds comments to XIB strings since Xcode doesn't support it
- Translation linter validates strings before import to catch issues early
Comprehensive translation comments and custom formatting systems reduced translator confusion and prevented crashes from localization mistakes.
About This Article
Lou Franco's team ran into a real problem: Xcode doesn't have a built-in way to add translation comments to strings in XIB or Storyboard files. This meant translators couldn't see the context they needed for UI elements without some kind of workaround.
Atlassian built a post-process script that takes comments provided separately and automatically merges them into the strings that XIB generates. This way, every string gets the guidance translators need, even the ones from interface builder.
Trello added contextual comments like width restrictions and usage instructions to their strings. This cut down on translation issues so much that most questions now are just about edge cases instead of the same problems coming up over and over.