C＃本地化

Question

可能重复：
C# localization , really confusing me

可能有人请分享自己的定位步骤庞大C#应用程序？

我很确定在谈论中小型项目时，基本的基于资源的策略可能会起作用。但是，如果我们谈论大型产品，应该将这种方法与定制构建步骤以及语言专家特别使用的一些第三方应用程序配对使用。

所以，请你指教/股是在应用程序中使用的一些全球本土化策略（够大，很明显:)

谢谢。

Answer 1

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

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

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

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

2. 处理您的可翻译资源并创建transkits - 包含需要翻译的文件的zip存档（在这种情况下，它好像都是这些文件）。这些文件应该可能被转换，所以你不会最终发送resx文件。转换应用程序应读取resx文件的内容，并将可转换的字符串转换为与翻译人员同意的格式文件（可能只是Excel，但我不会推荐此解决方案）。现在，我不能告诉你这些工具的名称，但我知道有一些商业应用程序存在，因为我只使用了自定义的应用程序。

3. 将transkits发送给翻译人员（很可能是翻译供应商）。

4. 在收到翻译文件（transkit）后，您需要验证它（这一步至关重要）。你需要确保transkit是完整的（即没有可转换字符串丢失）和技术上正确（即文件编码是正确的，通常是UTF-8或UTF-16）。此外，至少看一眼文件以查看是否没有奇怪的字符，如1/2，3/4或其他 - 这通常意味着编码不对。

5. 导入您transkit。这是2的相反步骤 - 您需要将翻译的字符串放回适当的文件。

6. 复制的翻译文件回原来的代码库和运行“本土化”的构建。

7. 测试你的本地化问题中的应用（即重叠控件，剪裁字符串，不正确的编码，等等 - 这通常意味着，国际化是不对完成）。
8. 修复本地化/国际化（Localizability）缺陷。
9. 继续到1，直到UI /字符串冻结期。这假设译员会使用某种翻译记忆库，并且不会对您重新翻译以前翻译的字符串收取费用（或收取较少费用）。
10. 自动完成所有可能的步骤。

除此之外，您可能不会建立您的常用术语词汇表，并对翻译的内容进行语言评论。

Answer 2

我认为你可以在很大程度上依赖于通过.NET有一些修改所提供的资源框架，使之更适合于大型项目，即建设并独立维护应用程序的资源，并消除引用生成的属性每个资源的名称。如果还有其他适合大型项目本地化的目标，请在下面描述，以便我也可以考虑。

1. 创建一个独立的项目来表示可以作为单独的DLL加载的资源。
2. 通过选择项目属性的资源选项卡上的链接添加“资源”文件到您的项目：“该项目不包含默认资源文件，点击此处创建一个。”
3. 添加另一个具有相同根名称的资源来表示另一种语言，例如德语为“Resource.de.resx”。 （Visual Studio显然使用文件名来确定资源文件所代表的语言）。将其移动到与默认资源文件相同的目录/文件夹。 （重复每一种语言。）
4. 在Resources.resx文件的属性，从自定义工具属性删除“ResXFileCodeGenerator”，以防止在应用程序的“属性”命名空间的默认代码生成。 （重复每一种语言。）

5. 明确/手动声明与像行加载新创建的资源，自己的资源管理器：

   静态System.Resources.ResourceManager resourceMan = 新在System.Resources。 ResourceManager（ “LocalizeDemo.Properties.Resources”，typeof（Resources）.Assembly）;

6. 实现可以生成包含您可以参考的所有资源列表的文件（见图1）

7. 实现一个函数来检索和格式字符串（见图2）。

8. 现在您已经足够了，可以从任意数量的应用程序中引用翻译后的字符串（参见图3）。

9. 使用System.Resources.ResXResourceWriter（来自System.Windows.Forms.dll）或System.Resources.ResourceWriter（System.dll）来生成资源，而不是将Resx文件作为主要来源。在我们的项目中，我们有一个SQL数据库，它定义了每种语言中的所有字符串，并且我们的构建过程的一部分在构建资源项目之前生成了所有的Resx文件。

10. 既然您可以从任何格式生成您的Resx文件，那么您可以使用您想要的任何格式（在我们的例子中是一个SQL数据库，我们将其导出并从Excel电子表格导入）以提供文件发送给翻译人员。

11. 另请注意，已翻译的资源正在构建为附属DLL。你可以想象使用正确的命令行工具独立构建每种语言。如果这是你问题的一部分（怎么做）让我知道。但目前，我会假设你知道这个，因为你已经提到了自定义构建步骤。

图1 - 枚举识别所有可用的资源：

namespace MyResources 
{ 
    public enum StrId 
    { 
     Street 
     .... 
    } 
} 

图2 - 代码来加载和返回格式资源字符串：

namespace MyResources 
{ 
    public class Resources 
    { 
     static System.Resources.ResourceManager resourceMan = 
     new System.Resources.ResourceManager("MyResources.Properties.Resources", 
     typeof(Resources).Assembly); 

     public static string GetString(StrId name, 
     System.Globalization.CultureInfo culture = null, params string[] substitutions) 
     { 
     if (culture == null) culture = System.Threading.Thread.CurrentThread.CurrentUICulture; 
     string format = resourceMan.GetString(name.ToString(), culture); 
     if (format != null) 
     { 
      return string.Format(format, substitutions); 
     } 
     return name.ToString(); 
     } 
    } 
} 

图3 - 访问资源：

using MyResources; 

namespace LocalizationDemo 
{ 
    class Program 
    { 
     static void Main(string[] args) 
     { 
     System.Threading.Thread.CurrentThread.CurrentUICulture = 
      new System.Globalization.CultureInfo("de-DE"); 
     Console.WriteLine(Resources.GetString(StrId.Street)); 
     } 
    } 
}