我遇到了国际化标签的问题。
我的应用程序使用 Granite.I18n.get('') 函数在 js 前端读取几个 i18n 标签。整个词典下载为“/libs/cq/i18n/dict.{+locale}.json”，如“/etc/clientlibs/foundation/shared/source/init.js”中所述。
现在 en 字典只返回自定义标签，而且体积很小。 但其他语言如fr，字典文件是所有/libs 字典的集合，非常庞大。我也在其他几个网站上注意到了这一点。
tennantco.com
en dictionary - 118 KB
fr dictionary - 1.4 MB
Timewarnercable.com
en dictionary - 1.1 KB
fr dictionary - 1.2 MB
Thermofisher
en dictionary - 3 KB
fr dictionary - 695 KB
我们的痛点是，在 CDN 上缓存这个大文件的成本增加了，我们正在努力寻找降低 CDN 成本的方法。
我了解 en 标签本身就是 key 。但是 ExportServlet 只能为 en 过滤掉渲染自定义字典。我们的词典类似于/libs 下的 otb 词典。那么 ExportServlet 是如何处理 en export 下的 otb 标签的呢？
此错误在所有 CMS 产品中都很常见还是特定于 Adobe？还需要一个解决方案或解决方法来获取仅适用于其他语言的自定义词典。
最佳答案
英语词典很小，因为英语条目是键而不是翻译。法语(和其他语言)很大，因为它们包含英语和进一步翻译的关键。此外，很多 key 仅在翻译语言中可用，只是因为 key 用作默认翻译。
因此对于法语，如果您使用 Granite.I18n.get('Hello world!')，如果找到法语翻译，它将返回法语翻译，否则它将简单地返回 'Hello World'，如果语言环境是英语，则不需要翻译。
由于在客户端评估 JS 的性质，该产品旨在下载完整的词典，包括产品本身的 OOTB 翻译，因为 i18n 实现不是上下文感知的，也无法过滤掉不需要的翻译。
虽然方便，但不幸的是，这是使用 Granite.I18n.get('') 的限制和副作用。
可能的解决方法
- Granite.I18n.* 可以通过使用服务器端 i18n 库并仅在服务器上呈现所需的翻译并作为部分 HTML 来避免。这可能不适用于 SPA。
- 如果您使用的是像 Angular(x) 这样的 SPA 框架，那么它们支持 i18n 工厂初始化，可以挂接到自定义 servlet 响应，下载经过过滤的 i18n。这可能需要大量工作，而且如果翻译的术语太多并且字典变大，那么大小仍然是个问题。
- 压缩、最小化和缓存字典。您可以使用 Apache 模块或输出过滤器来完成。这将减少大小和流量负载，但同样不能保证随着翻译的增长整个词典的大小会变小。
一般来说，页面必须只呈现需要的内容。使用 JS 做后期翻译会强制下载字典，Granite.i18n 不适合优化下载体验。
关于internationalization - 我可以得到特定词典的整个 i18n 标签吗，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/45330214/