I bought some opera tickets online the other day. For an opera in Vienna.
The website that took care of the booking was in German by default, but provided an English option. Being a web developer that specializes in building user interfaces, this intrigued me.
You see, I’ve spent a fair amount of time worrying about localization; the art (and science!) of ensuring an interface is accessible in multiple languages. It’s a tricky problem. There are a lot of pitfalls for the naive coder.
What I’ve spent much less time doing is actually using localized websites.
So as I worked my way through the booking process, I took note of what the Wiener Staatsoper did to make sure their user experience didn’t suffer when translated from German to English. Here are the results:
Good: The Layout didn’t Break.
English-German is an especially interesting translation because German words tend to be so much more… verbose than their English counterparts.
This can provide a lot of headaches for developers and designers. Yes, “speed limit” fits very nicely within the confines of that pretty tab in the stylish, narrow header. You know what won’t fit so well?Geschwindigkeitsbegrenzung.
In web design, if you’re not careful with your overflow, or you’re sloppy with your floats, or you just plain didn’t think to test real, translated strings when working on an international product, you’re in a lot of trouble.
I’m glad to report that despite my paying very, very close attention, the Staatsoper website didn’t have any awkward gaps or fields/labels that were needlessly long. This may sound obvious, but it’s a very important first step in creating a well-localized product.
Bad: Non-translated strings.
I was surprised this was such a problem. Especially since English and German are the only languages the site supports, it seems like it would be perfectly reasonable to keep both string tables up-to-date.
Alas, I found many instances of German text on English pages. Yes, some were show names and proper nouns, but just as many were not.
This feels unprofessional. As a user, I’m not expecting to see a whole lot of German after I select English. Every instance is a fault, and may cause confusion.
Good: Matching tone.
A website for something like an opera should stray on the side of elegance and formality. While I can’t vouch for the quality of the German copy, I can say that this message came through on the English side.
One specific example:
I originally attempted to complete the entire checkout in German. As I was filling in personal information, I noticed the standard * definition at the bottom of the page, letting me know that marked fields are mandatory. The description was about 6 words long!
“In English, we just say required”, I mumbled to myself.
Lo and behold, when I arrived at the same page in my native tongue, it didn’t say “required” at all. It said “These fields need to be filled in.”
A little wordy, sure, but that’s the point. This is an opera house. They aren’t targeting their copy at superusers who instantly know that * == mandatory. A fuller definition was entirely more appropriate, and the presumably-matching tone was both appreciated, and likely intentional.
Bad: Typos.
I can’t believe I even need to mention this, but: Get your strings proofread!
I spotted a handful of typos and very basic spelling/grammatical errors towards the end of the checkout process. This is just plain painful. If you’re going to go to all the trouble of adding support for a new language, go all the way and get your strings double-checked!
Typos and poor spelling/grammar look lazy and unprofessional. This is a really easy problem to avoid, and your users will thank you for it.
Good: Automatically adjusted region labels.
This was by and large the most impressive part of the Staatsoper’s localization effort. If you take only one piece of advice from this article, let it be this one.
I noticed something interesting while filling out address information. Without me taking any action whatsoever, the labels were already Canada-friendly.
Province instead of State. Postal Code instead of ZIP. Proper long-distance region already filled in. Canada at the top of the country drop-down, preselected.
I was blown away.
Granted, your average user isn’t a web developer, and won’t consider how much extra effort you put in to craft that exact experience specifically for your users, but this is something to strive for! Helping your users breeze through a form is no small feat, and playing localization to your advantage is a stellar way to improve their experience.
Overall, the Wiener Staatsoper did a more than decent job translating their user interface from German to English. The use of localized labels, matching tone, and proper layout techniques were very considerate and helped me considerably. The minor annoyances of missed and improperly-translated strings could easily be fixed, and would help make the translation an even better case study.
Now, was any of this helpful? What can you take away for your own projects?