如果您针对多种语言进行本地化并拥有大量内容，那么如何保持同步更改？例如，列出各种鸟类（其中200只）的鸟类应用程序。如果您已选择本地化五种语言，则意味着您需要1000个本地化文件。如果任何鸟类条目发生变化，不仅需要进行大量初始翻译，而且需要非常耗时。
是否有更好的方法来同步所有内容并进行初始翻译？
答案 0 :(得分：2)
这听起来更像是流程管理问题，而不是工具问题。问题的核心是字符串文件是以语言为中心的，但您管理的翻译是以数据为中心的。工具可以帮助维护数据完整性，但最终它将通过流程进行修复。
您正在寻找的过程要么是保持同步的机制，要么是将其他四个标记为不同步的方法。最好的过程将易于实现，易于理解它的工作原理，显然注意到过时的条目并适合自动检查。获得所有四项 - 简单，简单，明显，自动化 - 并非易事。
您和您的团队可以通过多种方式解决此问题。
一种是不允许不改变所有五个字符串文件的提交。 commit-hook脚本可以在存储库中强制执行此操作。当其他翻译没有变化时，例如在用一种语言修复拼写或语法时，这就会崩溃。
另一种方法是在更改一个翻译时提交四个后续错误，并确保及时完成。在第一组四个后续错误关闭之前对一个条目进行两次或更多次更改时，这会分崩离析。翻译人员会对他们必须分类的额外错误感到恼火，或者更糟糕的是，他们将无序地解决错误，并最终将翻译设置为第一个错误版本的条目，而不是最新版本。 / p>
第三种是仅对一种语言进行更改。完成下一个版本的代码后，对最后一个版本运行差异（例如，svn diff -r <last release>），并在切换新版本之前将该输出用作翻译日，以便在翻译日完成。就个人而言，我不认为这种方法使过时的翻译足够明显。在不更新翻译的情况下剪切版本太容易了，根本没有注意到它们被遗忘了。
第四个更明显的选择是，只要对一个版本进行更改，就将其他四个版本的翻译加上“REDO：”。在删除版本之前，请搜索并清除REDO条目。这种方法有两个风险：REDO标签在提交时可能会被遗忘，或者可能会在字符串文件中使用令人尴尬的REDO标签来删除。
对于所有这些，预先提交的同行评审应该检查所选择的过程是否被遵循。他们说：“许多眼睛都会验证，”或者说。
我确信还有其他方法，这里没有明确的“正确答案”。最好通过团队讨论来确定团队的最佳方法。
答案 1 :(得分：1)
你不需要只有5个文件吗？你使用什么技术？
答案 2 :(得分：1)
像gmagana所说，你应该只需要5个文件（每种语言一个Localizeable.strings）。
请参阅Apple指南“International Programming Topics”，特别是“字符串文件”一节。