Syntax idea: Portable glossary functions implemented as message resources

[eemeli]

This is a bit of an offshoot from a discussion with @stasm around issues such as that covered in #149. Mostly it's premised on adopting the EZ data model, but at least partly applies otherwise as well. I'm also using Fluent-ish syntax just because it's pretty close to being able to express what I want.

Background

To start with, there is an existing need to define commonly used terms such as product names that are used across multiple resources. For instance, Firefox always includes a brand.ftl resource in its bundle, with these (abbreviated) contents in English:

-brand-short-name = Firefox

In some languages (such as Finnish), these brand terms need to use a gender or case selector:

-brand-short-name =
    { $case ->
       *[nominative] Firefox
        [ablative] Firefoxilta
        [elative] Firefoxista
        [genitive] Firefoxin
        [illative] Firefoxiin
        [inessive] Firefoxissa
    }

In Fluent, -brand-short-name is a term, i.e. a message that is only referrable from other messages. It's used like this:

# english
open-with-browser = Open with { -brand-short-name }

# finnish
open-with-browser = Avaa { -brand-short-name(case: "inessive") }

Proposed Syntax

I believe that a use case like this would be invaluable to have supported in MF2. However, I think that the ergonomics and discoverability of such message references could be improved from those of Fluent. To start with, Flunt considers each such resource to overlay on top of each other, so a Fluent bundle does not namespace the resources that it contains from each other, whereas MF2 would allow for such namespacing.

My proposal therefore would be to permit for syntax like this:

# english
open-with-browser = Open with { BRAND(short-name) }

# finnish
open-with-browser = Avaa { BRAND(short-name, case: "inessive") }

Where the BRAND() function would be implemented as a message resource, looking a bit like this:

# english
.func_name = BRAND

short-name = Firefox

# finnish
.func_name = BRAND

short-name =
    { $case ->
       *[nominative] Firefox
        [ablative] Firefoxilta
        [elative] Firefoxista
        [genitive] Firefoxin
        [illative] Firefoxiin
        [inessive] Firefoxissa
    }

Here func_name ends up as a resource-level metadata entry that lets the processing system understand that its contents ought to be accessible as BRAND(msg_id, key: value, ...). In the data model, such a reference would end up being parsed as a MessageReference that includes the appropriate res_id for the brand resource.

Benefits

The main thing here is that this would allow for the definition of glossary-type functions that would have really well defined arguments and outputs using no implementation code. If something like this were included, then we probably would not want to support other forms of cross-resource message references in the syntax. It would also be pretty easy for tooling to make these functions and their arguments discoverable.

No changes would be needed for the EZ data model proposal to support this syntax.

[mihnita]

How are these different from "regular" message references?

[eemeli]

In message syntax, a function like :brand would not require any extension of the current syntax, as it would use the same syntax as other functions like :number.

[aphillips]

whereas MF2 would allow for such namespacing

Would it? I'm not sure we have a namespacing concept at the moment--this is kind of what @mihnita was talking about in telecon wrt non-local variables. We have no definition of non-local values currently (and thus no namespacing). Note that I'm not saying we shouldn't have it or that we couldn't allow for it--just that we're currently mute about it AFAIK?

---

How does a function get connected to its implementation? If it is always a MessageReference, why do we need to assign it instead of just providing a reference? If it is actually a function call, how to we provide a parameter list/prototype to the processor?

---

I am concerned that this is a particularly sharp-edged feature. It is basically a mechanism for string concatenation. I would expect that developers will do a poor job of designing/setting these up and then it seems to require that individual translators need to provide modifications to the "protected" parts of the message pattern (such as to provide the case needed by Finnish)--they may not know if the function can provide e.g. an "inessive" case or what the fallback will be.

If the goal is to mark up terms from the termbase so that the translator selects approved terminology, that's very different.

But I've had better luck with whole-pattern selection, i.e. something more like:

match {$brand, type: "short-name"}
when Firefox {Open with {$brand, case: "inessive"}}
when * {Open with browser}

(We had this as a feature 10 years ago in FireOS, where ProductNameFormat had generic and non-generic names for products and which included gender information for the name--"phone", "TV", and "tablet" have different genders in different languages, and different length names. We didn't handle case at that time, but the result was like above in which translators received whole segments for translation)

[zbraniecki]

match {$brand, type: "short-name"}
when Firefox {Open with {$brand, case: "inessive"}}
when * {Open with browser}

How would you handle multi-word brands? Can a selector key be a quote-enclosed literal?

Also, I see the tradeoff between what Eemeli suggests and you to be that in Eemeli's suggestion you fiddle with one entity per glossary entry and reference it in X messages.
In your solution you explode X messages to include per-glossary-term selector.

I think that for glossary heavy applications this would be a very bad tradeoff.

[stasm]

How would you handle multi-word brands? Can a selector key be a quote-enclosed literal?

Yes, variant keys can be literals: https://github.com/unicode-org/message-format-wg/blob/main/spec/syntax.md#variants

match {$brand, type: "full-name"}
 when (Mozilla Firefox) {Open with {$brand, case: "inessive"}}
 when * {Open with browser}