On Monday, August 10, 2015 at 8:39:30 AM UTC-7, Staś Małolepszy wrote:
> 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?
I'm not strongly opinionated on @ vs. $ctx for globals. My slight preference
goes toward using '@' just because of minor things like having to deal with
name overlap or special-casing variable names.
But I'm ok doing that if we have a reason to avoid '@'.
On the other hand I do have a strong opinion on grouping-by-provider. I feel
that dual-nature of variable (coming from context or from the call) is actually
a feature and a very desired one for me while globals are context-scoped by
nature.
I must say that I don't see anything confusing in that.
The dual-nature of variables makes sense to me because they are preserving the
isolation of concerns. Localizer doesn't care how the developer provides the
variable, and the developer can define a context one, and then override it
locally for a particular call.
> 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 think server side code should inject content like that into HTML. I
believe it should be polled with API at runtime.
So I still think that <script> tag is not helpful here.
> 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.
I think so.
> Can we use Object.observe() already? :)
Yes.
zb.
p.s. I'd like to make sure that Axel, you and I agree on the big-picture idea
of having data from the developer provided to the whole context before we dwell
into syntactic formatting.
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
