I'd like to bring back the concept from l20n 1.0.x line of context data.
We didn't add it in 2.x and we don't have it in 3.x yet, but I'd like to get us
all on the same page regarding the value of this feature in the future.
The idea goes like this.
We have a concept that a set of strings can operate within one context.
We call it an l10n context.
It may look like this (using pseudo-API for simplicity):
var ctx = new Context('diaspora.org/board);
ctx.addResource('./menu.{locale}.resource');
ctx.addResource('./settings.{locale}.resource');
ctx.addResource('./board.{locale}.resource');
ctx.get('latestNews');
ctx.get('newMessages', {
messageCount: 5
});
ctx.get('events', {
count: 10
});
Now, the view that this context is used for is a certain board of a certain
person on diaspora social network.
This person has a certain characteristic that may impact translation of some UI
elements in this view. For example gender or name.
In another case, we can imagine a download manager window that has a number of
files being downloaded currently.
Now, there are two aspects that are in play here. First of all, there may be a
lot of elements that may be in one or the other way affected by those variables.
It can be easily addressed by adding this data bits to the relevant entity
calls:
ctx.get('newMessages', {
messageCount: 5,
user: {
name: 'John',
gender: 'male'
}
});
ctx.get('events', {
count: 5,
user: {
name: 'John',
gender: 'male'
}
});
but that's mundane and on top of that, it increases complexity for HTML
bindings scenario where you'd have to set data-l10n-args on all affected
elements.
Second of all, it is possible that the developer doesn't know which entities
may be affected.
Do we know which messages on the diaspora screen should be affected by the
user's gender? Or maybe the Pause button on download manager window should be
translated differently in some languages depending on if there are current
files being downloaded?
Context Data comes to rescue.
Context data is a set of variables that the developer defines on the whole
localization context and can be accessed by any entity resolved within that
context.
It may look something like this:
ctx.data = {
user: {
name: 'John',
gender: 'male'
}
};
ctx.get('latestNews');
ctx.get('newMessages', {
messageCount: 5
});
ctx.get('events', {
count: 10
});
and localizers can use user.name and user.gender from any of the entities.
Now, you may ask, what about HTML API? How do we provide context data for HTML
localization which happens before JS code is executed?
In 1.x we provided a <script> tag with JSON data that stored this, but I
believe now that it was an unreasonable approach because it required build time
variable resolution for client-side UI.
Instead, I suggest that we don't resolve entities that use context data until
context data is resolved.
I'm not sure yet how exactly it may look like, but in my vision it works like
that:
1) HTML has l10n-id's
2) Some of them require context data (I don't know how identified)
3) When we load HTML we resolve all entities except of the ones that require
context data
4) When JS is launched it adds context data which in turn localizes the
remaining elements
I think that it would be actually really useful for all scenarios where
currently devs have to localize HTML Elements from JS just because they need to
pass a single variable resolved at runtime.
I don't have details on how exactly HTML API would work, but I think it's
pretty clear how the JS API should.
What do you think?
zb.
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
