Voulez-vous collaborer avec moi ce soir?

September 10, 2007

Arch-Image‘s Laurent Brixius recently posted a very good review of Cozimo. Laurent is Belgian and decided to write this review in French. If you read French or would like to practice it a bit, go get a good bottle of French wine and then read the review, here. Some cheese and a baguette might be a good idea as well.

In his review, Laurent points out that digital content creators are often fluent in English but their clients aren’t necessarily comfortable with it. Cozimo lets professionals such as Laurent collaborate with partners and clients in their native language.

Internationalizing online applications is increasingly important, yet it is a significant effort even when you are fluent in many languages, happen to know somebody that is, or are lucky enough to afford a team of professional translators. There are a few points worth taking into account when internationalizing a web application.

Internationalizing the user interface is integral to the user interface design

Labels, menus and links often require more space in French than in English, and probably less in Japanese. UI designers don’t know exactly how much space a user interface control will occupy once it’s rendered. If you care about your design, you can’t rely on fixed layouts for international user interfaces.

User interface designers need to answer the same questions they ask themselves when designing a fluid content layout: which constraints are rigid? what/where are the degrees of freedom? what happens to our latest snazzy fluid UI layout when (translated) properly-aligned controls don’t fit in one line anymore?

And what about all that time and effort invested in finding the perfect hotkeys? Bad news! It’s probably worth very little in other languages. Are you relying on icons to stay out of trouble? Icons probably make things worse in an international context.

A bit of abstraction may help here. Designers use and abuse of Lorem Ipsum for content areas. Following a similar approach for user interface controls can also be a good exercise.

And all of this, of course, affects important implementation details: does our CSS enforce a white-space: no-wrap style so that translated UI elements don’t break when the window is resized or the user increases the font size? are we floating or positioning the UI controls? Designers need to communicate these dynamic aspects to the developer taking on the implementation task. Which takes me to the next point…

The internationalization effort needs to be backed up with serious code and serious coders

Internationalization isn’t just a feature that you add on top of the product. It’s a core property of the system and one that needs lots of engineering attention and love. Do your engineers know The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)? Is your application framework i18n-friendly? Are you adding internationalization in a rush? You better not! Internationalization affects every single line of code that deals with text, both as content and user interface components, in both server- and client-side code. If text translation is done on server-side code, client-side code can no longer dynamically manipulate UI text elements based on hardcoded content; it must always rely on content generated by the server. And on the server side, most layers are affected by or involved with internationalization. Text content has to make it to the functional (non presentation) layers to be sent in an email or to be sanitized for cross-site scripting, for example.

Designers, developers and translators must work together in this effort

In an ideal world, translators work with translation files and don’t even see the page templates nor source code in the presentation layers. But they do rely on developers properly building translation messages and being aware of localization issues. Developers who care rely on designers providing i18n-friendly designs. Designers who care expect a few collaborative iterations with developers, ensuring that the dynamic aspects of the design layout are properly dealt with (traditional design tools won’t capture those aspects).

Sound like lots of trouble? Resistance is futile. You will be internationalized! Internationalizing online applications is no longer a luxury. It’s a necessity. It’s a trend and a business enabler that serious online companies cannot afford to ignore anymore.

If internationalizing online applications seems difficult, it’s probably a good time to realize that internationalizing real collaborative online systems is even more complicated. Multilingual content is shared among many clients with different default languages, and the server has to deal with synchronous and asynchronous content delivery in this context. Luckily, getting it almost right usually boils down to remembering that the online application (or more precisely, the multilingual server) shouldn’t bake messages, notifications and information at the time they are triggered. Instead, it has to marshal the information in a dynamic context (view or script) that gets executed, translated and presented, in the recipient’s preferred language, when it’s received.

But then it gets hairy. Groupware invitation workflows generally include e-mail or chat notification messages. In this context, there isn’t much the application developers can do to automatically present information in the recipient’s language. One could attempt using Multipurpose Internet Mail Extensions’ language type parameter in a multipart e-mail, but I’m not aware of ways of telling e-mail clients that they should choose among the available parts based on the user’s preferred language. Unfortunately, in the years of spam, e-mail clients aren’t very hackable (client-side code is simply blocked!). Plus, significantly different email parts means higher spam scores! If you can assume that the people involved in the invitation process know each other, using the sender’s preferred language is probably the safest approach when rendering outbound text.

Now here are the good news: if your team cares, the internationalization effort will be mostly an initial investment. It then becomes a bit like writing exception-safe code and it goes pretty fast. And then you reach a point in which translators can work almost on their own, at least to add support for new languages. Google has pushed this a bit further and taken a smart approach letting users translate the user interface for them (after taking care of the most popular languages, I believe).

I’m getting hungry now. Il piatto del giorno is a creamy asparagus risotto. Given the abundance of white wine, I’ll probably get that Italian translation going…


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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s

%d bloggers like this: