我正在为用德语编写的程序创建英语翻译（即tr（“...”）中的所有字符串都是德语）。使用非英语非德语区域设置的用户可能希望看到英语翻译，但现在使用该程序他们将看到德语。
有一些方法可以解决这个问题：
对于源代码不是英文的地方，国际化的最佳做法是什么？
答案 0 :(得分：2)
这是两个不同的问题。
最佳做法是不要在源中使用任何类型的硬编码字符串。 字符串应存储在外部文件中并通过ID加载。
但你所拥有的并不是最好的做法。可能需要做太多工作才能实现目标。
你所描述的（tr（“...”）东西）听起来像gettext（或类似的东西）。 gettext（和类似的库）的方法是“源中的东西是最终的后备”，如果不存在所需语言的字符串，则使用它。
在这种情况下，我会选择“向用户提供选项”。 你不能假设用户知道英语。
真实的例子：在瑞士，官方语言是意大利语，德语，法语和罗曼什语。如果我要求法语并且不存在，那么下一个最佳选择可能是德语，而不是英语。我加拿大的官方语言是法语和英语，所以如果我和法语不同，那么下一个最佳选择可能是英语。
答案 1 :(得分：0)
我认为最好的选择是询问用户（可能在安装期间）。
将来源更改为英语太昂贵而且不值得。我住在巴西，我们有很多葡萄牙语代码，一次翻译成英语（我们确实为英语人士制作软件）。除非您有一个要求您这样做的客户（通常在您销售该来源时）。
希望有所帮助
答案 2 :(得分：0)
好的，所以我猜三个选项是：
使用翻译的字符串重新编译程序。
这充满了危险，因为你最终会得到两份来源的副本。一个中的错误修复需要在另一个中完成。然后，如果你需要法语，会发生什么？意大利人？西班牙语吗？这种方法的唯一优点是非开发人员可以完成这项工作。 （差不多。）
资源输出字符串，并自动检查UI语言环境的负载情况。
这里的字符串被GetResource("key")或类似的替换。加载时，程序会自动转换为用户的文化。这可能有用，但我知道很多德语人士在他们的电脑上安装了英语文化，但他们更喜欢德语课程。
资源输出字符串并为用户提供加载选择
通常，最好给予用户控制权。这可能是加载时的提示，但如果经常使用该应用程序，这可能是一个烦恼。也许平衡是在安装期间询问用户他们的偏好，然后在对话框中给出一个选项，以便稍后更改此设置。
顺便说一句，请注意，翻译不是本地化。例如：德国的数字格式（例如1.233,44）与英语（例如1,233.44）完全不同。图标等通常具有民族特色。