Comments migrated from the slides

Slides comment, Addison Phillips (@aphillips), 6:48 AM Apr 21

This will be an interesting requirement. It suggests auto-close. Is there a syntax for a singleton placeholder, e.g. {foo options=bar/}?

Slides comment, Eemeli Aro (@eemeli), 8:04 AM Apr 21

Not yet, at least. We've tried to keep this proposal pretty minimal to start with, and our suspicion was that a self-closing markup tag and an expression were possibly the same thing, so this could work for your example:

{:foo options=bar}

Slides comment, Addison Phillips (@aphillips), 8:30 AM Apr 21

Hmm. My original understanding was that the markup would be replaced by a different level of processing than the message formatter. An expression would work, but it's not the same thing as a placeholder. In the back of my mind are XLIFF's <ph> elements, which can be paired or unpaired. Unpaired items can be moved anywhere in the translation. Paired items have to be span-like (start before end)

I know that HTML5 has been relaxed to allow autoclosing and so maybe we want to mirror that, but it also presents a problem in translation if the auto-close is assumed.

This is {b}bold. => ja: This {b}bold is. (is missing a close after bold???)

Slides comment, Eemeli Aro (@eemeli), 9:19 AM Apr 21

I think those end up as decisions that we've tried not to make here. As in, for {:img} vs. {img/}, can the :img function resolve to some value that would be formatted in an appropriate way?

Regarding the autoclosing, we found it important to be able to at least represent unclosed tags in the data model. It should be a topic of further discussion for whether the spec should even mandate exactly how a message with such partial markup ought to be formatted.

Slides comment, Elango Cheran (@echeran), 11:16 AM Apr 21

+1 to Addison's comments that the markup would be replaced with a placeholder by a different level of processing.

Also, the syntax here as presented doesn't indicate the type of markup, not even a function that indicates the markup type. By not having a placeholder with a function that represents the markup formatting, we lose the ability to represent different types of markup. It would require the runtime to commit globally to one type of markup support. I would expect that a runtime that can handle messages, some of which know how to invoke various types of "markups" (an HTML formatter, a Markdown formatter, an MS Word formatter, etc.)

Slides comment, Elango Cheran (@echeran), 11:19 AM Apr 21

(Btw, I couldn't tell in other previous comments of the thread if this idea was missed or not, so just in case, this bullet point says "well-formedness ... not required". I think we're all in agreement on that -- ex: you can find valid old HTML with multiple unclosed <p> tags.)

Slides comment, Eemeli Aro (@eemeli), 1:50 PM Apr 21

To represent different types of markup, it should be possible to use some implementation- or user-specific method for namespacing markup tags. For example: {html-b}foo{/html-b} or {md.link}...{/md.link}.

This matches the instruction that we got from the CLDR/ICU TCs regarding allowing . as a character in variable names, but not assigning meaning to it within the spec.

Slides comment, Addison Phillips (@aphillips), 8:41 AM Apr 22

A few additional points.

(i) Generally markup (or its proxy) is protected from translation in XLIFF using placeholder tags--to prevent accidental mutation. Auto-closing should generate a placeholder. Note that HTML is different WRT auto-closing, since they are parsing into DOM. We don't have HTML. We have fragments.

(ii) I think the document could be more explicit about how markup syntax stays out of conflict with other placeholders. Am I reading it correctly that all formatting placeholders are identified by $, e.g. {$myVar} vs. no-identifier for markup e.g. {myBoldTag}? Perhaps markup should be namespaced in a way to relates to placeholders?

Slides comment, Mihai Nita (@mihnita), 10:56 AM Apr 28

user-specific method for namespacing

That feels like a patchy solution to a problem we are introducing.

A "namespace" is technically the same thing as a function:
{"b" :html}

But it is a lot more hacky, with no good reason.

And it forces all tags through the same function (standard or custom).

With functions one can do:
{"sub" :html} ... {"sub" :html}
{sub :ssml} ... {/sub :ssml}
{sub :mihai} ... {/sub :mihai}

In the EM syntax:
{sub:open ssml}...{sub:close ssml}

With this proposal the interpretation of "namespace" has to be done by the library implementing MF2.

We need to reserve a spacial character to mean "namespace"
And that standard implementation would have to parse the tag, and use the "namespace" to lookup a table of markup functions to find my custom "mihai" function.

Which is a 100% duplication of what placeholders / formatables / expressions already do.

Slides comment, Mihai Nita (@mihnita), 11:09 AM Apr 28

TLDR: there are quite a few localisable HTML attributes.

===

For example alt, label (in option, button), value (in li), abbr (in td and th), summary (in table), placeholder (in textarea), several fields in meta (description, keywords, etc)

Then there are things that are not quite localizable, but need to change.
Sometimes hard/impossible to do algorithmically.

content-language and lang can be automated.

But there are links (in href or src) that are not under the control of the developer, and not algorithmic.

For example links to local government sites.
Or this link to this Japanese Wikipedia page for Bruce Willis:
https://ja.wikipedia.org/wiki/%E3%83%96%E3%83%AB%E3%83%BC%E3%82%B9%E3%83%BB%E3%82%A6%E3%82%A3%E3%83%AA%E3%82%B9

Comments migrated from the slides

no prefix

Slides comment, Markus Scherer (@markusicu), 9:06 AM Apr 25

Always use a prefix (punct/symbol char).
If : is no good for a function, then that might be ok for MarkupStart.

Uh oh!

Markup: how do ensure non-HTML display elements are first class? #238

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions