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?
How to manage the task of reviewing localized strings by a non-developer?
version control;team;collaboration
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.