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.

  • How related are the web applications? If there are no shared resources, then I would lean towards a reusable API with individual localizations rather than a shared web-app. Also, you need to be aware that localization involves more than simply translating text.
    – Telastyn
    Commented May 2, 2012 at 13:53
  • The web applications have no communication between them and not all of them are on the same same Web Server. A common API is a great idea! thanks for that. I agree with you that multi language support involves not only text translations but all sorts of resources
    – tivo
    Commented May 2, 2012 at 14:28
  • not just resources. Currencies change, the size of labels (and thus layout) often changes, different colors have different symbolism in different cultures...
    – Telastyn
    Commented May 2, 2012 at 14:30
  • thanks for the clarification, I found a link that explains in general the process: msdn.microsoft.com/en-us/library/h6270d0z(v=vs.100).aspx , my question is still on the architecture
    – tivo
    Commented May 2, 2012 at 15:16
  • You could reduce the performance impact of a centralized service by caching the results. The first hit for a given key would hit up the service, all subsequent hits would be handled locally. If you're worried about local storage, limit the size of the cache and expire "old" strings. Commented May 3, 2012 at 23:57

1 Answer 1


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

  • need to export for a specific technology (.resx, .po, .lang, xliff...)?
  • need random access from a server app via a (web)service?
  • need a unitary access to do translation?

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.