Localization Strategy

Question

We're currently debating two strategies of localization:

A. Have an XML file for the structure of the business objects with a Localized key to a separate CSV file for the translation.

for eg. /Resources/Schema.xml

in a separate CSV file: we have all key/value pairs for the translations:

/Resources/Localized.txt

Model_Title, Title, Title (in French), ...

This way, when the structure changes, we just change XML once while the LocalizedKey's are in place.

B. Have separate XML files for each language based on Culture.

eg. have two files: /Resources/en-US/US-Localized.xml /Resources/fr-AU/AU-Localized.xml

This way, they will have same schema but separate files. Therefore the user would have to make sure that the schemas are the same as they would need to change it twice as opposed to Option #1 where they can just change it once.

However, the readability here is much better since the user would not have to track the key the make the changes.

What are your thoughts/ideas on the strategies I suggested?

Thanks,

Answer 1

It is not clear about the environment -- web? desktop? internal enterprise integrated something-or-other? Is there any particular reason you aren't using whatever i18n framework your tool chain supports (gettext, .NET resource files...)?

In general I'd say you want to separate out resources by culture (but to be honsest, fr_AU should be rare) to have better maintainability and do not have to load the entire file for all per-culture-versions in many situations. This is especially true if your number of supported languages/cultures goes into the dozens or more.

However, it would be important to accommodate XML schema changes. The XML could be auto-generated, from simpler structures (key-value, either in a database or files) and validated via a common schema.

This is whether (as commenters noted) you are providing localized products or customers can create their own localizations.