Add first draft of default attribute definitions

[eemeli]

Adds an initial set of expression, markup, and message attribute definitions.

The proposed attributes are drawn from:

• XLIFF 2.2
• The messages.json web extension definition for placeholders.example
• Enumerate supported metadata/properties for messages, sections & resources eemeli/message-resource-wg#19

As noted in the text, this is not intended as a final list, but as a starting point. The text is not being currently proposed to be normative, but we could change that later.

[aphillips]

Good start. Lots of nit-picky comments.

Maybe a good question is: should these be directly incorporated? Or should all of these XLIFFy things be namespaced? Some of what XLIFF does doesn't apply to UMF messages and some of it would be much better on a message resource level (instead of cluttering up the message itself).

[aphillips]

Indicate that yes is default?

Is there a reason attributes don't follow a similar structure to functions and their options here?

[eemeli]

I don't think we've agreement that yes is the default. In fact, for expressions, I would think that the general default might in fact be no to indicate that a translator is not expected to make any changes to the expression.

Considering this a bit more, maybe something like translate=input or translate=|input,minimumFractionDigits| would be better? That would indicate which parts are expected to be translatable.

[aphillips]

The default value is no when the attribute is not present, but yes when the attribute is present and has no value, right?

I don't like the values yes/no, but they are inherited from XLIFF (and its friends, such as ITS) and we should probably remain consistent with them (for portability at least)

[eemeli]

Ah, that's a slightly different undrstanding of "default" than I'd had -- as in, the value that's applied if the attribute is not present at all.

I don't hate the yes/no as they're relatively legible and are perhaps easier to extend with other enum values than e.g. true/false would be. But as they're already in use by XLIFF, we should use the same values.

[mihnita]

I think that requiring explicit values is cleaner.
How hard is it to type =no (3 characters)?

---

translate=|input,minimumFractionDigits| would be better? > That would indicate which parts are expected to be translatable.

I think that such info does not belong here, it belongs in the function registry.

A while ago I even provided a list of l10n attributes to use for each function option (something like hide, read-only, enum, free-form). I can even think of more options.

[eemeli]

Maybe a good question is: should these be directly incorporated? Or should all of these XLIFFy things be namespaced? Some of what XLIFF does doesn't apply to UMF messages and some of it would be much better on a message resource level (instead of cluttering up the message itself).

During yesterday's call, @mihnita also expressed concern regarding cluttering up a message with multiple attributes. His thought was that it would often be preferable to attach a u:id to an expression or markup, and refer to that from a separate message-level block to attach attribute-y metadata to the relevant placeholder(s).

To me, this speaks of a need to have that capability also be well defined, so that it can be ergonomically done across resource formats. In other words, I think we need a JavaDoc-y syntax for message-level attributes.

[mihnita]

Then they are not messages that should be stored in resource bundles. They can very well be hard-coded.

A better use case is probably to encode info about locale sensitive behavior. For example the fact that the default order for a Contacts app should be first-name, except that Japanese, and a few others should be last name.

But that would not be MF2.

TLDR: I am not sure I see a good use case.

[mihnita]

In general I am not happy with the idea of storing all of this in the message proper.
This belongs in the storage, outside the message.

[aphillips]

Although I generally agree, some of these really are necessary in-message breadcrumbs (for use cases you've highlighted previously!). For the most part, these are added by localization engineers and their tools, rather than by developers, to assist tools such as TRADOS and the like in protecting or editing placeholders. Such information is difficult to store outside the message because the act of translation changes the length, content, and placement.

[janispritzkau]

I have a couple of questions and would like to share my understanding of the matter. In addition to the message resource standard, I’m considering how it could integrate with an in-context editing or translation tool.

Expression Attributes

These attributes may vary by locale, so it makes sense for them to be included within the message:

• @comment
• @term - Isn't @comment sufficient for this use case?
• @example - This is really useful. It reminds me of OpenAPI, which lets you generate example queries.

For @translate, I think it should be consistent across locales. To me, it still makes more sense for it to be in the message rather than hardcoded. Perhaps it could be enforced through linters.

Markup Attributes

What exactly does the @comment attribute refer to in the markup context? Is it describing a particular use of the tag, or the type of tag itself, or the content between an opening/closing pair? If it's about the type of tag, perhaps the resource-level metadata (in Message Resource) would be a better place then it should go into a schema/registry.

The same with @term. What is it referring to?

Personally, I would drop these from the spec because they seem too application-specific: Do these attributes define what translators can or shouldn’t do during translation?

• @can-copy
• @can-delete
• @can-overlap
• @can-reorder

Message Attributes

I understand the flexibility of having messages with @translate=no in the resource bundle. However, it feels odd to duplicate such messages across all locales. If a base locale or locale-independent bundle exists, then this attribute would make more sense.

I haven't had time to think about the other message-related attributes yet, so that's all for now.

[catamorphism]

Since I promised during the last meeting that I would look over this PR: I looked it over, and I have no strong opinions and don't feel like I know enough about the use cases to give an official review.

[aphillips]

submitting some old comments held in draft.

[aphillips]

Although I generally agree, some of these really are necessary in-message breadcrumbs (for use cases you've highlighted previously!). For the most part, these are added by localization engineers and their tools, rather than by developers, to assist tools such as TRADOS and the like in protecting or editing placeholders. Such information is difficult to store outside the message because the act of translation changes the length, content, and placement.

[eemeli]

I've refactored the PR so that it's hopefully easier to read, and (as discussed at the last call) included this note at the top:

Important

This part of the specification is under incubation by the MessageFormat WG, and may end up being finalized elsewhere. It is non-normative.

I've also dropped the message-level @max-length, @source, and @version attributes, and applied other suggestions from above.

[macchiati]

General comment. The descriptions need to be more detailed, and there needs to be an example for each attribute.

For example, this description is ambiguous. "re-ordered" with respect to what? Literal text? Placeholders? Other markup? If it is with respect to literal text surrounding the markup, that is very problematic, for example.

[eemeli]

This is intended to correspond to the XLIFF 2 canReorder attribute. I'll add some text clarifying that.

[eemeli]

Done; also added correspondances with HTML & ITS 2 concepts where appropriate.