在具有多个功能分支的解决方案中管理翻译的更好方法是什么?

时间:2016-08-09 19:52:52

标签: tfs merge

情况

  • 我们有多个功能分支,一个主分支;
  • 一个特定项目有多个XML文件,不同语言的键值对;
  • 只有一个人在做翻译,而不是程序员,而是分析师;
  • 我们使用功能分支来分隔测试的功能和范围;不同的QA负责针对不同的用户故事在不同分支上进行测试。
  • 当用户故事完成时,我们合并功能分支,并同步到其他子分支
  • 那些语言XML文件很大,比如每个大约有几百个键值对。

挑战

当多个功能分支需要翻译,并且翻译更改在同一个文件中完成时会出现挑战,比如日语;

  1. QA偶尔会在另一个分支中修复一个翻译错误;
  2. 分析师对哪个分支工作感到困惑;
  3. 合并时有很高的机会,一个版本会覆盖另一个版本;因为当我们从分支合并时,TFS中的默认逻辑会使用较新的版本来覆盖它。大部分时间它工作正常,但在某些情况下失败,这增加了合并的复杂性。
  4. 当然,这些挑战是可以控制的。

    但理想情况下,我认为这些静态文件应该属于一个地方而不是功能分支,因此所有功能分支都共享相同的翻译包。

    我可以使用内部nuget源来托管语言文件,但每次我们进行小的翻译更改时,它都会增加工作量。

    或者我可以设置TFS来使用相对路径,但是我需要在构建服务器中更新构建定义并确保本地构建可以获取正确的文件。

    还有其他推荐吗? 谢谢

1 个答案:

答案 0 :(得分:1)

如果你有任何共享内部库,那么创建NuGet包应该是一个好方法,你也可以创建一个只包含该库的vs解决方案。

对于XAML构建,添加一个post build命令来创建nuget包,或者扩展你的tfs构建模板来执行它(那里已经有很多模板已经这样做了。)

对于VNext构建,有一个名为" NuGet Installer"的新VSTS任务。这允许您签入NuGet.config文件并指定不同的包源。在运行MSBuild之前运行此任务。更多详情请参阅:How to get TFS2015 Build (Build.vnext) and NuGet package restore to use custom package sources

此外,我认为如果您的产品或应用尚未发布给用户,则翻译的更新更改可能不会那么频繁。毕竟,只是一些翻译和语言包。您可以在迭代期间更新一次或两次。