Working with external translators in .NET

Question

I am working on a .NET project (happens to be an MVC website) that is being deployed in 5 languages. We have several hundred text strings in various .resx files, which is working great.

However, the process for adding or changing strings is slow, as the translation is being done by another department and we don't have a great system in place for tracking or coordinating changes. They apparently use WorldServer, which has some resources on file formats and import/export, but not much on workflow for my side of the equation.

WorldServer or no, what is the best way to coordinate ongoing translation efforts and integrate the results with existing translations in .NET?

• Patrick: There is dev.windows.com/en-us/develop/multilingual-app-toolkit by Microsoft. I haven't used it, but it has XLIFF on it's feature list which is supported by WorldServer.
• Doc Brown: This sounds more like a legal problem of putting time constraints into the contract you have with those other departments (and maybe a penalty if those constraints are violated), not a software engineering problem.
• brichins: @DocBrown it's not so much about timing and enforcement as it is the level of technical effort (on both sides) to identify and sync changes. It'd be nice to just dump everything in their lap and say "you sort it out or your budget gets dinged", but that's not going to accomplish anything. If it were an external company doing the work, then yes the time constraints would be vital.

Answer 1

In the interest of full disclosure, I'm the author of a commercial (".resx") localization tool for Visual Studio developers. I won't be mentioning anything about my product here though so as not to violate the site policy.

The program is a Visual Studio add-in that developers use to extract all strings from their ".resx" files into a single, proprietary file for shipping to their translator. Their translator can then download a free program from my site (no cost to them whatsoever), translate the strings and send the file back. The same add-in that created the file in the first place is then used to import those strings back into the programmer's solution. To this end, the application does many things that will presumably solve your "workflow" issues. It was designed for this from the ground up.

For instance, if a programmer changes a string in their solution, then their existing translations will require updating of course, so the program will flag them for review. This means that the next time they ship their strings to their translator, the translations will be highlighted in red, meaning they need to be reviewed and updated. The program also has many other bells and whistles, including a lot of error and consistency checking. For example, if a programmer changes a string in their solution while it's out being translated, it'll be brought to their attention when the strings are later returned.

• brichins: Sounds about right for what I'm doing. I'm disappointed in the proprietary format approach, but still interested to know what your program is. Can you drop a link in a comment please?
• Larry: @brichins: It's proprietary for a number of valid reasons but the details are too long to get into here. Here's the link though: hexadigm.com. The support email address is posted on the "About Us" page.
• brichins: Follow-up: I looked at this tool and it did seem pretty useful, for both devs and translators. I moved to another project before I had time to do anything with it, but I passed the details on to the manager and asked them to look into it - seemed interested but I'm not sure what happened.