There, I said it. It’s been on my mind for a very long time. The process of localizing (translation plus other changes due to locale-specific laws/customs/culture) can be incredibly difficult and time consuming. Why?
Localization is not a 1:1 process
Most people think localizing a software product involves just translating the text and poof, you’re done! Not so fast.
One of the first issues you’ll run into when localizing a piece of software is things might not fit correctly. German tends to have about 30% more characters. Japanese, Korean and Chinese tend to have less characters, but a BIGGER font size. Extremely tight or fixed layouts will often break. A one-size-fits-all design is very difficult to achieve. Take a look at the site I work on, in a few different internationalizations and you’ll see what I mean.
Different laws and customs require different features per localization. France needs a link to a different privacy policy, Australia has a different logo and slightly different product name. Russian has more than one plural, which becomes very tricky when the number of items can change during runtime. (For a great/scary read about localization of 2 simple phrases, read Localizing Your Perl Programs.)
Localization is often considered an engineers responsibility
Since most people think localization requires just replacing text, many people don’t give it a thought during product naming, design, copyrighting and marketing. Well guess what? That one teeny decision someone made two months ago is now an engineers problem. A design that requires two elements to line up perfectly breaks. Attitudes and personalities sometimes don’t work well in other countries (notably Apple’s “I’m a PC. I’m a Mac” ads, which required more than just translation, but different dialogue and actors.)
N more localizations requires N times more testing
When you have different localizations of your software, you technically have different versions. This then requires testing of each version. Sure they are almost the same, but they are just different enough to break. Text can overflow or be corrupted, different settings can cause different bugs and users can use a different keyboard. (Check out Five Worlds under “Shrinkwrap”).
Finally
So I’ve stated 3 reasons why localization sucks, but it doesn’t have to suck. Why? Because if localization started at the top, engineers would have a hell of an easier time when they have to implement it all. Localization is everyone’s responsibility, not just engineers. If product managers, designers, marketers, copyrighters and yes, engineers all thought ahead and planned for localization, it would not be such an arduous task.
And that is all I ask for: localization to be a shared responsibility.