Resource files seem great for localization of labels and messages, but are they perfect?
For example:
- Is there a better solution if there is a huge amount of resources? Like 100,000 strings in a .resx file? (Theoretically, I do not actually have this problem)
- Is this a good method for storing the other types of data, such as images, icons, audio files, regular files, etc.?
- Is it a best practice to store your .resx files in a stand-alone project for easier updates/compiling?
- Are there any other issues that you have run into when using .resx files?
I have had two problems with resource files, both about performance of the translators (people), rather than the speed of string lookup.
So they just used Excel to edit the translations. Therefore, we might as well have stored the translated strings as a CVS file, so avoiding having to copy the translated strings into the resource files.
Once again if the translated strings were stored as a CSV file, we could have cached them in the ASP.NET cache. Then any changes to the translations would show up on the next page load.
So we could have used a custom implementation of the resource provider and keep to the standard ASP.NET resource lookup system. Or just ignore the standard resource lookup system if it does not help in your case – it depends on how your pages are written.
You may find at some point that you wish to be able to override strings for a single customer, if so you will need a multi-stage lookup system. Otherwise, you have to merge the customer’s custom strings with the translated string each time you ship a new version of the system.
For point#4.
I have been using .resx files for all strings on our site that must be localized into many languages and haven't had any major issues with them.
The one thing that you need to think about is if you want this text to be searchable. For some of the sites I work on there are some localized resources that need to be searchable so I must keep them in the database. However, when I have the choice I prefer the .resx file for similar reasons mentioned above.