FWIW, I agree with the analysis of the problem and I like all of the suggested solutions. (Maybe because I participated in the discussions about these last week :).
On Fri, Dec 16, 2016 at 11:00 AM, <[email protected]> wrote: > 1) Multi-variant value > ==================================== > brandName = { > [nominative] Firefox > [possesive] Firefoksa > } This would go well with the proposal to enforce a default to be present in a list of variants. In this example, we'd write *[nominative]. > key = Welcome to { brandName[nominative] } > > This syntax is intuitive and serves the function. > > The question is how to solve edge cases, like handling multiple selectors in > a single value and specifying for that. I realized that accessors are very hard to design in the current syntax. Select expressions can appear in Patterns which are elements of other Patterns, e.g. " Foo { "{ foo -> ... }" }." This is a different kind of nesting than the one you present in your examples. In order to make the semantics complete, we'd need to spec out very complex accessors, like [foo, [bar]][baz]. I don't want to do that -- not because I'm lazy but because I doubt it's useful at all to localizations. What if we limit the foo[bar] accessor syntax to values which are a Pattern with a single select expression which must not have a selector? Otherwise [bar] is ignored and normal semantics of resolving the Pattern apply. > 2) Multi-value entity > ==================================== > I find this suboptimal, but an acceptable cost of the change. It also helps readability, so I'm okay with it. The following reads clear to me: file-menu.label = File file-menu.accesskey = F While the current equivalent requires more visual parsing: file-menu = [xul/label] File [xul/accesskey] F > 3) Meta-information > ==================================== > #masculine > brandName = Firefox We could also allow Mozilla-specific tags in the future, like #private for message which shouldn't be checked by compare-locales. * * * We'll need to choose names for these new constructs and I'm lost in looking for good examples to follow. For #2, HTML uses "attributes" and React uses "props". For #3, Rust uses "attributes" and Twitter would call them "hashtags". We also still have "traits" :) Do you have any naming scheme in mind? -stas _______________________________________________ tools-l10n mailing list [email protected] https://lists.mozilla.org/listinfo/tools-l10n
