Rails翻译性能影响<%=原始t(与<%= t(

Question

我正在使用rails-i18n Rails构建一个多语言应用程序。我必须翻译的大部分内容(和DB条目)都是纯文本，尽管其中一部分有一些嵌入的html。

我正在考虑使用<%= raw t('translation_key') %>而不是直接的<%= t('translation_key') %>来解释将来可能包含html的更改。

如果我在整个网站都采用<%= raw t('translation_key') %>，我会不会受到任何(负面)的影响

1. 网站绩效
2. 网站安全

Answer 1

您只需将_html附加到您的标签键中，以处理翻译标记中的HTML：

en:
  key_one: test text
  key_one_html: <p>test text</p>

然后，标准代码将起作用：

<%= t('key_one_html') %>

Answer 2

性能方面：

对业绩的影响应该是微不足道的。调用raw将参数复制到一个新字符串中(确切地说，是一个ActiveSupport::SafeBuffer )，并将其html_safe标志设置为true。另一方面，不再对该字符串执行HTML转义。

安全方面：

在任何地方使用raw都有更大的缺点。

你说你的翻译是从数据库中读取的。用户可以编辑这些翻译吗？如果是这样..。

• 您将面临HTML注入的风险:恶意用户只需输入<script>标记即可。
• 从现在开始，所有的翻译都必须是HTML安全的。这意味着您必须手动转义所有翻译，即必须替换<、>和&。

Alternatives:

如果您需要将HTML合并到您的翻译中，还有其他选项：

• 明智地使用_html后缀以防止自动转义
• 使用本地化视图和部分(即index.en.html、_footer.de-DE.html )来翻译视图的更大部分。

若要简化数据库条目的转换，请尝试

• 全球化
• 翻译 (仅限PostgreSQL)

结论：

在任何地方使用raw都会导致道路上的许多问题。省去很多麻烦，只要“视需要”就行了。

Answer 3

您还可以使用globalize来处理更大的text / html内容部分。

https://github.com/globalize/globalize/blob/master/README.md

如果您担心性能问题，它还支持急切的加载。