Localization\Globalization Considerations and Tips

by mosessaur| 18 September 2008| 4 Comments

I've been worked with localization and globalization for a while now. During that period I faced issues and learned many things about the subject. Here I am going to share some of my own ideas and tips to avoid falling in certain issues. It worth to mention that I am talking from GUI point of view and not Application Data point of view.

Consider using Resource Files ".resx" or Database:

Well this is a matter of your needs. But I highly recommends to always consider ASP.NET Resource Provider. Then it doesn't matter to work with ".resx" of Database. By default ASP.NET has a provider for XML based resources which is resource files ".resx" But also you can get a great Database Resource Provider for free from here.

Actually to choose between both you should think about that all your UI localizable terms should be stored in one central location. I mean, do not put some in resource file and some other in Database. Like you define labels on resource files and grid headers in database!! or maybe error or information messages. Just build it right from the beginning and define one central location.

Local Resources or Global Resources:

One good question is When I shall use global resource or local resources? To answer this question let me show some issues you might fall into when using local resources:

  • If you have 100 user control than means you'll create 100 local resource files * number of cultures you wish to support.
  • High possibility for duplication. For example, Grid headers! You might have these headers defined in several grids in different pages or controls. So why do you need to resource keys in different local resource files?! Why not have them in one Global Resource and share it among all pages and controls? However according to my experience, and having GridView as an example, localized headers can only be defined in Global resources. However this is not the case with ListView when you have full customization.

So I prefer to go with global resources most of the time. But that doesn't mean to totally abandon local resources. I can use them only when appropriate. It is just having less resources will save you time in many things including translation process.

Know your Terms:

Well, be able to recognize what is your application about and what are the comment terms that will be used then you are going to save yourself duplications. A common issue is that we always duplicate terms and that results in different translation for the same term in the same location. This can be related to the point I talked about above regarding local resources. Having several keys defining same term.

If you are able to define or specify your common terms then you'll end up translating one single value that will be commonly used across your application. So again, this will results in having your common terms in global resource files.

Organize your resources:

When you start working with global resources, I recommend that you build the resources structure before you just start ahead collecting keys and values.

For example you tables/grids' headers, you can make a special resource file to just store those headers. You might think that some of the headers might be common with some other things such labels of a form or something similar. Well yes but still they are used in some different way. So better to keep them isolated.

You can also make special resource files for messages. Messages such as friendly system error messages or information messages. Or it might be validators' messages. Just like that, organize your resources so that you have better control over them.

Floating elements and RTL languages:

If your application supports RTL languages such as Arabic or Hebrew and you are depending on floating DOM elements, then you might consider built special style sheet for RTL languages that is loaded dynamically based on selected culture.

Floating elements defines if the element will float right or left. And this will not auto switch when you change the direction from LTR to RTL. At this point Direction has no effect, and you need to switch the floating direction itself.

Conclusion:

Localization\Globalization isn't always hard. If your application was already built with globalization in mind; most of the process will move smoothly and effectively.

kick it on DotNetKicks.com

Comments (4) -

Janko
Janko Serbia on 9/18/2008 9:00 AM I agree that localization shouldn't be hard. You made some good points here.
|
mosessaur
mosessaur Egypt on 9/18/2008 9:33 AM @Janko Yes, it is not hard, but really, it depends on the solution itself how it was built. In most cases, ASP.NET localization and globalization solution fits all solutions. Except those who are already planned to use different approach.
|
Scott
Scott Australia on 11/10/2008 9:09 AM I strongly recommend checking out the west wind db resource provider(www.west-wind.com/.../).

I manage an open source project ( http://sharpforge.org/p/SharpForge.aspx ) and initially used the resx files. Here are the issues I had
o) I wanted to access those resources strongly typed from the BLL layer. It simply wasn't possible.
o) The resx files are also very difficult to maintain, adding/removing/changing resources keys can create all sorts of problems.
o) Finally I was having huge problems not saving the files using editors with the correct character map/encoding which would strip all of the translated text. The process of getting the resources from the translater into the code repository often resulted in munging the text.

I was able to implement the west wind db provider as part of the application. It comes with an editor that you can give the translators access to. Their translation goes directly into the app with no double handling and is available as soon as the application is restarted. It also has the capability to create strongly typed objects to access the provider from any layer.

Once this was installed I simply created a translation project on getafreelancer(http://www.getafreelancer.com/projects/246088.html) and was able to get 25 translations done for my application within about 2 weeks. All for about $US50 each.

|
club penguin
club penguin United States on 5/21/2009 4:50 AM I was having huge problems not saving the files using editors with the correct character map/encoding which would strip all of the translated text. The process of getting the resources from the translater into the code repository often resulted in munging the text.
|

Pingbacks and trackbacks (1)+

Comments are closed