Meeting Agenda : 2022-02-07

[eemeli]

Unicode MessageFormat WG - Weekly Meeting

Start time: 18:30 CET / 9:30 PT

Meeting Notes : Link

Call : Link

This is the first of the weekly meetings of the WG, and will focus on aliases/macros; a feature mentioned previously in #209, and included in each of our current three spec proposals:

• Eemeli: syntax / data model / error handling
• Staś: syntax / data model / runtime
• Mihai: description

Questions that may be answered by this discussion:

1. Should aliases/macros be included in the spec?
2. Should we call them aliases, macros, or something else?
3. Should they use the same namespace as variable or function references, or have their own?
4. In the syntax, should its assignment and use be marked with the same or different sigils?
5. Can they take literal values?
6. Can they take placeholder values?
7. Can their value consist of a sequence of parts?
8. Can their value contain a selector?
9. Should they be allowed to contain translatable content?
10. Should they be considered translatable or not translatable by default?
11. If the value is not translatable, should it be represented in XLIFF as a part the message text, originalData (not translatable), resourceData (translatable), a separate message, or something else?
12. If the value is translatable, should it be represented in XLIFF as a part the message text, originalData (not translatable), resourceData (translatable), a separate message, or something else?

If you have additional questions in mind, please post them in comments below. I'll send a poll about these to the mailing list in the next few days, to get a bit of a baseline on where we're starting from.

[stasm]

Good list, thanks. A few more that I can think of, related to the syntax and the runtime behavior of aliases:

13. Should aliases be defined before the message body ("in head") or can they be defined inline in selectors or placeholder ("in body")?
14. Can aliases refer to other aliases?
15. If yes, how can implementations prevent cyclic references?
16. Should expressions bound to aliases be evaluated eagerly or lazily?

[eemeli]

The meeting managed to reach preliminary consensus on some of the points under consideration:

• As both "alias" and "macro" have strikes against their use, let us refer to the entities under discussion as "local variables".
• Use cases exist that make including local variables in the data model a good idea.
• Local variables should not allow value reassignment or shadowing.
• The use cases for translatable text content (e.g. a title attribute on an element; fragments with selectors avoiding a combinatorial explosion of top-level selector choices) need a solution. If this is not provided by message references, local variables may serve that purpose.

The following points were covered by the discussion, but not explicitly agreed upon:

• Local variables could use the same namespace as externally defined variables.
• Local variables should be "lazy" in their resolution, in that their value is not immediately resolved to a formatted string or other such final representation when they are defined. This means that e.g. if the value of a local variable is a number formatting call, the formatting options of that number could be extended when that variable is used.
• Even if a local variable does not contain translatable text, the option values it does contain may need to be localisable by a translator. Going even further, the translation of a message may need to be able to define its own locale-specic local variables.

The representation or handling of local variables in the syntax was not covered in any depth by the meeting.

The discussion on the XLIFF representation of local variables turned out a bit more generic in its scope; no conclusions were reached, but the following points were made:

• The XLIFF document may either include a complete representation of a data model, allowing for said data model to be fully reconstructed from just the XLIFF, or it may be only an extract of the data model, and thereby require the original data model for the reconstruction.
• The determination of a local variable's XLIFF representation should be as automatic as possible, rather than customisable.

Some of the exploration of use cases covered ones that are not solvable by local variables:

• Commonly used phrases that are used by multiple messages.
• Accordance between related messages, e.g. Click {button} to continue.

These and related aspects will be further considered during our next weekly call, this coming Monday: #221

[stasm]

Great summary, @eemeli, thanks!