C#本地化

Question

可能重复:
C#本地化,真让我困惑

有人可以分享他们的大型C#应用程序本地化步骤吗？

我很确定在讨论中小型项目时,基于资源的基本策略可能会奏效.

但是,如果我们谈论大型产品,这种方法应该与自定义构建步骤和语言学家专门使用的一些第三方应用程序配对.

那么,请你建议/分享一些在你的应用程序中使用的全局本地化策略(足够大,显然:)

谢谢.

Answer 1

即使在大型企业应用程序中，基本的基于资源的策略也适用。这是内置且易于理解的解决方案，因此每个程序员都可以毫无问题地使用它。

唯一的问题是，您需要以某种方式将资源文件转换为翻译记忆库文件（即 tmx）并转换回来 - 以便翻译人员可以使用他们的标准工具。

所以你需要的实际上是一个本地化过程。对于大型应用程序有什么不同吗？好吧，如果您设置正确的流程，它就会扩展。现在进入流程。从我的角度来看，它应该是这样的：

1. 将资源文件复制到适当的文件夹结构中（本地化工程师不应直接使用应用程序代码库）。适当的文件夹结构应该类似于：
   [Project Name]
   。
   。
   [中性] [德语] [日语] [法语]
   。
   。
   （每个文件夹包含给定语言的可翻译资源，中性通常是英语）
   当然，您需要以某种方式将代码库转换为文件夹结构，但这可以自动化。

2. 处理您的可翻译资源并创建 transkits - 包含需要翻译的文件的 zip 档案（在本例中似乎是所有文件）。这些文件可能应该被转换，这样你就不会最终发送出 resx 文件。转换应用程序应该读取 resx 文件的内容，并将可翻译的字符串放入翻译者同意的格式文件中（可以只是 Excel，但我不会推荐此解决方案）。现在，我无法告诉您此类工具的名称，尽管我知道存在一些商业应用程序，因为我只使用过自定义工具。

3. 将 Transkit 发送给翻译人员（最有可能是翻译供应商）。

4. 收到翻译后的文件（transkit）后，您需要对其进行验证（此步骤至关重要）。您需要确保 transkit 完整（即没有丢失可翻译的字符串）并且技术上正确（即文件编码正确，通常为 UTF-8 或 UTF-16）。另外，至少看一下文件，看看是否有 1/2、3/4 等奇怪的字符，这通常意味着编码损坏。

5. 导入您的运输工具。这是 2 的相反步骤 - 您需要将翻译后的字符串放回到适当的文件中。

6. 将翻译后的文件复制回原始代码库并运行“本地化”构建。

7. 测试您的应用程序是否存在本地化问题（即重叠控件、剪切字符串、不正确的编码等 - 这通常意味着 i18n 未正确完成）。
8. 修复本地化/国际化（Localizability）缺陷。
9. 继续执行 1，直到 UI/字符串冻结期。这假设翻译人员将使用某种翻译记忆库，并且不会因重新翻译以前翻译的字符串而向您收费（或收费更少）。
10. 自动化所有可能的步骤并完成。

除此之外，您可能不会建立通用术语表并对翻译内容进行语言审查。