Wil Shipley On Localization
October 20th, 2009Lots of great information and sample code to boot.
I am always feeling overwhelmed and helpless when it comes to localization. The tools at our disposal don’t make it easy enough to “do it perfectly,” so I end up (for the most part) not offering localizations at all.
Maybe I should give in and adopt Wil’s strategy of essentially providing a UI that fits all languages. Unwanted white space be damned!
October 21st, 2009 at 12:10 am
I found DL2 a pain to localize, because it didn’t have enough space for a lot of German strings. http://code.google.com/p/google-toolbox-for-mac/wiki/UILocalization looks like a pretty good solution to that problem, though.
October 21st, 2009 at 1:18 am
I would think the decision to localize would be based on the US sales for the most part. So if your app is pulling in 50k/year and you expect a 20% increase to come from localizing it, the question becomes is the added workload of all that localization worth the $10k you expect to gain. Alternatively, you could be spending that time improving your app for the English market, and those improvements may generate sales that far outweigh the localization sales (especially when you factor in the costs of localization). In other words, the worse your app is doing, the less sense it makes to localize (unless there’s special circumstances–e.g. so hypothetically, let’s say Blogging is currently a HUGE fad in Japan where 60% of the population has a blog; it would probably make a lot of sense to do that localization for MarsEdit regardless of US sales figures).
Now if you’re Wil Shipley and generating massive revenue, then you’d be crazy not to localize. I have no idea where Red Sweater’s apps fall into the spectrum, but I would certainly examine the decision to localize on an app-by-app basis. The other thing to consider about localization is that once you do it, it’s pretty hard to go back and abandon the users of that language in the future if the revenue simply doesn’t justify the time and expense of maintaining ongoing support for that language–it’s a pretty serious commitment.
Last is considering the support angle. How is support best handled with non-English speaking customers? Would you have to use a 3rd party service? What kind of quality is reasonable to expect from a service like that, and how expensive is it.
October 21st, 2009 at 3:15 am
Ack!
All that time to make a UI that looks so polished and then consider throwing it all away because you drew a line at internationalization?
Talk to Dan Schimpf about MacJournal Make international friends who know are polyglots (or at least diglots) to do each localization for you.
Internationalizing software is akin to not skimping when it comes to MVC or clean architecture, and I have to disagree with Shipley….
He wrote:
Even if you’re not going to do a non-English version, you should still be strict in following internationalizing. I still can’t bring myself to put literal user-facing strings in code without them a) being wrapped in an NSLocalizedString() function and also putting an entry for the same string in a .strings file.
Mac people care, even when they don’t speak English. Often even moreso, because they’re doubly in a minority.
October 21st, 2009 at 7:37 am
Well there are tools out there that tremendoulsy help the integration of localisations. I use iLocalize and it makes the process a breeze.
If the application has the proper structure, it”™s a non issue.
There are also many localizers out there who volunteer to do the job and if I”™m not mistaking, that was the case for Delicious Library so really the cost of integrating localizations in this specific case should be *minimal*.
On a related note: The current version of DL though cannot be localized at all becaause the .nib are compiled and cannot be edited.
October 21st, 2009 at 7:50 am
In the case of Delicious Library again, I would add that the statistics ae biased. If I take the exemple of the French localization: it”™s full of nasty issues, cropped strings, terms used in the wrong context or not localized at all. It”™s also completely outdated. No idea why it was never corected (despite various reports and offers to help out if need be).
The application got very very bad press for it in several French-speaking websites and I don”™t doubt it hurt the sales for French users.
I don”™t know how it is or the other languages, but that kind of issues have to be taken in conosideration before making conclusions on the increased sale revenues through localization. Would you buy an application where you wouldn”™t understand half the User Interface?
The fact is that (for a properly done localization), there is a sale revenue increase. If integrating the localization requires minimal work, why stay away from it?
October 21st, 2009 at 8:02 am
(…and DL had a nasty bug for the longest time ever and couldn”™t deal with accented letters on Amazon France. Not good).
No really, if the application has all string localizable, mostly everything is done.
Provide tha app with editable .nib and use iLocalize, it will do all the heavy lifting for you. I fear Will Shipley made his life way too complicated by not using the right tools.
The real problem is to get users in other country to get to kno your software and t realize i is localized. The best way might be to ask your localizer help craft a letter to a few selected local websites…
October 21st, 2009 at 9:13 am
I keep on posting, but it”™s a matter obviously close to my heart.
Trying not to be all negative though: Wil”™s post raised a few good points and I”™d like to comment back on some of them (and then I”™ll be quiet, you”™ve probably had enough of my prose by now :-> ):
– some languages require more space than English. French requires more space 90% of the time. If you want to save some time and avoid cropped strings that will need to be resized, make the text fields in the .nib longer than just what you need in English.
– dealing with pictures is a pain. If you can, provide the multilayer sources to the localizers, but it never is an easy task.
– xib and compiled .nib are unusable at this time. I disagree with the idea to provide everything only in .strings though. Simply provide editable .nib. The layout *will* have to be adjusted but it could be not too bad if you followed my first advice. Localizers will need the developer tools anyway if they want to use iLocalize too (and I would strongly strongly encourage them to do so). This also allows for visualizing the strings in their context and avoid misunderstanding and issues with similar strings meaning different things in different context.
– Don”™t ever ever ever split-up a sentence in multiple strings. Most of the time localizing it is impossible because 1) localizers do not know what string goes with what, and 2) the grammatical structure in other languages might require a completely different structure and the result in the localization is *not* pretty :-)
October 21st, 2009 at 9:53 am
The support aspect is one that I never thought of before. Selling mainly to a very small segment of the EU countries, due to the nature of my product… I can support 80% of my customers easily by using my native german or english. But yes, already the french clients make it rather hard to give the support I usually expect to give. Something that shouldn’t be covered to easily…
Daniel: Call me if you localize and need german support in addition ;-)
October 21st, 2009 at 7:50 pm
Scott:
If you integrate the tools I posted, you can put in a new localization by simply dropping a directory into Xcode. You’re done. I’m not sure why you wouldn’t do this, even if your app only makes $100 a year.
Corentin:
The glitches in the French localization are my fault because I haven’t been responsive enough in fixing my interface files for French and German, but aren’t endemic to the process I outline. I stand behind it.
It’s not true you can’t localize DL — the whole point of my post is you CAN localize DL, without access to the NIBs.
-Wil
October 21st, 2009 at 8:08 pm
Will:
True, you can extract the strings with proper tools, and localize them, but:
1) you can”™t see the strings in their contect in the nib since you can”™t open the .nib in IB
2) you have (as a localizer) to rely on the developer to readjust the layout. In my experience, that hasn”™t always resulted in a great job. Especially since sometimes, if you see the string in its context and realize how long it ends up being, you can make wiser, shorter choices of words or phrasing.
3) non editable .nib means not being to use iLocalize and not be able to track modified strings between builds/updates. Really really not something I”™d want to do as a localizer.
In any case, I still stand by my previous offer(s). If you want any help updating the French localization, you can always contact me (especially if you have a version with editable .nib ;-) ).
October 22nd, 2009 at 10:03 am
Wil and others – I’ve been myself working on a solution similar to this and implemented it in upcoming Cashculator application.
I’ve now tried using Wil’s solution instead, since it’s close to mine but theoretically better written but have come to an issue with Wil’s method not being invoked for NIBs that are loaded with NSViewController (which are most of my views). Thus, they are not localized.
Second issue I had is that the shell scripts phases that Wil provided do not work if you don’t change your shell to zsh (in Xcode), at least for me. I don’t know why Wil hasn’t mentioned it.
Now, I can’t figure out how to integrate this with NSViewController and it’s a pity. I find that it uses NSNib directly to load the NIB, seemingly bypassing NSBundle and thus Wil’s code.
Any help with this?