ExtJS MVC、动态加载和 i18n

Question

我想将我的 ExtJS 应用程序翻译成不同的语言。我的问题是我正在使用 ExtJS MVC 框架，并且我的大部分 JS 文件都是由框架本身动态下载的。

理想的解决方案(我想到的)是在 Ext.Loader(或我的 Ext.app.Application)中有一个额外的选项来定义要使用的语言，并据此自动下载这样的文件“a.MyClass.fr.js”在加载我的“a.MyClass.js”(其中将包含一个 Ext.apply，覆盖我的字符串资源)之后。这可能目前在 ExtJS 框架中不可用。

我可以看到的替代解决方案是在服务器端执行一个技巧。首先，将在客户端上创建一个 cookie，以设置为语言。在服务器端，我可以捕获对 JS 文件的所有请求，然后如果设置了 cookie(例如 ='fr')，我会将请求的 JS 文件(MyClass.js)与其 i18n 的 friend (MyClass .fr.js) 在服务器上动态地返回结果。这会起作用，但它真的很棘手，因为它暗示了其他事情(缓存......)。

也许最好的方法是自己实现我在 ExtJS 框架中描述的第一个行为......

你怎么看？我正在寻找一种非常干净整洁的方法!谢谢 :)

Answer 1

我最近遇到了同样的问题。

找到一种干净的方法来做到这一点是一个相当大的挑战——大多数替代方案要么......

1) 每个区域复制你的代码库 (WTH)

2)下载覆盖每个组件的本地化文件(维护 hell ？可怜的翻译呢？)

3)使用/生成一个包含翻译的静态文件并引用它(所有语言都已下载？生成它的额外构建步骤？你如何使它们保持同步？)

我试图获得所有世界中最好的，并最终得到了一个实用程序类，负责:

1) 加载 ExtJS 翻译文件(基本上将覆盖应用于 extjs 基础组件)

2) 从服务器加载特定于语言环境的属性资源包(指定要加载的语言环境)。

3) 使用 translate() 方法查询加载的存储(包含来自服务器的消息包)并根据字符串的值返回翻译的原型(prototype)字符串。

这是事情的要点:

捆绑和原型(prototype)制作:

localeStore.load({
    callback : function(records, operation, success) {
        // Define translation function (NB! Must be defined before any components which want to use it.)
        function translate() {
            var record = localeStore.getById(this.valueOf()) ;
            if(record === null) {
                alert('Missing translation for: ' + this.valueOf()); // Key is not found in the corresponding messages_<locale>.properties file.
                return this.valueOf(); // Return key name as placeholder
            } else {
                var value = record.get('value');
            }
            return value;
        }

        String.prototype.translate = translate;
        callback.call(); // call back to caller(app.js / Ext.Application), loading rest of application
    }
});

举个例子:

this.copyButton = Ext.create('Ext.button.Button', {
    disabled: true,
    text: 'DOCUMENT_LIBRARY_MENU_COPYTO_BUTTON'.translate(),
    action: 'openCopyDialog'
});

在服务器上捆绑(mesages_en.properties):
DOCUMENT_LIBRARY_MENU_COPYTO_BUTTON=复制文件
ETC..

优点:

简洁的代码，'Your_key'.translate() 使其易于阅读并意识到这是一个本地化字符串

无/很少的维护开销(为每个语言环境保留一个覆盖文件？天啊..)

你只加载你需要的语言环境——而不是整个沙类。

如果你真的想要，你甚至可以在同一个包中为 ExtJS 语言环境文件提供自己的翻译。

您可以编写单元测试以确保所有包都包含相同的键，从而避免以后出现孤立的翻译

缺点:

同步 - 商店必须在您的主应用程序启动之前加载。我通过从实用程序类中添加一个回调来解决这个问题，一旦加载了所有文本，该回调就会被调用。

没有实时的文本填充.. 虽然我也不想让我的用户重载服务器:P

到目前为止，我的方法已经很好地满足了我的要求。
站点加载速度并没有明显变慢，并且捆绑包(每个捆绑包包含约 200 个键/值)在加载期间的大小约为 10kb。