国际化梦工厂

新版本的Singleton中引入了I18nContext这一概念，旨在管理来自不同环境的变量，I18nContext本质上是对Local Storage的一层封装。它携带了pseudoEnabled, i18nEnabled, preferredLanguage和跨组件、跨模块（只要在一个domain下）共享的一系列基础信息，同时提供了一种在服务之间加载和共享这些值的方法，而不必显式地在服务中逐级的传递参数。来自localStorage的伪设置，决定是在调试阶段还是在开发阶段显示伪翻译。...

不知大家是否还记得两年前笔者曾贴出的一张照片（图片拍摄于Unicode Conference），期间列举了国际化前端生态圈中比较主流的框架，Globalize和Moment系数在列，笔者也曾花费不少笔墨对他们进行剖析。本文开始，我准备和大家分享另外一个相对小众的国际化框架Singleton，相比于Globalize（GitHub 4.4k颗星）和Moment（GitHub 44.4k颗星），Singleton在GitHub上的星星目前仍不足百（https://github.com/vmware/si

在国际化软件的时间日期格式方面，我们耳熟能详的有Moment，GlobalizeJS等，那么Singleton又是如何解决该问题呢？宏观上看，Singleton并没有使用嵌入源码的lib模式，而是提供了两个service（目前共发布了两个版本的API，v1做出初始版本已基本被弃用，v2经过与多个产品磨合后，成为了包含类型最多并且较接近Restful API风格的一版，本文所有效果都基于后者）。Singleton的格式API，已经覆盖的国际化关注点包括了日期时间、数字、货币、计量单位、单复数，主要AP

长久以来，所有软件几乎不约而同的对产品翻译资源文件均采用了作为代码一部分的方式统一发布并高度内聚。这样的方式自然有其显而易见的好处，例如不会因为产品本地化而引入任何新的安全问题，性能问题等。然而他带来的问题也不容小觑，作为资深的国际化开发或测试工程师来说，以下场景想必不会陌生。客户：贵公司本地化产品中XX页面上的翻译存在歧义，甚至会严重误导用户。工程师：谢谢您的反馈，我们已详细记录了该问题，将在下个版本中修复。客户：那下个版本何时发布呢？工程师：请再耐心等待半年。客户：……如果.

不卖关子啦，因为本例的背景着实非常小众和特殊，不便引发大家的种种推测，这里直接公布答案——本项目中很早就引入了Singleton作为i18n框架，而在随后的岁月中，Singleton本身经过了几次重要的升级，导致老版本和新版本在stringloading的处理上有着两套截然不同的逻辑体系。在产品的中文主页面上的点击导航栏，发现少量模块（如图中所示的Subscription）的内容回退为英文，而在之前的若干轮测试中，该模块已经可以完美的展示中文内容。...

在之前的文章中，已不止一次的给大家介绍了开源国际化开发框架——Singleton。对于企业级大型应用，其优势的确是肉眼可见的。然后，这是否意味着只要引入了Singleton框架，国际化问题或者说国际化中的三层问题就彻底被解决了么？答案是否定的。在接下来的几篇短文中，我想给大家分享的内容就是即便在import Singleton后，因为种种不规范、不推荐的写法和配置下，直接引发了多种奇葩的国际化问题。首先，让我们一起来关注一个字符串读取问题，现象如下：在产品的中文主页面上不断的点击导航栏，发现UI大部分内容都