如何管理非开发人员检查本地化字符串的任务？

在.NET Framework中，本地化的字符串位于XML文件（或多个文件）中。这些文件是项目的一部分，并且像任何其他源代码文件一样被提交到源代码管理。通常，Visual Studio用于将这些文件显示为表格并编辑本地化的字符串。

我在一个小组中研究应该具有多语言界面的产品。

1. 作为开发人员，鉴于翻译可能不准确，我用两种语言起草了本地化的字符串，

2. 团队中的另一个人（非开发人员）以两种语言查看内容，并在需要时进行更正。

当前的问题是，非开发人员既不会使用源代码控制，也不会使用IDE，因为这对于该人员来说既麻烦又困难（对于非开发人员来说版本控制很困难）。

另一种解决方案是我将本地化字符串导出为Excel文件，等待此人检查Excel，然后重新导入修改后的字符串。需要说明的是，我可能正在创建其他字符串，重命名现有的字符串等，这使得很难将本地版本与经过审核的字符串进行区分。

该怎么办？

在其他团队中如何发生？

本地化要比仅在Visual Studio中编辑XML复杂得多，尤其是：

1. 尽管KateGregory的 说法是正确的，但Visual Studio昂贵，并且为本地化人员购买副本通常是禁止的。
2. 除非本地化人员也是开发人员，否则他们将看不到产品中的字符串，也无法测试字符串是否正确显示（非欧洲字符（如亚洲语言）或从右至左文本，如阿拉伯语），正确安装/换行（德语字词），并且不会引起注入式攻击（例如法语对撇号的使用）
3. 尽管版本控制不是一个复杂的工具，但是将源代码控制的访问权限授予远程或约定的本地化程序是一种风险。他们可以在团队不知情的情况下复制源代码，或者（有意或无意地）做出重大更改。
4. 它还假定您要本地化的唯一内容是RESX文件。某些产品可能具有本地化的数据，例如报告名称。

因此，最好的办法是创建一个简单的网站，该网站公开各种字符串，并隐藏底层语法。构建过程包括本地化人员在进行快速健全性检查后提供的字符串，并与本地化人员共享该构建以进行测试。该网站可以将登录信息用于不同的本地化人员（如果您想走那么远的话，还可以跟踪和结算工作）。从长远来看，这是更多的工作，但是更好的解决方案。

编辑XML很烂。Visual Studio具有可用于编辑资源的视图：

我认为编辑后检出结合一分钟的演示“待更改”窗口将使您的非开发人员可以使用所需的尽可能多的源代码控制。

我将寻找为非开发人员使用的XML编辑器*。

然后，您需要向非开发人员提供版本摘录以供审核。

审核完成后，您可以重新签入文件。

进行更改后，只需在签入之前对XML文件进行比较，然后将按您更新的部分发送给非开发人员进行检查。您的更新是为什么您需要保持审阅文件版本的原因。

尝试使用Excel将使事情变得极其困难，因为excel的diff工具还有很多不足之处。您还冒着额外注释爬入电子表格中额外单元格的风险。这些评论将需要您进行其他处理才能将其合并回去。

在以前的生活中，我们对外部组织的许多翻译使用了非常相似的过程。我们的文件本质上是文本文件，其格式与XML相似，但形式不同。在文件审阅期间，我们进行了大量更改，因此，我感谢您的情况带来的乐趣。

一种选择是创建一个帮助程序，在该程序中，翻译人员可以在一个窗格中看到字符串列表，而在另一窗格中输入特定的语言。这样，数据就被存储回XML，然后您可以让该应用程序导出文件。

如果您将密钥处理到数据库中并在其中存储每种语言，则可以集成更改，翻译人员可以查看需要更新的内容。然后，您可以仅导出到特定语言的XML文件，然后将其放回版本控制中，或者翻译器可以。

我们在Rails代码中使用与此类似的方法，我们从不编辑甚至不提供特定于语言的文件，这些文件均由翻译团队使用的外部应用程序维护和导出。抱歉，我不知道他们的软件是定制的还是现成的，但将一些简单的东西组合在一起并不难。

您怎么知道您拥有所有字符串，并且它们在应用程序中的格式正确？您如何知道数字，货币，时区和其他语言环境信息的格式正确？一切都已加载并且多字节序列化工作正常吗？

否。本地化是其他功能。签入。进行构建。让测试人员获取构建并验证功能是否像其他任何功能一样正确完成。进行新构建时，您需要像本地其他功能一样对本地化进行回归测试。