I have about 8 web applications (all of them ASP.NET based), and I want to implement multiple language support for all of them and have an architecture that I can leverage on new web applications down the road. I would also like to try to centralize the admin piece (where all the text translations and other language specific resources reside), do you know of any tool or architectural pattern that might be useful in this case?
The only robust solution I can think of is to have a web application that manages the language support resources and all the other web applications connect to this centralized app/service, but I'm afraid that this solution will have a performance impact on all applications if not implemented the right way.
I would greatly appreciate any suggestions.
Best Answer
You can start by defining many thing.
Define how to identify the culture in your API (ISO-639, LS-2012, ...)
This choice will change the way you store resources and access them. Also, decide how to fallback through regions and neutral cultures. Some languages have a very specific way to fallback between different cultures, some books would give you a great insight.
As you're going ASP.NET to choice is simple.
Define how to store each data type (strings, pictures, currencies...)
You will have to consider different access ways. Do you want to stay mobile and use simple files? Or can you afford keeping a database in a single place to handle everything?
Centralizing can become a problem is clients and consultants have to deal with translation. Using a text-file-based solution goes into source control revision easily, providing the good portable tool and libraries is great but isn't easy for non-techies.
Define access formats for all kinds of application
In all cases, being able to export translations in a well-known format will give you the ability to use translation services. You will then need to be able to merge new translations with your existing ones.
Define how to deal with currencies
This is more a code concern which your API will not have to deal with entirely. But setting-up rules for all developers is a good thing.
Finally, make sure the API you will create can be ported to as many languages/technologies as needed. Using standard formats will be a essential choice because of the existing libraries (gettext, xliff) and tools.
Don't forget to handle plural forms (no items, one item, x items) and translation remarks (contextual information for each resource) which will solve a lot of problems.
Write everything you decided in a shared document to make sure everyone understands the why and how. If you're writing an API, documentation is... important.