Just my 2c gained from translating UIs in french. Localized strings can show a great variation in length even among close languages such as english and french. Moreover, english allows for short sentence/syntax whereas french does not, at least not easily.
From what I've seen, there are two strategies to adapt to different strings lengths : -a managed layout (not too bad but not perfect) -designing as many UI elements as locales (perfect but tedious). AFAIK Apple chose the second solution, so that's about the only way to go on this platform I suppose. Substitution of localized strings in english UI elements (eg dialogs) will result in either text being clipped out of labels, label frames too wide in english because they have to make way for other localized strings or localized strings too short to make sense because they have to fit. And sometimes, the syntax has to change anyway and the dialog has to be rethought somewhat. So all in all, specifically designing UI elements for each locale make sense if you want the best results. It is also time consuming and thus (probably) expensive. It's weird to see big companies fall into localization blunders. Pixar's Wall.E, for example, shows at some point in the movie the axiom ship "Operation Manual" which in french is translated as "Manuel d'Opération", an easy translation except we never refer to operation manuals using this term (although it's grammatically correct). Le 21 déc. 2009 à 10:27, Symadept a écrit : > > Hi Ricky, > > Even in my one of the project I am doing the same. Localizable.strings > (english) version shall have all the strings in Key-Value pair format, > "Hello" = "Hello"; And you can keep the comment on top of the string /* > Welcome text */. > > And you can have many IBOutlets to set the string at runtime, as you > mentioned, with NSLocalizedString(@"Hello", nil). Now you generate various > language localizable.strings by Add Localization (mail me if you think you > need more info) from XCode and change the file format to UTF16. Now these > files shall still show you english. Now pass these files to Localization > team and they shall simply copy paste the other version of the string in RHS > of the corresponding files. > > If you go with multiple nib files for various locale, UI maintainance will > become hectic. Hence you are in right track. > > All the best. > > Regards > Mustafa Shaik > > > On Mon, Dec 21, 2009 at 4:30 AM, Ricky Sharp <rsh...@mac.com> wrote: > >> >> In getting quotes from many localization companies, I've found that some >> have different processes. For example, one company would prefer if I just >> provide .string files. During their QA process, they'll then run the app >> and look at everything in context. >> >> While generating .strings from nibs is easy to do, there's a problem in >> that there seems to be no method of putting contextual comments into a nib. >> And there's no way I would hand-edit comments in the generated .strings >> files. >> >> Thus, I'm wondering if it would ultimately be worth it to externalize all >> strings from my nibs and just put everything in my single .strings file. >> This will clearly involve me adding tons of IBOutlet ivars just so that at >> runtime I can set their text with NSLocalizedString APIs. >> >> I still plan on having separate nibs though for each language (to account >> for text bounds, font sizes, etc.) >> >> How have others tackled localization? >> >> ___________________________________________________________ >> Ricky A. Sharp mailto:rsh...@instantinteractive.com >> Instant Interactive(tm) http://www.instantinteractive.com >> >> >> >> _______________________________________________ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >> >> 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: >> http://lists.apple.com/mailman/options/cocoa-dev/symadept%40gmail.com >> >> This email sent to symad...@gmail.com >> > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > 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: > http://lists.apple.com/mailman/options/cocoa-dev/francois.guillet%40wanadoo.fr > > This email sent to francois.guil...@wanadoo.fr > François _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
