jump to navigation

To localize or not to localize February 25, 2008

Posted by globalizer in Locales, web applications.
trackback

That is the question.

And here I am talking not about translations, but about the kind of formatting that your software performs on dates and numbers, for instance. You really need to make a conscious decision in this area – do I want my application to be locale-dependent or not – and then make sure you follow through in every single function and on every screen.

Otherwise you may easily end up with the kind of totally unusable application that my electrical coop uses for online bill payments.

I will save them embarrassment and not actually post the specific name of the coop, although I would feel no qualms about outing them; I sent an email with the details of the problem, and the fix, more than 2 years ago, and since then

  • I have received no response what so ever,
  • and have seen no change in the behavior of the application

“OK, will you get to the point?” I hear you ask, and right you are:

My electric coop gives me the opportunity (which I appreciate, btw.) to view and pay my electric bill online. And since I use my system for a lot of different language testing my browser will quite often have a language that is not English at the top of my language preference list. Almost all web applications use that language preference to decide which locale formatting to use, and my coop application is no exception.

Thus, with my browser language set to Danish, my bill displays like this:

Coop bill

So far, all is well. The web application has seen that I prefer Danish, so it displays the amount I owe using the Danish format with a comma as the decimal separator. When I click “Pay” on the page, I get the following message displayed, however:

Coop error

Oops, I see that this error actually contains the web address – oh well.

And here’s where the disconnect is revealed: the guy implementing the entry field validation has hardcoded it to the US English format, no matter what number format the application itself has chosen to use when it displays my bill.

There is of course a whole host of issues here:

  • The message assumes the customer typed in a value, while it was in fact filled in by the application
  • The message provides very little help to the hapless user who has no idea why the application refuses to understand the number it put in the entry field itself
  • A little bit of proof reading/testing of the message would not have been amiss, that might have uncovered the missing spaces where the sentences are concatenated

Just to complete the picture, I also got a nice little NumberFormatException displayed in the browser at the end:

NumberFormatException

All in all, not a good localization story at all. And proof that you are much better off being completely locale-independent than half way there.

Advertisements

Comments»

No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: