为什么我不想使用Resx文件：

我正在寻找resx文件的替代方案,以便为我的项目提供多语言支持,原因如下：

>我不喜欢在编写消息时指定“messageId”,这是更多的努力,它对流程很烦,因为我没有看到日志消息实际上会说什么,我需要打开另一个选项卡进行编辑消息
>有时我使用内联代码,因为我不想为简单步骤创建新变量(例如Log.Info(“Iterated {i 1} times”);).使用变量或内联进行简单计算使得整个代码有时比创建其他代码行更清晰

我可以想象的是：

一个外部应用程序,它为所有字符串抓取已编译的exe,使您有机会忽略/添加应翻译的字符串.它可以为所有语言创建XML或Json文件.它将使用散列/ id替换所有字符串,以便仍然可以查找所有语言中的字符串.

我是唯一一个对常用的Resx /集中式字符串数据库解决方案不满意的人吗？我错过了为什么这不是一个好主意？

最佳答案 依靠既定方法而不是实现自己的格式的一个原因是翻译.这实际上取决于您的资源是如何翻译的：如果是由技术背景的志愿者完成,他们不介意在纯文本编辑器中工作,那么您可以自由地提出自己的资源格式.另一方面,如果您将资源发送给技术不熟练且喜欢在翻译环境中工作的专业翻译人员,这些翻译环境具有集成的术语管理,翻译记忆库,拼写和质量检查等等.很可能这种环境不会能够处理您自制的资源格式.

因为我已经提到过专业翻译环境：其中一些工具依赖于ID来确定哪些字符串是旧的,哪些是新的.如果您使用文本为ID的方法,则源语言中的每个固定拼写错误意味着您创建了一个需要翻译并付费的新字符串.如果翻译人员发现字符串的源文本已更改,则可以查看更改,注意拼写错误已修复,确定翻译仍然正常并签署字符串,无需额外的翻译费用.

顺便说一句,如果你想要像Log.Info这样的字符串进行良好的本地化(“Iterated {i 1}次”);你必须找到一些正确处理复数形式的方法.某些语言对不同的数字有不同的语法规则(有关概述,请参阅Unicode Language Plural Rules).只是因为在代码中容易做的事情并不意味着它很容易本地化,我担心.

总结一下：如果您想创建自己的资源格式,请与您的翻译人员交谈.问他们可以处理哪些格式.考虑一下您的格式带来的与翻译相关的限制,例如,如果翻译者因为破坏了字符串而不应该使用任何字符？撇号和引号是这里的主要候选者,因为它们通常用作资源文件中的字符串分隔符,或者 XLIFF并返回：大多数翻译环境都可以处理XLIFF.