i18n: refactor internals

[dfilatov]

No description provided.

[narqo]

Results from today discussions

Current API:

BEM.I18N.decl('block__elem', {
    key1 : 'string',

    key2 : function(params) {
        return 'string';
    },

    key3 : function() {
        BEM.I18N('i-tanker__dynamic', 'plural', { n : 5 });
        this.keyset('i-tanker__dynamic').key('plural');

        this.key('plural');

        return this.key('key1');
    },

    plural : function() {
        return i18n['tanker']['dynamic']['plural']({ n : 5 });
    }
});

BEM.I18N('block__elem', 'key1');
BEM.I18N('block__elem', 'key2', { foo : 'bar' });

BEM.I18N.keyset('block__elem').key('key1');

i18n['prj']['keyset']['key'] = function() { return 'string '};

---

Future API
to be discussed (TBD):

modules.define('i18n', function(provide, i18n) {

var val = cache[..][..][..];
typeof val === 'string' ? val : val.call(i18n, params, i18n)

// Declaration of translations Object.<Lang.<Project.<Keyset.<Key>>>>
provide(i18n.decl({
    ru : {
        'bem-components' : {
            button : {
                file : 'f1',
                file2 : function(params, i18n) {
                    i18n('bla', 'bla');

                    this('bla', 'bla');

                    this('bem-core', 'bla', 'bla', { b : 1 });
                }
            }
        }
    }
}));

});

Usage with ym (TBD)

modules.define('button', ['i18n'], function(provide, i18n, Button) {

i18n('button', ...); 

provide(Button.declMod(...));

});

Usage with CommonJS (TBD):

var i18n = require('page1.i18n.all.js');

i18n = i18n({ lang : 'ru', project : 'bem-core' });
i18n('i-tanker__dynamic', 'plural') // ru
i18n('bem-components', 'i-tanker__dynamic', 'plural') // ru

//i18n = i18n.lang('en')

var i18n = require('page1.i18n.ru.js');
i18n('i-tanker__dynamic', 'plural') // ru

i18n('i-tanker__dynamic', 'plural') // en

Usage with BEMHTML (TBD)

// TODO:

[narqo]

Thoughts:

• get rid of "project" field – all keysets should live within common context like BEM-items
• think about same syntax for i18n-invocation for ym-modules (which is async), CommonJS, BEMHTML (which are sync), etc

[veged]

Started working with @dfilatov. Decided to omit cases with multi languages in the same runtime for the first iteration.

[qfox]

Why it not moved out of bem-bl/bem-core internals? What's the point to store it inside bem-core?

[qfox]

Decided to omit cases with multi languages in the same runtime for the first iteration.

Well, does it mean global language configuration?

Some troubles with initialisation by lang param? Like here: i18n({ lang : 'ru'

[veged]

@zxqfox it's used wiry widely (inside Yandex) — but there is no overhead for peoples who doesn't use it

but may be we decide to move it out... let's wait for implementation

[veged]

@zxqfox yes — assumption about only one lang per runtime force some restrictions

[qfox]

@veged I don't understand the problem ;-(. At my pov there is no troubles to load all translations and use the needed one (chosen by passed parameter).

[veged]

@zxqfox at least there is a problem to load all translations to browser

anyway — we think about it a lot and consider that we can add such feature later (based on what we got and on really needs)

[qfox]

@veged well, feels like incorrect arch. It's easy to make i18n.register(lang, hash), merge all ?.:lang.i18n.js files to one ?.i18n.js by wrapping to this registrator. And then in browser just switch default context with useLang or something.

Nvm. I still asking about splitting i18n to separate package.

[veged]

@zxqfox you can't load all 100500 lang files to browser — also, there is a problem with async code, if you use I18N('key1') somewhere you can't guaranty that in async case it will be execute with right global lang setting

answered about splitting behind — #576 (comment)

[qfox]

@veged good catch. case with use in async mode should force us to make several ctxs of I18N. But idk how to load it safely before using without async. Simple case here is switching language on the fly for one-page app. So we don't need 100500 languages, just 1 or more (current + all used at runtime). If it can be loaded separately as js files (it's possible with i18n.register) then we could make it without global env.

[qfox]

@veged In summary, it should be possible to merge some popular (or default) translations to js file as i18n.register('ru', { ... }); i18n.register('en', { ... }); code blocks for all bem blocks. and also it should be possible to load translations separately for each bundle as i18n.:lang.js file to load dynamically. What you think?

[qfox]

@veged I also want to understand what's the problem with splitting i18n. Is it a lack of human resource? Anyway there are no available back compatible variants. But discomfort for bem-core developers and customers. Explicit (dependency) better than implicit 🌴

[veged]

@zxqfox I'm think we need to do first step as small as possible and as big as needed ;-) so we can come back to multi lang runtime feature and separation later

[qfox]

@veged Got it. Thanks.

[tadatuta]

See also bem/bem-bl#589

[narqo]

May be we can look (and reuse) some implementations inspired by Intl module of ECMAScript:

• https://github.com/jquery/globalize#message_module
• https://github.com/yahoo/intl-messageformat

[aristov]

modules.define('BEMHTML', ['i18n'], function(provide, i18n, BEMHTML) {
    BEMHTML.BEMContext.prototype.i18n = i18n;
    provide(BEMHTML);
});


/*
* TODO
*
* сделать технологию, которая будет билдить i18n
* сделать технологию, которая будет билдить browser.js+bemhtml+i18n
* сделать технологию, которая будет билдить browser.js+bh
* сделать технологию, которая будет билдить browser.js+bh+i18n
*
*
* */

[tadatuta]

cc @andrewblond

[aristov]

b1/
b1/b1.i18n/all.js ~ b1/b1.i18n.js

[aristov]

ENB techs for the new i18n module.

[aristov]

tests and specs configuration for the new i18n module.

[aristov]

Done.

[veged]

still need to port to v4 #1178