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.
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.