I would like to get some of your ideas about
- resource name / categorizing
- place of resources
Let me just give you the scope of the application:
- 3 or more supported languages
- 3 MVC websites [with a lot of shared resources, and also some unique resources]
- 1 shared MVC extensions library
- 1 core business library, which has shared functionality, and business objects [also contains resources]
- 3 business libraries that have specific business logic for the three websites [also with resources]
- 1 SQL 2008 database shared among all websites, sends sometimes localized emails.
I would like for it to be easily maintainable (so also easily exported/imported for translation), not to be duplicate (since we have common resources), and understandable for everybody that comes in contact with the code
Place of the resources:
- should I create one assembly containing all the translations? And create a reference to that assembly in my projects (even if possible adding it to SQL server)?
- or should I use source control to keep all the resource files in sync?
- some other ideas?
resource name / categorizing:
So we have localized emails, text on buttons (command like texts), labels, error messages, information messages etc etc.
How do you categorize these items into resources files, do you just dump them all in one file? Or do you categorize them into a strings , and an emails resource files, which categorization do you use?
We have a similar system setup; What we use is a database just for the text. Then we have a common assembly that provides methods to get localized strings along with a custom expression provider so we can use standard <%$ Resources:zzzz %> syntax inside aspx/ascx files.
Our database is set up so we can provide a default text for a token, along with a localized version and an application (eg, simplified our “Translation” table has the following columns: (Token, Locale, Application, NativeText) ). This way we can provide overrides for specific applications if we need to.
This has the advantage that we can also provide a Translation Editor (we don’t currently, but it is a possible future option), and also exporting/importing translations isn’t too bad (not claiming that it is without fault – I think translation is going to be a hard topic no matter what).
We do still use standard resource files, but only for strings that are truly application specific and also unlikely to change; I’d advise against this. It just means we can’t create the list of strings to translate as easily.