简体   繁体   中英

Handling multiple languages across multiple applications and shared libraries (.net)

We are developing products that will be used in the following way:

  • Various shared libraries which may be used by multiple products. I anticipate these libraries will mostly need to access string resources that contain error messages/exceptions.
  • Various end-user based applications, designed to run as standalone apps on a PC. They will be required to support multiple languages upon deployment/installation.
  • Various web-sites which may be required to support multiple languages either at deployment time or possibly at runtime (ie minimal or zero downtime). Potentially the site might need to support multiple languages at the same time if being accessed globally.
  • We may be required to allow customers access to our language files for editing themselves. We would not wish to allow them access to our source code (other than the resource files/dlls) in order to achieve this.
  • We might need to incorporate a facility to log exceptions in our native language (English in this case) and display them in the translated language. This will help us debug our customers solutions in the field.

I am already aware of products like RCWinTrans and handling multiple languages in VC++/MFC applications. However, the requirements we are faced with here are more extensive and thus require us to make a few up front decisions that could be difficult to change long term, so ideally we want to make the best choice now.

Based on my own knowledge, I have a few questions although I may be missing some tricks with .net that will be happily received. Here are my questions:

  1. What would be best? Put all our resources in a seperate DLL per VS solution OR put the resources in each VS project. The way I see it per solution is easier to manage, modify, and allow customer access. The per project solution seems cleaner though and makes the individual projects more portable. This method would apply to our shared library based solutions as well as our end-application based solutions.
  2. Does the solution above still stand with web sites? Is there a better way? Does this way require downtime?
  3. Is it possible to have two seperate resource files loaded at once ie if we want to log the exceptions in English but supply them back up the food chain (as a message in an exception) in the translated language? Are there any tricks we can use to automate this like AOP?

Thanks in Advance,

Roger

Have you considered using an Inversion of Control container like StructureMap or Unity ? That may allow you to keep the default resources together with the project (which IMHO makes most sense), while still allowing a customer to locally override resources as necessary.

As an example, assume you have the following interface:

public interface IResourceSupplier
{
    // Returns the localized text for a given identifier.
    string Localized(string identifier);

    // Returns the invariant (English) text for a given identifier.
    string Invariant(string identifier);
}

Using IOC, you could create a centralized resource supplier for the solution which would check for user-supplied overrides. If no user override is provided, then you could query each of the project-specific resource suppliers (detected at application startup) until you locate one which returns the desired resource.

Obviously, depending on your needs you may need to tweak for performance, for example by caching frequently used resources. Using IOC does give the advantage that as long as the interface does not change, plugging in an alternate implementation can be a relatively trivial task.

Does this help?

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM