In today’s market, localization is a forward thinking design decision, or is it? If your application is going to be a full blown multi-lingual application, I’d say that localizing is a great idea, but if it’s it’s going to other countries where it’s understood that the application is geared towards a particular business language (typically English) why bother. Localization is one of those decisions that should be made upfront and thought through, because adding it after the fact is a real pain. I worked for a POS company where the application necessitated it be in multi languages. I worked at another company, an online Ad company company, where it wasn’t cut and dry. At the Ad company we had 3 applications, one for internal employees, one for publishers, and one for advertisers. At this Ad company, our internal users were split between a couple of countries and one of the countries had 2 languages. These internal users only spoke English, so the idea of localizing the application would be a waste of time. On the other hand our external applications were growing, and just because the root of business started in the US and Canada, that shouldn’t blind us from considering foreign countries. Opening you Ad network to all languages would increase you share of the market and localization is an easy way to accomplish this.
A great article on using localization in ASP.NET can be found here, Extending the ASP.NET 2.0 Resource-Provider Model. Even though this article focuses on ASP.NET, much of it can be utilized by WinForms. In a lot of MS examples out there they talk about storing image paths, image files, etc. but in my experience I’ve found that the most important resource to store is just text. I define different text types to be in these categories: word or word group, full sentence or paragraph, and replacement text. A word or word group is text that always stands alone. Replacement text is a category I put dynamic typed items, for example “Item number {0} has not been found.” which would be used with the string.Format method. Replacement text is the trickiest, because in almost all languages, order at which you arrange the noun/verbs is different and not literally translatable from English. Below is a list of considerations to think about when internationalizing an application.
- Width of labels, buttons, columns, or any area that has some perceivable width constraint. A lot of time the English words take much less space than their translated counterpart. This can lead to bizarre and undesirable UI shifting or hidden overflow.
- Stay away from using slangs or acronyms. Slangs are tough because there typically isn’t a correct translation for it. Acronyms should only be used if they are and industry standard, for example mass in kg instead of kilogram is standard in any language. On the other hand, something like ROI (return on investment) should most likely be spelled out.
- When using replacement text, the translator should be given some context in which the sentence or phrase is used in so that word ordering can be correct especial when phrase contains words that have double meaning. For example, a replacement text with double meaning could be “Server {0} is not found.”, which a translator can make the easy mistake of assuming this is a computer server or a restaurant server. In English the word is interchangeable but not in other languages.
- Considering limiting yourself to fewer dialects than more. There’s little use in, for instance, translating all the various dialects of French. Unless there is an overwhelming need to, like zh-cn and zh-hk, don’t.
No comments:
Post a Comment