Expand expression attributes proposal #473
Conversation
There was a problem hiding this comment.
I'm not sure about the runtime uses of attributes. I primarily see them as aid for tooling. For the runtime, I think we can leverage the open/close syntax to create spans decorated with some extra data, as needed.
Attributes can be assigned to any expression, including expressions without an annotation.
I'm not sure if attributes should be allowed on all expressions, or perhaps just placeholders? For example, if the @locale attribute impacts the runtime, would the following example produce 1.0 apple?
let $myCount = {$count :number minFracDigits=2}
match {$myCount @locale=fr}
when 1 {{$myCount} apple.}
when * {{$myCount} apples.}
| > Example embedding a French literal in an English message: | ||
| > | ||
| > ``` | ||
| > {In French, "{|bonjour| @locale=fr}" is a greeting} |
There was a problem hiding this comment.
Is this use-case also solved by spans?
{In French, {+span locale=fr}bonjour{-span} is a greeting}
+span/-span doesn't even have to mean HTML span here. It's just a start and an end of a span of text that should have a different locale property. The runtime can then decide how to express it such that the locale is isolated properly.
There was a problem hiding this comment.
@stasm I don't think so. The spans don't affect their interior text? Recall that in formatToParts the MessageValue has direction and language properties for this. Although, your formulation has a certain attraction, as "bonjour" is just some text. One can imagine this:
In French {+g @locale=fr @translate=no}bonjour{-g} is a greeting
(using g for xliff:g)
| > Example providing a translator with an example for `$place`: | ||
| > | ||
| > ``` | ||
| > {Hello {$place @example=world}} |
There was a problem hiding this comment.
This is treading the semantic comments territory. Perhaps it would be best to leave this out of scope?
There was a problem hiding this comment.
With semantic comments we may reasonably describe values such as $place, but not specific expressions, which may even be repeated in variant patterns. So expression attributes such as @example and @note should be considered.
| > Example embedding a French literal in an English message: | ||
| > | ||
| > ``` | ||
| > {In French, "{|bonjour| @locale=fr}" is a greeting} |
There was a problem hiding this comment.
@stasm I don't think so. The spans don't affect their interior text? Recall that in formatToParts the MessageValue has direction and language properties for this. Although, your formulation has a certain attraction, as "bonjour" is just some text. One can imagine this:
In French {+g @locale=fr @translate=no}bonjour{-g} is a greeting
(using g for xliff:g)
| > Example embedding a non-translatable French literal in an English message: | ||
| > | ||
| > ``` | ||
| > {In French, "{|bonjour| @locale=fr @translate=no}" is a greeting} |
There was a problem hiding this comment.
See above: I like bonjour being part of the string better than as a placeholder operand. Placeholders often look like a little colored box and the translator has to expand the thing or carefully read the attributes to learn what it says.
There was a problem hiding this comment.
In this case, would that not be an appropriate representation of a non-translatable literal?
|
@aphillips @stasm Please take another look? |
There was a problem hiding this comment.
I think maybe having a source standard for additional expression attributes makes some kind of sense. While XLIFF and ITS and such have been with us a while, evolution is always a possibility here. If there were a source standard, that might suggest namespacing the attributes and making them a plug-in rather than requiring them for MF2's release. Some systems don't have meaning/support for some of these attributes and some systems provide external support for e.g. notes and examples.
That is, can we modularize this out of MF2? Or do we need this now? Or (my preference) can we reserve space for future work?
| To support later extension of the specified set of attributes while allowing user extensibility, | ||
| require custom attribute names to include a U+002D Hyphen-Minus `-`. | ||
| suggest custom attribute names to include a U+002D Hyphen-Minus `-`. |
There was a problem hiding this comment.
This might be related to #475 ?
There was a problem hiding this comment.
Yeah, this is ultimately dependent on resolving namespacing.
|
This PR improves the proposal doc, and keeps its status as "proposed", so I think it's good to merge. That said, I have a number of comments about the overall attributes proposal. I opened #513 to continue the discussion. |
|
I think we should merge this and make time imminently to discuss the inclusion of expression attributes into the syntax. Currently this looks like it could miss the |
|
Merging is fine, but this should be prioritized below the LDML45 release; that is, not spending time time on it until all LDML45 MVP issues are settled. |
|
This PR adds examples and alternatives to the design doc, and does not change its status. Merging it would make the design doc more cohesive and comprehensive, making it easier for us to consider the proposition as a whole. Given @stasm's latest verbal approval above and the lack of comments from others on this for the past few months, I would suggest that an approval from @aphillips could be considered sufficient for merging this, which would make it easier to file a follow-up PR updating the proposition's status, for consideration before and at a January meeting. |
|
I am merging this now and will schedule a topic in January to discuss inclusion in |
Adds examples for use cases, relaxes namespacing to a suggestion, and documents function chaining as an alternative.
Full doc: https://github.com/unicode-org/message-format-wg/blob/exprattr/exploration/expression-attributes.md