Re: Localization strategies?
Re: Localization strategies?
- Subject: Re: Localization strategies?
- From: Ricky Sharp <email@hidden>
- Date: Tue, 22 Dec 2009 11:54:27 -0600
Thank you all for the replies.
Here's my final plan:
(1) Have separate nibs for each language. I agree with those that say you cannot have a one-size-fits-all layout. Each nib will thus carry layout, font size, style, etc. that makes sense for a particular language.
I've already "pseudo-localized" the nibs to hopefully address 90% plus of any truncation issues.
(2) Externalize all strings from the nibs and put them into Localizable.strings. This allows me to have a single file to hand off to translators. I can also group like-items together and fill in nice contextual comments.
Nibs will still contain text for buttons, etc. but will all be in the form {s} (a string wrapped in curly braces).
(3) For runtime creation of fonts (e.g. boldSystemFontOfSize), call into my special "Font" factory. I ended up creating a "fonts.plist" localized file. Each version will contain two attributes per key (font size and whether or not its bold). At runtime, I now read in the appropriate plist and gather the metrics for the fonts I need to create.
(4) Leverage my existing automated-test infrastructure to do a full product walkthrough (setting up proper data along the way) and generating screen-shots. Such screen shots can now be viewed by the localization company's "QA" team to ensure all text is valid within its context.
Furthermore, the "walkthrough" script will mine all text on the screen and look for curly braces. That will mean that either an outlet isn't connected or its localized string key is either missing or malformed.
The walkthrough script will also be generating HTML files (which will provide links to all screenshots). This will allow everyone to view screenshots side-by-side (comparing original English to a second language)
Finally, here's some other things I have already done to ensure translation will be as smooth as possible:
* No plural forms (while allowing plurals can be handled, it's not worth the effort IMO)
* No fragmented sentences (i.e. pieces of sentences across multiple UI elements)
* No hardcoded ordering of parameters. i.e. template strings like "Blah {0} blah {1}." may be "{1} blah blah {0}" in other languages. Each placeholder is always matched to the appropriate vararg argument.
___________________________________________________________
Ricky A. Sharp mailto:email@hidden
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden