我们正在构建一个应用程序,我们首先使用Rails 3,我们必须从一开始就构建I18n.作为完美主义者,我们希望在我们的观点中使用真正的排版:破折号,卷曲的引号,省略号等.
这意味着在我们的locales/xx.yml文件中,我们有两个选择:
内联使用真正的UTF-8字符.应该工作,但很难打字,并由于仍然顽皮的东西unicode的软件数量让我害怕.
使用HTML字符实体(’—等).更容易键入,并且可能与行为不当的软件更兼容.
我宁愿选择第二个选项,但是Rails 3中的自动转义会使这个问题变得有问题,因为YAML中的&符号会自动转换为字符实体,导致浏览器中出现"可见"状态.
显然,这可以通过使用raw
字符串来解决,即:
raw t('views.signup.organisation_details')
但是,raw
每当我们t
遇到问题时,我们都不满足于走向全球化的道路,因为它让我们容易犯错并产生XSS漏洞.
我们可以选择性地raw
包含我们知道包含字符实体的字符串,但这很难扩展,只是感觉不对 - 此外,包含一种语言的实体的字符串可能不在另一种语言中.
有关聪明的轨道的任何建议 - 解决这个问题的方法吗?或者我们注定要废话排版,xss漏洞,浪费时间或者所有工作?
灯塔中存在此问题的票证,解决方案是附加_html
到locales/xx.yml
文件中的i18n键,并使用t
别名1表示html_safe字符串.例如:
en: hello: "This is a string with an accent: ó"
变为:
en: hello_html: "This is a string with an accent: ó"
它会创建以下输出:
这是一个带重音的字符串:ó
这样可以防止你不得不写,raw t('views.signup.organisation_details')
并且会产生更清晰的输出:t('views.signup.organisation_details_html')
.虽然交换raw
了_html
似乎不是最伟大的交易,但它确实把事情说清楚,你输出假设什么是一个html_safe字符串.
t
别名.如果你使用I18n.t
或I18n.translate
翻译没有被_html
视为html_safe:
I18n.t('hello_html') I18n.translate('hello_html') # Produces => "This is a string with an accent: ó" t('hello_html') # Produces => "This is a string with an accent: ó"
我不认为这是RoR TranslationHelper文档的预期行为.
好.我昨天因为i18n角度给这个问题添加了书签,但没有回答,因为我是一个从不使用过Rails的Python人.我仍然不会回答这个问题,但考虑到你并没有被有帮助的Railsians所淹没,他们可以为你提供一个绕过Rails内部的好方法,不过这是我的观点.
首先,我认为你从一开始就考虑问题是很好的.这非常罕见.其次,我完全同意使用原始字符串或选择性地使用实体选择字符串来对声音进行特殊处理,就像一个脆弱,丑陋,容易出错的黑客.
现在,如果我正确理解Rails(我读了这篇i18n指南),YAML文件包含每种语言的本地化字符串.在这种情况下,我强烈建议在其中使用常规字符(UTF-8).否则,维护本地化,甚至阅读翻译文件 - 想想非拉丁文脚本中的语言! - 将会是地狱.
是的,这意味着你必须弄清楚输入方法,但解决方案是干净和直接的.