Generalize the data-i18n attribute and allow arbitrary JS

[papandreou]

Right now the data-i18n attribute is run through eval before being interpreted by cloneForEachLocale, mostly in order to avoid quoting keys when using the Knockout.js data-bind-inspired syntax. It would be even more powerful to actually model it as an inline JavaScript asset so it could contain relations, and so that placeholders/templating can be used in attribute values. I've seen use cases for both, most recently #85.

It could look something like this:

<div data-i18n="attr: {'data-foo': GETSTATICURL('some/path.js'), title: TR('TitleLanguageKey')}, text: TR('BodyLanguageKey')" title="The title in the default language">The body text in the default language</div>

The data-i18n attribute should probably be renamed if we go ahead. Any ideas?

[papandreou]

This could potentially also solve #52.

[papandreou]

More things that should be configurable per element (cc @gustavnikolaj):

• Whether to allow inlining of a script/stylesheet/image element
• Whether to allow bundling of a script/stylesheet

[papandreou]

• Whether to omit the script/stylesheet/image in the production build

[gustavnikolaj]

The use case I had for this recently is this:

Hammer.js has two plugins* that are useful for debugging and development on desktop machines. I wanted to include those, but not when doing a production build. I wrapped them as a module, and can include them in the module where I need them. For now, I'll have to add them to the module before I start developing and remove them before the commit.

define([
    '3rdparty/hammer.debug'
], function () {
...
});

Given the nature of the plugins, I do not need to include them as a argument for the module, and thus we could do something like a pseudo require.js plugin - inspired by the tpl plugin.

define([
    'development!3rdparty/hammer.debug'
], function () {
...
});

I'm not suggesting that we do though - I'm afraid that it's not general enough to be useful for other cases than this particular one. I could have included it in various otherways - and we might find that one of those alternatives is better suited for solving this issue.

I've previous had similar problems with a production / debug build of a module, where I wished to include one in one environment and another in the latter.

*: https://github.com/EightMedia/hammer.js/blob/master/plugins/hammer.showtouches.js https://github.com/EightMedia/hammer.js/blob/master/plugins/hammer.fakemultitouch.js

[Munawwar]

This might be helpful - https://github.com/mbest/js-object-literal-parse. Apparently the same code is part of KnockoutJS 3.0 beta (source: https://github.com/mbest/js-object-literal-parse/issues/3).

[papandreou]

No longer a concern here after the i18n-related code was moved to https://github.com/assetgraph/assetgraph-i18n

Also, I'm not really sure it would be worth it.