On Wed, Aug 12, 2015 at 12:09 AM, Zibi Braniecki < [email protected]> wrote:
> > 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. > What the localizer cares about is which variable can be used in the string and which can't. It's not clear to me what our plan to make this easier is. How is the localizer supposed to know if they can use $gender or $n in other strings? What can we do to make tools help the localizers? If context data was part of the global scope (whatever the syntax might be for it; let's put this aside for now, as you say), the distinction is clear. $n is a local arg passed to the entity. It can't be used freely in other entities. @gender and @plural are global, on the other hand, and can be used in all entities. Another way of thinking about that is that globals are context-wide data that's always available in every context. I also don't expect there to be many use-cases for context-wide data provided by the developer. The gender is probably *the* most important one. Do we know of any other? In fact, I'm starting to think that maybe all globals should be developer-provided. That is, the developer should have the control over which globals they want to provide. There would be sane defaults for the given environment (@screen for browsers etc), and the developer could add their own "globals", like gender. The benefit of this approach would be that all global references would be grouped together which would make it easier to understand where they can be used and also it would be easier to instrument tools about globals available in the current context. Right now we'd need to instrument twice: once for globals and once for context-wide data provided by the developer. -stas _______________________________________________ tools-l10n mailing list [email protected] https://lists.mozilla.org/listinfo/tools-l10n
