In .NET Framework, localized strings are located in an XML file (or multiple files). Those files are part of the project and are committed to the source control as any other source code file. Usually, Visual Studio is used to display those files as a table and edit the localized strings.
I work in a small team on a product which should have a multilingual interface.
-
As a developer, I draft the localized strings in both languages, given that the translation may be inexact,
-
Another person from the team (a non-developer) reviews the content in both languages and corrects it if needed.
The current issue is that the non-developer person would not use neither source control, nor an IDE, since it would be too cumbersome and difficult (version control is difficult for non-developers) for this person.
An alternative solution would be for me to export the localized strings as an Excel file, wait for this person to review the Excel, then to re-import the modified strings. The caveat here is that I may be creating other strings, renaming existing ones, etc., making it difficult to diff the local version with the reviewed one.
What to do?
How does it happen in other teams?
5
Localization is a lot more complex than just editing XML in Visual Studio, specifically:
- Although what KateGregory says is correct, Visual Studio is expensive and purchasing copies for localizers is often prohibitive.
- Unless the localizer is also a developer, they cannot see the strings in the product and test that the strings are displayed correctly (non-European characters like Asian languages or right-to-left text like Arabic), fit/wrap correctly (German’s long words) and do not cause injection attacks (such as French’s use of apostrophes)
- Although version control is not a complex tool, giving access to source control to remote or contracted localizers is a risk. They could copy source code without the team’s knowledge or commit breaking changes (either intentionally or unintentionally).
- It also assumes the only thing you are localizing is RESX files. Some products may have localized data like report names.
Therefore, the best thing to do is create a simple website that exposes the various strings, hiding the underlying syntax. The build process includes strings provided by the localizers after a quick sanity check and the build shared with the localizers for testing. The website can use logons for different localizers (and track and bill work if you want to go that far). This is more work but a better solution in the long term.
1
Editing XML sucks. Visual Studio has a view you can use to edit resources:
I think that check-out-on-edit combined with a minute of demonstrating the “pending changes” window should enable your non-developer to use as much source control as they need to.
I would look into finding an XML editor* for the non-developer to use.
You’ll then need to provide versioned extracts to the non-developer for review.
Once they’re done with the review, you can check the file back in.
When you have made changes, you’ll simply need to diff the XML files prior to check-in and send the updated-by-you sections to the non-dev for review. Your updates are why why you need to keep the the review files versioned.
Trying to use Excel will make things exceedingly difficult since the diff tools for excel leave a lot to be desired. You also run the risk of additional comments creeping into the extra cells within the spreadsheet. Those comments would require additional handling upon your part in order to merge them back in.
In a previous life, we used a fairly similar process for a number of translations by external organizations. Our files were essentially text files with a similar but different form than XML. And we had tons of changes going on while files were out for review, so I appreciate the fun of your situation.
* I’ve used xml notepad and it’s tolerable, I would suspect there are better ones out there
One option is to create a helper application where the translator can see the list of strings in one pane and enter the language specific in another. This way the data is stored back to the XML and then you can have that application export the file.
If you process the keys into a database and store each languages there, it would allow for changes to be integrated and the translator to see what needs updated. Then you can just export to the language specific XML file which you put back into version control or the translator could.
We use a similar method to this with our Rails code, we never edit or even provide the language specific files, they are all maintained and then exported by the external application our translation team uses. Sorry I don’t know if their software is custom or off the shelf, but it shouldn’t be that hard to put something simple together.
How do you know you got all the strings and that they’re formatted correctly in the app? How do you know that numbers, currency, timezone and other locale info is formatted correctly? That everything is loaded and multibyte serialization works properly?
No. Localization is a feature like any other. Check it in. Make a build. Let the tester get the build and verify the feature is done properly like any other. When you make a new build, you get to do regression testing on the localization – just like any other feature.
3