Question

Possible Duplicate:
C# localization , really confusing me

Could someone please share their localization steps for huge C# applications?

I’m pretty sure that the basic resource-based strategy might work when talking about small to medium projects.

However, if we speak about large products, this approach should be paired up with custom build steps and some 3rd party applications used specifically by linguists.

So, could you please advise / share some global localization strategy that is used in your applications (big enough, obviously 🙂

Thank you.

Answer 1

Basic resource-based strategy works even in large enterprise applications. This is built-in and easily understandable solution, therefore each and every programmer could use it without a problem.

The only problem is, you need to somehow transform your resource files into Translation Memory files (i.e. tmx) and back – so that translators could use their standard tools.

So what you need is actually a Localization process. Is it different for large applications? Well, if you set-up correct process it would scale. Now onto process. From my point of view it should look like this:

1. Copy resource files into appropriate folder structure (Localization Engineers should not work directly with application code base). The appropriate folder structure should be somehow similar to:
   [Project Name]
   .
   .
   [neutral] [German] [Japanese] [French]
   .
   .
   (each folder contains translatable resources in given language, neutral is usually English)
   Of course you would need to transform your code base into folder structure somehow, but this could be automated.

2. Process your translatable resources and create transkits – zip archives containing files that need to be translated (in this case it seems like all of them). The files should be probably transformed, so you won’t end-up sending out resx files. The transformation application should read contents of resx files and put translatable strings into some file of format agreed with translators (it could be simply Excel but I won’t recommend this solution). Now, I can’t give you the names of such tools, although I know that some commercial applications exist, for I have only worked with custom ones.

3. Send transkits to the translators (most likely translation vendors).

4. Upon receiving translated files (transkit) back, you need to verify it (this step is crucial). You need to ensure that transkit is complete (i.e. no translatable strings are missing) and technically correct (i.e. file encoding is correct, usually UTF-8 or UTF-16). Also it is at least good to take a glance at the file to see if there are no strange characters like 1/2, 3/4 or something – this usually mean broken encoding.

5. Import your transkit. This is the reverse step of 2 – you need to put translated strings back to appropriate files.

6. Copy translated files back to the original code base and run “Localization” build.

7. Test your application for Localization problems (i.e. overlapping controls, clipping strings, incorrect encoding, etc. – this usually mean that i18n is not done right).
8. Fix Localization/Internationalization (Localizability) defects.
9. Proceed to 1 until UI/String freeze period. This assumes that translators would use Translation Memory of some kind and won’t charge (or charge less) you for re-translating previously translated strings.
10. Automate all possible steps and your done.

Apart from that you might won’t to establish your common glossary of terms and do linguistic review on translated content.