In the thread about bi-annual syntax review, I listed a number of potential
problems with the syntax.
In this proposal, I'd like to tackle mainly problem (3) and (4).
====================================
Summary:
I believe that there are exactly three linguistic features currently
represented by traits. Each one of them has a very different role and
clustering them with syntax is confusing.
Additionally, their syntax is overlapping with the syntax of variants which
adds to the confusion.
====================================
Proposal:
Each of the three features could be served better if we aimed at identifying
how we should represent them in the syntax to aid readers with their function:
1) Multi-variant value
====================================
Since we are already talking about variants of the value, we should merge this
into selectors.
That would require two changes to our syntax:
a) We would need to allow for selector expressions without selector.
brandName = {
[nominative] Firefox
[possesive] Firefoksa
}
It better represents what the content of this data is, and it reduces the
number of concepts in FTL.
b) We would want to add a specifier
But the reason we originally introduced traits was to allow for referencing a
single variant of the value. If we merge those kind of traits into variants,
currently there would be no way to reference a nominative variant of the value.
For that reason, I suggest that we repurpose trait reference to a "specifier"
which informs which variant of the selector we want to use:
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 believe that those are edge cases, and our design principle has been to make
common cases easy to read and edge cases possible, so I would prefer not to
sacrifice a clear solution because of an extreme edge case.
But to satisfy the need to make sure that we can handle more complex solutions,
I believe that in the future we could allow for more than one specifier for
both nested selectors and chained selectors. It could look like this:
key1 = {
[one] One
[other] Other
} and {
[one] One
[other] Other
}
key2 = { key1[one][other] }
or:
key1 = {
[one] One
[other] {
[masculine] Man
[feminine] Woman
}
}
key2 = {key1[other, masculine] }
Both [X, Y] and [X][Y] approaches can be applied to both nested and chained
selectors, but I believe those to be so rare and esoteric, that I don't think
we need to support them now and it's enough to know that we do have a way
forward if we find the need.
For now, I believe that we should focus on the common use case, which is solved
with this change.
2) Multi-value entity
====================================
This is a completely different use of traits and as such, I'd suggest we
reflect that in our syntax. Because in all cases we encountered, there is at
most a single "value" and multiple "attributes", I believe it's worth treating
it as such.
A syntax that is popular for referencing attributes is a "." dot, so a proposed
syntax might look like this:
key = Value
key.label = Label
key.accesskey = C
Additional benefit of this syntax is that if the value is not needed, it can be
omitted:
file-open.label = Open File
file-open.accesskey = O
I do not suggest separating attribute into their own entities. I believe that
parser should combine value and attributes into a single entity.
Counterarguments:
a) This creates a risk of a single entity sprinkled around a long FTL file or
even multiple files.
I recognize this as a non-goal, and suggest that we enforce attributes to be
only allowed to be listed directly under value.
If the value is not present, all attributes of the same entity must be next to
each other.
Any other combination would result in a parser error.
b) Redundancy in the entity name repeated for each attribute
I find this suboptimal, but an acceptable cost of the change.
Alternative proposals:
We could try to omit the redundancy by writing something like:
file-open
.label = File Open
.accesskey = O
3) Meta-information
====================================
So far, we have not encountered a single other use case of the meta-information
beyond the gender of the brandName.
Although it's an important use case for many languages to be able to construct
messages with the brandname, the lack of in-the-wild cases that we would solve
with meta-information makes me believe that we should not optimize our syntax
for them.
There are multiple proposals on how to encode it. The dominant is to add tags
to the entity. Tags are a common concept in UX outside of software engineering.
It could work like this:
#masculine
brandName = Firefox
key1 = { META(brandName) ->
[masculine] On { brandName }
[feminine] Ona { brandName }
}
In the future we could try to add syntactic sugar to make referencing the meta
information easier, but initially, that should be readable enough and solve the
one case we have while allowing us to believe that it should work for other
cases if we find them.
Thoughts?
zb.
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
