Re: Localization strategies?
Well, Ricky I see you're one of the few who has really thought through all the issues. On 2009 Dec 22, at 19:59, Kyle Sluder wrote: On Tue, Dec 22, 2009 at 11:54 AM, Ricky Sharp rsh...@mac.com wrote: * No plural forms (while allowing plurals can be handled, it's not worth the effort IMO) That's good, because I read somewhere that in some languages, for example Arabic, there are actually different forms for one, two, and three or more. But not using plural forms at all -- I would find that to be very difficult. NSString has support for this with the syntax Blah %1$@ blah %2$@. Bizarrely, it starts at 1, not 0. You're correct Kyle, but I have enough trouble typing %1$@ myself. There it just took me about 10 seconds. When I discovered this feature a few years ago, I decided that either localizers were going to frequently type it wrong, or use some kind of automated typing that would frequently type in the wrong one. So I wrote my own localized string function which does it the way that it was done in Classic Mac OS, with simply %0, %1, %2, and is type-agnostic. That's what I use now, and it seems to be bug-free at this point.___ 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
Re: Localization strategies?
On Tuesday, December 22, 2009, at 09:59PM, Kyle Sluder kyle.slu...@gmail.com wrote: On Tue, Dec 22, 2009 at 11:54 AM, Ricky Sharp rsh...@mac.com wrote: (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. This shouldn't be necessary; see man ibtool for arguments you can use to generate strings files from your nibs automatically. Been there; done that. The issue with storing strings in nibs is that I cannot place contextual comments anywhere. * No plural forms (while allowing plurals can be handled, it's not worth the effort IMO) Don't cop out with text like One or more items… or There are 5 document(s) open. That looks unprofessional and very un-Mac. No, I'm not doing anything like that. Example: Instead of 10 problems, use Problems: 10. Apple actually makes use of this strategy, thought only for certain languages. For their English localization, they pretty much stick with the plural forms. But, for languages such as Russian, they use the colon approach. I didn't want to have two methods of doing things, so just removed plural forms in their entirety. I've worked with languages with 6 plural forms and it's just not worth the effort. This also leads to a lower translation cost. * No fragmented sentences (i.e. pieces of sentences across multiple UI elements) Is this going to work in Preference panes? If you're already going the multiple-nib route, does doing this really pose a problem? I'm sure you could get this to all work out, but just wanted to keep things simple. -- Rick Sharp Instant Interactive(tm) ___ 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
Re: Localization strategies?
2009/12/23 Jerry Krinock je...@ieee.org: I read somewhere that in some languages, for example Arabic, there are actually different forms for one, two, and three or more. Localizing plurals is hard because the plural rules for different languages are complex. Just stay away from plurals if you can. For the curious reader: https://developer.mozilla.org/en/Localization_and_Plurals /Dado ___ 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
Re: Localization strategies?
On Dec 23, 2009, at 7:38 AM, Jerry Krinock wrote: Well, Ricky I see you're one of the few who has really thought through all the issues. On 2009 Dec 22, at 19:59, Kyle Sluder wrote: On Tue, Dec 22, 2009 at 11:54 AM, Ricky Sharp rsh...@mac.com wrote: * No plural forms (while allowing plurals can be handled, it's not worth the effort IMO) That's good, because I read somewhere that in some languages, for example Arabic, there are actually different forms for one, two, and three or more. At my day job, we're moving a very large product to Arabic. We definitely didn't want to deal with its 6 plural forms. Official rules can be found here: http://unicode.org/cldr/data/charts/supplemental/language_plural_rules.html But not using plural forms at all -- I would find that to be very difficult. Not as bad as you may think. At my day job, we removed over 3,000 occurrences of plural forms to include (s). Took just three of us about a week. NSString has support for this with the syntax Blah %1$@ blah %2$@. Bizarrely, it starts at 1, not 0. You're correct Kyle, but I have enough trouble typing %1$@ myself. There it just took me about 10 seconds. When I discovered this feature a few years ago, I decided that either localizers were going to frequently type it wrong, or use some kind of automated typing that would frequently type in the wrong one. So I wrote my own localized string function which does it the way that it was done in Classic Mac OS, with simply %0, %1, %2, and is type-agnostic. That's what I use now, and it seems to be bug-free at this point. Yea, ended up writing my own utility as well. ___ 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Localization strategies?
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: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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Localization strategies?
On Tue, Dec 22, 2009 at 11:54 AM, Ricky Sharp rsh...@mac.com wrote:
(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.
Luckily this isn't always necessary. But there's no substitute for when it is.
(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.
This shouldn't be necessary; see man ibtool for arguments you can use
to generate strings files from your nibs automatically.
(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.
Eeeenteresting.
(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.
Also enteresting.
* No plural forms (while allowing plurals can be handled, it's not worth the
effort IMO)
Don't cop out with text like One or more items… or There are 5
document(s) open. That looks unprofessional and very un-Mac.
* No fragmented sentences (i.e. pieces of sentences across multiple UI
elements)
Is this going to work in Preference panes? If you're already going the
multiple-nib route, does doing this really pose a problem?
* 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.
NSString has support for this with the syntax Blah %1$@ blah %2$@.
Bizarrely, it starts at 1, not 0.
My $0.02.
--Kyle Sluder
___
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
Re: Localization strategies?
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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Localization strategies?
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
Re: Localization strategies?
On 2009 Dec 21, at 01:27, Symadept wrote: 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. Well, of course there are tools for this. I use and recommend Max Seelemann's Localization Suite, and just learned that it has now been open-sourced. This is great news, since a localization tool is something that you'll often want to tweak. For example, I'd love to make it scriptable from the command line so I can add it to my Build script. http://www.loc-suite.org/ More good news is that Max is that it looks like Max is actively working on it. If you go with multiple nib files for various locale, UI maintainance will become hectic. We discussed the pros and cons of this recently -- read this... http://lists.apple.com/archives/Cocoa-dev/2009/Dec/msg00363.html (*) On 2009 Dec 20, at 12:30, Ricky Sharp 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. Since any app can by definition do an infinite number of tricks (and errors), the test coverage they get when they run the app is going to be 85% at best before they get tired of mousing around and ship it back to you. So, I would recommend giving this localizer good comments. I try to make my strings files read like API documentation, with comments defining the contract stating how each string can be used (and re-used). How have others tackled localization? The dearth of replies should tell you something :) Here's my answer: A combination of techniques. Localization is always costly, iterative, compromised, and imperfect. Some have used each of the techniques you propose, and others have rejected them. They may well be optimum for your situation. Judging from your post, you are a good tech writer and thus might want to rely heavily on .strings comments as I do, and choose localizers which do the same. Jerry (*) I can rarely get Apple's List Search to find threads, even if I'm looking at an email I sent and copy keywords exactly. But then I found it in a Google search Bug has been filed -- again -- 7490709. ___ 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
Re: Localization strategies?
On 20.12.2009, at 21:30, Ricky Sharp wrote: 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. One approach to avoid the whole IBOutlet excess would be to create subclasses of the standard view classes which, when they are loaded, use their contents/title as the key and pass it to NSLocalizedString(). That way, your NIBs only contain keys, and the .strings files can hold the actual strings, including comments. Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de ___ 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
Re: Localization strategies?
On Dec 21, 2009, at 8:18 PM, Uli Kusterer wrote: On 20.12.2009, at 21:30, Ricky Sharp wrote: 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. One approach to avoid the whole IBOutlet excess would be to create subclasses of the standard view classes which, when they are loaded, use their contents/title as the key and pass it to NSLocalizedString(). That way, your NIBs only contain keys, and the .strings files can hold the actual strings, including comments. Another possibility: instead of creating a bunch of subclasses and having to specify that subclass for each view you create in IB, you could write a method that recurses through all views in a window. Check each view for a title or name property (maybe stringValue too), and maybe use some convention like #TITLE# to indicate you want to replace that title or name with a localized string to be gotten via NSLocalizedString(). Check whether the view is a table view that displays column headers, and if so, iterate through its columns. Do similar special-casing for tab views and segmented views and anything else that needs it. This method could be in its own utility class, where it could be called by awakeFromNib. Offhand I think this is how I would do it if I wanted to take the approach of putting keys in the nib. --Andy ___ 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
Re: Localization strategies?
On Dec 21, 2009, at 8:18 PM, Uli Kusterer wrote: On 20.12.2009, at 21:30, Ricky Sharp wrote: 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. One approach to avoid the whole IBOutlet excess would be to create subclasses of the standard view classes which, when they are loaded, use their contents/title as the key and pass it to NSLocalizedString (). That way, your NIBs only contain keys, and the .strings files can hold the actual strings, including comments. Another possibility: instead of creating a bunch of subclasses and having to specify that subclass for each view you create in IB, you could write a method that recurses through all views in a window. Check each view for a title or name property (maybe stringValue too), and maybe use some convention like #TITLE# to indicate you want to replace that title or name with a localized string to be gotten via NSLocalizedString(). Check whether the view is a table view that displays column headers, and if so, iterate through its columns. Do similar special-casing for tab views and segmented views and anything else that needs it. This method could be in its own utility class, where it could be called by awakeFromNib. Offhand I think this is how I would do it if I wanted to take the approach of putting keys in the nib. --Andy It's best not to localize in a locale unless you are going to do it correctly! That means hand tooling the UI. Apple realized long ago that GUI elements must be localized correctly. This means far more than translation with the inevitable string length differences. This means making an interface make sense in a localized format. One size fits all only when the UI is intuitive and self explanatory. (Photobooth is an excellent example) It tends to be true that your UI could use improvement if it is overly textual. A good UI design can avoid localization being painful. This is the true shortcut in localization ___ 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
Localization strategies?
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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
