Hey Zibi, thanks for starting the thread. This has been something that I
was meaning to tackle for some time now.
On Sat, Aug 8, 2015 at 1:01 AM, Zibi Braniecki <
zbigniew....@gmail.com
> wrote:
>
> It can be easily addressed by adding this data bits to the relevant entity
> calls […] 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.
>
This is the key argument for having a system in which some data is
available context-wide. This is how we unlock new possibilities in
translations. I'm really glad that we're coming back to this idea.
> 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.
>
I wonder if there's an opportunity here to make L20n simpler by providing
context data in form of either a) global(s) or b) a special var, or even c)
a special entity.
What bothers me right now is that we have a special syntax for globals (@),
which are context-wide, and a special syntax for vars ($), which can either
be context-wide or local to the entity. This isn't consistent and also
makes it harder for tools to know what 's going on. For instance detecting
a missing reference to a var is hard because the tool has to know that a
particular reference might be a context-wide arg not used in the source
language but required in the translation.
Perhaps we should design our data split (and the syntax) around the concept
of being context wide vs. local to the entity? This would put global and
the context-wide data in one group, and local vars in the other.
I don't have answers to the specifics yet, but maybe the user gender should
be exposed as @gender (a custom global defined by the developer), or
perhaps @ctx.gender or @ctx('gender') to avoid name collisions.
Or, we could go the opposite direction: have a special var which is the
namespace for all context-wide data: $ctx.gender. Which would also be a
way to remove globals all together ;) $ctx.plural or $ctx.deviceType could
work well, too.
What do you think about this grouping-by-scope instead of the current
grouping-by-provider?
> 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.
>
I don't think it's that unreasonable. For things like context-wide
user-gender, we're likely talking about the currently logged-in user. We
can have the server provide this kind of data to the client in form of
HTML. For all-clientside apps, we could still insert the required <script>
before l20n.js is initialized, or pass a promise with the context data to
the initialization of the document.l10n View.
> I don't have details on how exactly HTML API would work, but I think it's
> pretty clear how the JS API should.
>
Do we still want to have a method for updating the ctx data
(ctx.updateData(…)), like we used in v1.x? The rationale was that we
wanted to know when some ctx arg changed value and possibly react to it.
Can we use Object.observe() already? :)
-stas