Localization Strategy

1
votes

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,

2
localizationinternationalization
Why wouldn't you just have one file per language? For B, I don't understand why you would have two files per language... – NinjaCat
Because to the client, it will be easier for them to read the xml and make any changes. – Brian Liang
Are you providing the translated resources? Now that I re-read yoru question it seems that the customer or the user is providing their own translation. Am I understanding that correctly? – NinjaCat
i think you are joking about the being easier to read your XML file. Please try to use a standardized file format for this instead of reinventing the wheel - try to use gettext format and if you really like XML go for XLIFF. For both of them there are plenty of tools already made. – sorin

2 Answers

0
votes

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.

0
votes

In general, you should consider existing tools, rather than start from the scratch.

In .net we are using Data Driven ASP.NET Localization Resource Provider and Editor Created by rick strahl