On Wednesday, August 12, 2015 at 5:38:54 AM UTC-7, Staś Małolepszy wrote: > 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?
I have no idea. > 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. Ok, I see your point. That doesn't sound bad. > 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? No, and I think it's hard to predict at this point. It's just too early. We still didn't get to start using L20n file format in any app. Once we do, and once we get more UI's that use L20n features, I expect we'll start seeing more duplication of l10n-args asking for de-duplication and that's where ctxdata comes in. :) In result, I'm ok waiting with this feature and not adding it yet. I just wanted to make sure that we have a chance to discuss it before we come to the point where we'll start trying to solve a problem with it. > 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. I'm not sure if I like that. I see a difference between environment variables like @screen or @hour, and ui specific like @gender or @user.name. But those are likely implementation details that we can narrow down once we accumulate more examples of where ctxdata would solve problems. zb. _______________________________________________ tools-l10n mailing list [email protected] https://lists.mozilla.org/listinfo/tools-l10n
