Vincent Gable’s Blog

July 19, 2010


Filed under: Design,iPhone,MacOSX,Programming,Usability | , , , , , ,
― Vincent Gable on July 19, 2010

It’s a small thing, but it breeds deep suspicion. Mac OS dialogs always had “OK” buttons (capital O, capital K). Windows dialogs had “Ok” buttons (Capital O, lowercase k). “Ok” buttons in Mac/iOS software are a sign of a half-assed port, by someone who doesn’t really know the platform.

November 4, 2008

The Perils of Localization

Filed under: Uncategorized | , , , , , ,
― Vincent Gable on November 4, 2008

The sign below is supposed to say ‘No entry for heavy goods vehicles. Residential site only’ in English and Welsh.


Unfortunately the Welsh version says ‘I am not in the office at the moment. Send any work to be translated’.

Story from the BBC

(Via Successful Software.)

August 20, 2008

Hardwired Strings

With every programming language/development environment I know of, you have to do extra work to make a string localizable. For example,
errorMessage = NSLocalizedString(@"This is hard!",@"");
not simply,
errorMessage = @"This is hard!";

And it’s not just extra work, it’s a ridiculous amount of work. E.g. to create an Objective-C string, you just put an @ in front of a standard C string. But to create a localized string, you have to surround your string in ()‘s, and prefix it with a seventeen character mixed-case function-name, and finally add an empty “note” for the translator. (Rarely, you may want to add a note for the translator, and it’s good that you can, but you should not be forced to write something when it is not necessary.)

There isn’t really an excuse for this; it’s just how languages have lazily evolved.

Non-localizable (“hardcoded”) strings are a huge issue, even though they are trivially simple for programmers to fix. The problem is that translators do not work with source code, they work with resource files. So when they find a “hardwired” string that must be changed in code, they tell a programmer to fix it. And that communication is slow and costly. Especially when you consider that good localizers are probably native to the place they are localizing for — meaning that having a real-time conversation involves at least one party staying up past 3AM.

I dream of a day where "this would be localized by default"; "and"("syntactic sugar for adding optional translator notes would be there too"); and creating C"literal C-strings" would be easy.

“Unicode support libraries” are doomed to institutionalized-failure, because they will never make it easier to do the right thing. It must be so easy to create a localizable program that you wouldn’t dream of doing anything else.

Localizing In Xcode

Let me say this again in slow motion: NEVER type in ANY English string without typing NSLocalizedString() around it! This will save you SO MUCH HASSLE later on when your app is popular. Remember that enterprising polyglots can localize your code from just the binary you ship if you follow a few rules of localization, so you may wake up one day and find that someone from across the world has mailed you a your app in another language. It’s a fuzzy feeling and it gets you instant market-share.

Wil Shipley

Powered by WordPress