In our asp.net website we support multiple languages.
The current translation workflow goes as followed:
- Site gets built with “developer language”
- Translations are kept in a database and use a custom Provider
- At a certain point in devcycle translators get an extract (excel compatible xml) of the DB to work on
- A filled in file is received by the dev team and converted (automatically) to sql script
Advantages:
- Translators don’t have to work with translator-unfriendly tools
- They have an easy overview of all the literals
- The dev language is easily distinguishable because of a leading ‘_’ in order to spot untranslated literals
- Sql scripts are redeployable and versionable
Disadvantages:
- Translators have no view on how their translations will look in app
- Translations often times screw over layout because of length problems (eg: Russian tends to be way more verbose then English)
- Conveying context is hard
- Translations added after the extract file are hard to track and lead to mistakes
- Distributed translators + excel(xml) make for timing- and merge conflicts
I’m trying to find a better way to communicate with translators.
An existing tool would be preferred over something implemented in house.
Giving the translators a working view of their work has a high priority.
Managing versions of the translations files should improve.
We had hoped that the excel xml’s would be versionable, but comparing and merging is near impossible.
Giving translators Visual Studio to work in the resx files is not an option.
Have you considered something like the link below? You could integrate that into a staging version of your app for the translators, then they can see the changes in action.
Westwind.Globalization Data Driven Resource Provider for ASP.NET