Clarify that standalone markup is permitted. #356
Comments
aphillips
added
documentation
|
I think that we should not have markup at all. All the formatting can be handled with placeholders. Markup open issues:
And to show that it was not agreed on, see PR #283 in Jun 21, 2022:
|
This goes directly against the Unicode TC decision: "Should not assume well-formedness of elements" |
|
This issue is interesting because it touches on a mix of technical and process/meta-level concerns. Although many are intertwined, so maybe we can discuss how to discuss? Technical: I agree that we should call out standalone tags as explicitly allowed with examples. Although that brings up the question of syntax for them, and the higher-level question of what benefits we gain for entertaining special syntax for markup. Meta: We had an issue to discussion how to represent standalone markup tags (#239), but it got closed in favor of #238, which is still open. We also had issue #269 about sigils for markup tags, which was closed after PR #283 was merged, even though it handles open/close tags only. That leaves us in this curious state where open/close markup tags have special syntax in the current spec, and I think standalone markup tags use regular placeholder syntax. Meta/Technical: We have multiple open issues about various details of markup syntax, but we still haven't addressed the question of what special syntax for markup tags buys us in the first place, on top of just using regular placeholder syntax. I asked about this in #262, which is still open. I don't recall hearing a thorough & compelling answer so far.
@mihnita I don't think the length or emotional content of arguments imply the importance of the conclusion, but rather, the technical merits ought to be the main determinant, and I think we have been doing well in returning to the technical points and avoid non-technical feelings and distractions. It might be good for us to consider things in terms of tradeoffs and asking pros & cons, and maybe evaluative criteria on top of that, if arguments get repetitive. |
|
Let's discuss how to approach this Monday. Some specifications have features that are "at risk" and I think markup would qualify as an "at-risk" feature in our spec. We have proposed a syntax to support it, but don't have implementations or clarity on requirements and functionality. This is a recipe for problems when we discover those requirements later... Some approaches suggest themselves:
I think (3) is interesting because one of the challenges with markup is that for Web platforms there are often two levels of it. There are HTML tags and then there are templating languages used by page generation frameworks. There are an unreasonable number of templating languages, many homegrown. If we took an XLIFF approach that might be something we could accomplish and build implementation around (since we don't actually have to build support for pluggable markup regimes). However (1) and (2) are also viable (and these options are not necessarily mutually exclusive--we could do combinations of these or all three). |
|
To help in our deliberations, I'd like to submit the following three real-world Fluent messages to be used as examples that I believe we should be able to support in MF2. These are all from preferences.ftl, lines 92, 125 and 843: ## Extension Control Notifications
##
## These strings are used to inform the user
## about changes made by extensions to browser settings.
##
## <img data-l10n-name="icon"/> is going to be replaced by the extension icon.
##
## Variables:
## $name (string) - Name of the extension
extension-controlling-password-saving =
<img data-l10n-name="icon"/> <strong>{ $name }</strong> controls this setting.## Preferences UI Search Results
search-results-help-link =
Need help? Visit <a data-l10n-name="url">{ -brand-short-name } Support</a>## Firefox Account - Signed out
# This message contains two links and two icon images.
# `<img data-l10n-name="android-icon"/>` - Android logo icon
# `<a data-l10n-name="android-link">` - Link to Android Download
# `<img data-l10n-name="ios-icon">` - iOS logo icon
# `<a data-l10n-name="ios-link">` - Link to iOS Download
#
# They can be moved within the sentence as needed to adapt
# to your language, but should not be changed or translated.
sync-mobile-promo =
Download Firefox for <img data-l10n-name="android-icon"/> <a data-l10n-name="android-link">Android</a> or
<img data-l10n-name="ios-icon"/> <a data-l10n-name="ios-link">iOS</a> to sync with your mobile device.In the above, the According to my understanding of how our current markup syntax ought to work, I believe this could be a representation of the above in MF2, presuming that appropriate |
|
@eemeli noted:
Your description of the current "theory of markup" sounds correct to me. That presumption at the end is the nub of the problem. How does one ensure that +a and +strong are available? Presumably, the runtime that supported your HTML markup would consume the For example, it wouldn't be unreasonable to have style in your source: That requires extra processing to make into valid MF2, because the quoting and perhaps other stuff has to be replaced with our syntax, such as replacing double-quotes with our literal markers: Also, note that your examples do not include abusive use, e.g.: Finally, your examples are strictly in a single markup dialect. There are lots of pages assembled by what I called a "templating language" (think of stuff like mustache) where the string contains both HTML and "something else". The HTML markup handler wants to generate Alas, what happens when the HTML and template language clash: => How does the MF processor know which handler gets the keyword I suspect we might be better off keeping MF out of the markup management business in favor of the markup protection business (using something vaguely XLIFF-like for the example): (Of course that is a lot of work for the developer and fairly unattractive...) |
|
We played today with the difference between Elango's and my mental model and arrived to a reduced discrepancy: With Markup as a AST node: With markup as a placeholder node: They're not that different! |
I would presume that we would include in the registry an enumeration of the supported markup elements, and their valid options.
While that's a possibility, I do not expect that in real-world use a runtime would necessarily be reproducing some other intermediary string representation of a message including markup, but rather building the appropriate output directly. Taking my first example message as a starting point: When formatted for display, this makes much more sense to be formatted as parts, rather than a string, resulting in something like: [
Image(key='icon'),
Literal(' '),
MarkupStart('strong'),
Literal('ExtensionName'),
MarkupEnd('strong'),
Literal(' controls this setting.')
]If the target is an HTML DOM as in the original, the
That's correct, and unfortunate. My personal preference would have been for us to support XML syntax for markup, but this was not supported by the whole group.
That's right. I am not trying to claim that these are exhaustive, but they are actual messages we will want to be able to represent in MF2. It would be very useful if others could provide real-world examples from other sources which e.g. break start/end markup across messages; Mozilla's Fluent messages don't have any such.
If this is handled within MF2, then I would expect the function registry to provide the answer. But that only works if the target is an intermediate string representation, which would require subsequent parsing. If the target is a more final shape, then MF2 only needs to provide a parts representation that'll be handled by some next phase that determines what to make of the markup parts.
Yes, that would be rather unergonomic. |
We use a tooling layer between source documents and messages that generates our messages in a format-independent way. It leverages Okapi for its many benefits in this regard (ex: support for many formats & types of markup out of the box). The handler for the format/markup determines how to create text units and segments. It performs segmentation on the text units using ICU4J BreakIterator to subdivide them into segments, which correspond to individual messages. So in the case of an HTML markup document, if it contains something like: <span ...><i>You're viewing <b>Apigee X</b> documentation. <br/> View <a href="..." title="..." ...>Apigee Edge</a> documentation.</i></span>then we ultimately might get 4 segments that are the equivalent of MF2.0 messages in our current syntax looking like: Okapi will also assign unique ids per placeholder and unique ids per placeholder pair, which I'm eliding here because: 1) brevity 2) we hide from the translator such information in the CAT tool anyways, since it doesn't concern them So it's natural for someone new to seeing this to question whether this is all a good thing, or if it is all too complex for what it's worth, since it's splitting up the inline
FWIW, one of my personal takeaways from chatting with @zbraniecki the other day is a better personal appreciation of the subtle problems—bad practices for localization?—that can occur when users author markup like HTML directly into a MF message. I can also see users wanting to insert things like Even if we set aside how to represent this in MF2.0 syntax, the additional problem here is that you really have a block element (the So what I'm saying is that I think messages that use markup and authored by hand (ex: by developers) will be problematic and error-prone, unless there is tooling to validate (ex: linters) or to assist (ex: Okapi, Fluent). It feels analogous to the problem with current ICU MessageFormat allowing nested messages (which is tantamount to the rookie l10n mistake of string concatenation) in that these are subtle problems likely to reoccur. If we want to address the problem by strongly encouraging some type of tooling to assist and sidestep problems from handwritten markup, then I think the relative importance of human ergonomics or choosing |
That is not how I see it :-) This is how I have represented markup-as-placeholders before: With I will call "the engine" the implementation of the MF2 proper (with parsing, and runtime rendering). With With them separate I can let the engine handle So the proposal is simply markup = placeholder + open/close attribute. If you go back to the proposal last year, that is exactly what it says. I would argue that the two proposals can carry 100% the same information, but the placeholder + function has more flexibility. A syntax like this is a little less verbose: But:
For example html:sub and ssml:sub
If placeholders are good enough for standalone markup, they are also fine for open / close markup (with that extra info about open / close) |
|
If you think about Same flexibility (anyone can add a new namespace without messing with the deep down implementation). And if we make the spaces optional (as was proposed today), the syntax is even closer to html. |
|
I know that for my argument 1. (no other markdown) Eemeli proposed something like And it still leaves us with the inconsistency between open / close markup and standalone as placeholder. |
|
Note: I am not arguing that the proposed markup with But it is not needed (does not bring any benefit that I can see), introduces inconsistencies, and adds unnecessary complexities. And we benefit from all the extras that placeholders offer us: And then we can reuse it in several message variants (plural / gender / etc) Note: in my comments I used markup (with lowercase) for the general concept or markup / html tags, not for the current ebnf syntax. The current syntax is (so technically |
|
@echeran gave an example It would be unsurprising to me to see this being filled in using a templating language rather than static content: Admittedly, putting the static string and the I think the allergy I'm developing to defining markup (no matter what we call it or whether it is using placeholders a la @mihnita above) is this: all of the markup support syntaxes here depend on a runtime processor and obligate the user to learn Yet Another Syntax to place markup into a message. They cannot just write their markup (HTML, SSML, or some templating language) directly. They must learn (or create!) a way for it to be expressed as some form of placeholder. Any tooling that they use to write code using their templating language will not work to e.g. autocomplete the syntax. There is a possibility that the runtime of MF will generate invalid runtime-error-generating goo that will be difficult to debug. Hence, my tendency to not want to get involved directly. Instead, provide a way to help translators do the right thing. I'd even not require it. If you want to put an anchor tag in a string, well... that's probably not a great idea, but just type it into the string: And the generic solution would be to provide hints to translation tools about placeholders. Here I'm using XLIFF tags in the Is it verbose? Yes. But I'm not required to write it. And it translates directly to translation tooling. No developer has to install a templating language registry and any templating language just works out of the box. Is it possible to write bad messages this way? Yes. But developers don't need markup support to do that 🙈 |
I was thinking about this a bit. If we get into the "protection" business, then we could be very neutral about whatever markup (or combination of markup) people want to use. Let's take the following example provided above.
Easiest is if we just allow embedding of exactly the source, with a sigil, eg
(The sigil doesn't need to be @, that's just for illustration.) Now, the problem arises that we need to reduce as much as possible the need to escape characters within what we have embedded, as in the above:
One possibility is that for such items we don't have a simple } terminator, but rather something that is very unlikely. (For illustration here,
We could have a registration of markup introducers like @html. We would hand over to the appropriate markup class the responsibility for determining which sequences of markup were disallowed. Thus if a translator decided to translate the above message as the following (out of order), a markup function would detect that, and the translation software could raise an alert.
That way we don't have to get into the business of determining which markup languages have nested structure, which markup is stand-alone vs initiating vs terminating, and so on. As Mihai said, using 'let' can make messages far more readable, both because it can provide semantics that are more comprehensible to translators, and makes variant messages much more compact (and obviously parallel). |
This is exactly my point. |
|
Looking at all the examples posted here and previously, it seems like they all are some flavour of XML or SGML, or ultimately represent XML/SGML content (i.e. markdown or templating languages). And the markup examples we're playing with either represent XML/SGML elements, or wrap them. Why don't we use XML or SGML for markup? Like, for real. With relaxations for not requiring matching start/end pairs and allowing In previous conversations, the prime reason against this has been the subsequent need to quote I think this is pretty close to what @aphillips is suggesting, except that it doesn't require the |
|
I disagree; we shouldn't have to quote < in literal text.
Now, if we want solely protection, and leave everything else up to the
implementation, then the simplest approach would be to allow {<.*>}.
We would still want to be able to have that in let declarations, to provide
for sharing among variants and for documentation.
…On Wed, Mar 1, 2023 at 1:14 PM Eemeli Aro ***@***.***> wrote:
Looking at all the examples posted here and previously, it seems like they
*all* are some flavour of XML or SGML, or ultimately represent XML/SGML
content (i.e. markdown or templating languages). And the markup examples
we're playing with either represent XML/SGML elements, or wrap them.
Why don't we use XML or SGML for markup? Like, for real. With relaxations
for not requiring matching start/end pairs and allowing $var as values.
In previous conversations, the prime reason against this has been the
subsequent need to quote < in text. But looking at the examples here, I'm
starting to think that allowing bare XML to pass through as "just text"
would be a mistake. If our markup is too onerous, that's probably what many
developers would probably end up doing & then adding a post-processing
parser.
I think this is pretty close to what @aphillips
<https://github.com/aphillips> is suggesting, except that it doesn't
require the {+bpt} and other tags anywhere.
—
Reply to this email directly, view it on GitHub
<#356 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACJLEMFBNEZHUIMDEN4TWZDWZ632DANCNFSM6AAAAAAVCGJM4E>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
TL;DR: what is the requirement in MF for markup support? That would inform us better about what is needed. The only part of our goals that address this is goal 4:
But we are silent about this elsewhere. What do we want to do/need to do to meet this goal? @eemeli noted:
A lot of us on this project work in the Web space, so it should be no surprise that most of our examples start with HTML or with XML dialects. But there are still plenty of application frameworks that are not like this. Some frameworks, like JSTL or ASPX, look like angle-bracketty tags, but not all do. I have worked on a lot of frameworks and languages that render to non-HTML contexts or which didn't use angle-bracketty markup.
Maybe the idea is that MF not understand markup because it is not the job of MF to handle markup. It is the job of MF to place stuff into pattern strings at runtime and to permit translators/translation systems to provide appropriately localized versions of those patterns. MF doesn't need to understand markup to do this. The resource format layer might provide support for markup protection and management (to assist translators) but that would perhaps be out of scope for MF? I notice that this is similar to the reason we don't have character escapes in MF. At the moment I don't think there are any cases where standard placeholders need to generate markup. A function, of course, could generate output that happens to be (for example) a set of bold tags around some text. But that's it's business, not the business of MF to know what the output character sequence "means". Mark's suggestion about using |
That is because we only talk about the examples posted here. Issue #262
Issue #272
Issue #241
In the EM proposal document from last year we mention
|
Unfortunately there are some areas where is beneficial for localization to tools to know what that tag represents, so only wrapping something like a "black-box" does not work well. Many CAT tools have a concept of open-close tags, and they will warn or prevent if one changes the order (close before end). The other (bigger?) problem is that some attributes in the tags need localization. Some examples: I can provide a complete list. And example from W3C (https://www.w3.org/WAI/WCAG21/Techniques/html/H33.html): I can also imagine exposing attributes like
Once we get to register markup inducers, they become very much like the functions in placeholders. So is very much like placeholders with the +/- markers for the open / close concept: So one can even have some attributes come from outside: It is very much like a function with a literal: So I don't think there are fundamental differences between the two concepts. In fact even the people arguing for separate markup still proposed to use placeholders for standalone elements: So placeholders are good enough for standalone, but not for open-close? One reason I can imagine to treat "markup" as different is because we want to differentiate between "things that end up visible on screen as text" vs "things that are invisible but affect formatting". I don't know if this helps anyone, translators or developers. But I think a lot of things from placeholders will also apply to markup elements. So in an implementation I would probably inherit :-) I tried to show that placeholders and the proposed markup are very-very similar. I've seen all kind of arguments about syntax. |
Looking through the issues you linked to, I only find further examples of XML-ish markup. Would you have any examples of messages with non-XML-ish markup that we should support? Taking such targets deeply into account is much easier with examples. If it's hard to find them, maybe we should focus on having good support for XML content in particular?
I would think that this is large part answered by yourself, here:
Markup elements allow for the clear representation of localisable content that is not a flat sequence of parts. As you yourself point out, the starts and ends of markup depend on each other. They have an effect not only on the exact point in the message where they occur, but also on the content between them. By having clear syntax indicating such starts and ends, we make it easier for anyone and everyone working with a complex message to understand what shape it has. This is also why I think our placeholder syntax may be sufficient for representing standalone elements. If it's important to indicate that a placeholder is representing a standalone element, this could easily be achieved with a common prefix: If we were to support XML directly, then it would of course make sense to support standalone elements as well: |
Consider:
I can't quote, obviously, any of Amazon's peculiar formats, but some of them are similar. And there are a variety of angle-brackety formats (such as JSTL, PHP, etc.) that also exist and which might not be quite the same as HTML/XML type syntaxes.
Yes, totally. However, a starting point of "the templating goo is just characters in the pattern" does no harm as long as the translation tools still segment and process the markup. And we can add hinting (so that the developer can indicate where the markers are and what their relationship is) without MF itself knowing what the markers mean at runtime.
This requires the developer to change their tags and markup (and hope that the runtime will generate the correct results). Maybe a different choice would be to allow the message to be "marked up", they way text editors can be instructed which format to use for syntax highlighting/formatting: And allow for multiples: MF doesn't "understand" the markup in the formatter runtime, but translation systems know what to expect. Local markup handlers can be installed for proprietary goo. |
How would you imagine that working for formatters that would return markup elements? Or elements passed into the MF2 formatter as arguments to be placed in the output? |
|
Let's recalibrate on the goals here. @aphillips has asked:
I think the discussion so far has revolved around the following two:
For (1), there seem to be two general approaches:
For (2), it seems that it would be enough if CAT tools were able to:
Note that all of these can be satisfied through a sufficiently capable function registry. For example (the schema is TBD): <function id="html.open">
<signature type="markup" tag="open">
<!-- When the argument is |strong|... -->
<input value="strong"/>
<!-- ...only accept the following options: -->
<param name="title" ... />
</signature>
</function> |
|
Thanks @stasm. Our syntax says that completely blackbox patterns are explicitly allowed. That is, this is a valid pattern: Translators and CAT tools have to deal with the fact that this pattern appears to have HTML in it. We can't forbid pattern strings like this because otherwise people couldn't write HTML tutorials or certain math expressions (and because our syntax says this is valid).
We could add syntax to MF to support this, because clearly developers need to include markup-like tokens (such as HTML or other templating stuff) into strings and translators might have to deal with it. Providing hints to CAT tools and MT engines about the markup will make for more robust translations, which benefits developers (fewer bugs to chase). I think interesting questions are:
I can think of cases where a developer calling For example, a platform I know has a widget set. There can be specific tags that the widgets are attached to at render time. The widget code wants to read the "parts" inside the widget to get field order and specific field contents (for example).
Agreed. And there can be registries used by CAT tools, by the runtime, or both... and these could be separate, e.g. the runtime knows nothing but the CAT tools have extensive knowledge of the markup. You could say that this is the state today 😀
How does this avoid "extra parsing"? Extra parsing by whom? It appears to add parsing to MF's workload, no? What does the MF runtime do with information about the contents of the placeholder? Using ... could render in the Otherwise the developer has to do the work to obtain the directionality and insert it: I guess my concern is that there are lots of good things we can do, but we can't force developers to use our syntax and they can mix and match. The availability of a "bad practice" doesn't make our syntax wrong. |
|
Interesting discussion!
@aphillips, my gut tells me that this is (maybe?) somewhat of a secondary question. I'm hunting through these issues, trying to to see the roots of the markup discussion. I cordially ask, could the primary question more accurately be:
...where enhancement could be loosely defined as "customization of the resultant message to add styling, accessibility, or other functionality within the target runtime". Markup is one mechanism to achieve that end-goal. However, markup does not serve many users in the MF userbase (re: #272).
If we support markup, we do so knowing that it has limited utility. For huge swaths of MF interested users, it has no use at all. @mihnita has been saying the same thing more or less, this time, last year. I think it's a pretty tough argument to make that MF should implement markup, given how low utility it is in so many programming contexts. I do however, deeply desire the capability that markup offers, but I seek it via a mechanism that works for everyone. I weakly hold the position that if we want to support a goal of enhancing translated text, we should do it once, do it well, and support everyone. Eemile pointed to MessageValue as a standard output of MF libs that could be a "works everywhere" way for every runtime to apply markup-like-enhancements. It does not offer formatting directly like markup does, but it offers an intermediate representation that let's us achieve the same goals. Fwiw, eemile explicitly disagrees with making this output part of the MF spec. I respect his opinion, so that gives me pause. However, if we agree that all users should be able to apply enhancements, should we really be including a redundant feature-- |
The current solution we've ended up with attempts to be sufficiently minimal to not impose an undue cost on users that have no need of markup: Effectively, formatting functions may use one of three starting sigils @cdaringe, do you think that this is too much to include? |
|
@cdaringe you keep repeating a claim that markup does not work for many UI toolkits which is statement directly contradicting our position that markup is designed to support all UI element types for all systems including Android, iOS, React Native, etc. I really believe that instead of investing time to double down on implications of your claim, you should document why you believe markups will not work for those toolkits. |
|
edit: I've collapsed my distracting comments below. Fundamentally, conversations in the working group have had ambiguity over the meaning of term "markup", and my comment is me not understanding the context for which this conversation was happening. I kept it there, but it's just noise 😄
> @cdaringe, do you think that this is too much to include?
Hey eemeli, point taken. I interpret your point internally as "Hey, the spec here is minimal, it's open/flexible, it's really low cost of ownership, and likely empowering to many users". That's my expanded interpretation--and if i'm somewhat close to your intent--it's a fair point! I would still posit that markup support is too much to include (with again, a weakly held stance). I'm thinking and typing simultaneously--here are a few reasons that came to mind against inclusion:
Points 1 & 4 are a bit weak, but i think 2 & 3 have some real merit. software is art 🎨 . Please interpret my massive response just as exploration of the topic, not as passionate argument against😄 .
Forgive me, I just perceived this to be clear on the surface. I'd love to see any evidence on how markup could work pragmatically with other toolkits. In lieu, I present an example. Let's suppose that I own and operate the following apps:
Great! Now, my company WhizBangCorp™ needs to up update their terms of service in their various UXes. The "foo bar baz" warning wasn't bold enough. Sure. Ok, every dev team now needs to go make something bold. Markup is the ICU MFv2 text enhancement strategy. It's not coupled to web, can it work everywhere? If we need to make something bold, surely we can use markup! Let's try it: Old message: Question: What is (likely) rendered on 6 of 7 of my UIs? One could say, either:
Woof, that was a serious wall of content. Hopefully it clarifies my perception. |
Yes and no. To clarify: I don't thing supporting "markup" is very useful if by that we mean "real markup" (as in But I think it is very important to support a way to tag sections of a string in certain ways. That information should be accessible to translators, because they have to make sure the proper words are tagged. If that is what we call "markup" then we really need something to support it. I would argue that these days a lot of frameworks use something like that. So I imagine that an Android implementation of MF2 would produce a Spanned object when you formatToParts, a macos implementation would produce an AttributedString, and so on. This is in general pretty well supported by localisation tools, with the "html-y" part well hidden. I've seen those primitive building blocks (open/close/standalone "tags") to translate HTML, makdown (the real thing), FrameMaker, MS Word / Excel / PowerPoint, Javadoc, doxigen, php. And I am quite sure it can handle items 1-7 in the previous comment. I am open to add something for "markup" separate from placeholders, but I think:
TLDR:
That is the meaning when I say "we don't need markup". Maybe the term "markup" is confusing? |
|
i'm using markup as my interpretation of markup. i perceive this is what the others are referring to as well. zibi & eemeli are asserting that this WG supports the most abstract/open as possible markup, no particular flavor.
yes and yes! this is a fine concise synopsis :). markup alone doesn't get us the tagging we need for other platforms' text-enhancement needs. |
Let's take this hypothetical business case as a starting point. What's your proposed alternative for fulfilling the ask of "make bar bold" in all locales, across multiple platforms? Keeping in mind of course that in some, the order might change to something like |
aphillips
added
the
resolve-candidate
|
A stripped down, constrained version of the status-quo MFv2 markup syntax. MFv2 (current): foo {+bar}bar{-bar} baz
MFv2 (proposed): foo {@bar}bar{/@bar} baz
# MFv2 (proposed): föö bäz {@bar}baari{/@bar}In terms of resolveMessage, creation of a spec-blessed In this minimal example, the markup messages and marker messages were semantically indistinguishable, so it is not very interesting. A more interesting example: MFv1: Click <a href={url}>here</a> to continue
MFv2 (current): "{Click {+a href=$url}here{-a} to continue}"
# allowed, preferred from user-space
MFv2 (proposed): "{Click {@a}here{/@a} to continue}"
# still allowed, less preferred from user-space
MFv2 (proposed): "{Click <a href={$url}>here</a> to continue}"Q: Where's the URL in the first Q: How do we apply enhancements/formatting/TTS/accessibility-hints in application-space runtimes? Supposing that // demo: HTML target runtime
// runtime-demos/js/html/index.mjs
const url = "https://example.com";
const html = htmlBinding.fmt("en", "{Click {@a}here{/@a} to continue}", null, {
a: (children) => [`<a href="${url}">`, ...children, `</a>`], // html: string productions are fine!
});
console.log(html); // Click <a href="https://example.com">here</a>// demo: React target runtime
const url = "https://example.com";
const MyReactComponent = reactBindings.fmt("en", "{Click {@a}here{/@a} to continue}", null, {
a: (children) =>
React.createElement( // react: React.ReactElements are required
"a",
{ href: url },
children.map((c) => (c instanceof MessageValue ? c.toString() : c))
),
});
ReactDom.renderToString(MyReactComponent); // Click <a href="https://example.com">here</a>(* demo: ocaml + GTK target runtime *)
module MF = struct
(* (text, gtk_tags_to_decorate_partial_buffers *)
type formatted = (string * string list)
let fmt locale msg data ?(enhancer_map=GtkEnhancer.empty) (buffer:GText.buffer) =
resolve_msg locale msg data
|> snip_snip_snip
end
let fmt_link children: formatted list =
let fn (text, tags) = (text, List.cons "link" tags) in
List.map fn children
let enhancer_map = GtkEnhancer.of_list [("a", fmt_link)]
let fmt_gtext = fmt ~enhancer_map "en" "{Click {@a}here{/@a} to continue}" None
buffer#create_tag ~name:"link" [`FOREGROUND "blue"] |> ignore;
fmt_gtext buffer |> ignore;
w#show ();I added OCaml + GTK as perhaps less common toolkits in order to demonstrate how promoting |
|
@cdaringe Thanks for taking the time to explain your thinking in detail. Two thoughts:
|
|
hey @stasm,
perhaps not. i'm going to pause my opposition as I do a bit more research and practice using the beta impls a bit more in order to make more informed claims.
...ehh it wasn't intended to do so :). the fact that I closed them was really just for ease of review/grokking the concept, not a strict requirement. |
|
Closing resolve-candidates per discussion in 2023-07-24 call |
Is your feature request related to a problem? Please describe.
From our Slack discussion of 2023-02-18/19/20, our documentation should be clear that we allowed unpaired markup.
Describe the solution you'd like
See above
Describe why your solution should shape the standard
It's fundamental to parsing/validation
Additional context or examples
Pasting the Slack conversation:
Mihai
2 days ago
I argued many times that markup dies not have to be paired. And that we don't need markup at all :-)
Mihai
2 days ago
s / dies not / did not /
Mihai
2 days ago
This is the problem with landing things where we have no agreement.
Mihai
2 days ago
What went into that decision was time pressure, and the spec landed 2 days before people were living for the summer. It was either that, or miss the ICU release. (edited)
Mihai
2 days ago
I didn't implement markup in the ICU tech preview, and I have an open issue.
But this is what I tried to warn about in the last meeting. Agree that in a somewhat unarticulated and emotional.
But I was seeing it happening again right there
Mihai
2 days ago
Maybe in spec we should mark things that are not agreed with a special tag.
Otherwise "we decided", and changing them requires more effort. You are "challenging an existing decision" (and in that meeting there was also a push to make that harder)
Mihai
2 days ago
And "just file an issue" is not a solution. Give it some time and it becomes "Mihai is challenging a decision" instead of "we submitted with disagreement".
All that we have as a recording is people remembering.
Mihai
2 days ago
(meaning: not much)
Mihai
2 days ago
Sorry, I should not bring these "heavy topics" over a (long) weekend, over chat, and at unfriendly hours for people in other time zones.
I will stop, and choose another avenue
👍
1
Eemeli
21 hours ago
We currently do not allow unpaired markup (we say so explicitly). This is not consistent with HTML, as you note, but I don't know what went into that decision.
Where do we say so explicitly? Doesn't this section say the opposite, as it states that "[markup elements] do not require well-formedness"?
Staś Małolepszy
10 hours ago
Yeah, my impression was also that unpaired markup is fine. My comment above about the unpaired {-m} being invalid was wrong, sorry about that
👍
1
Addison Phillips
4 minutes ago
Non-well-formedness means lots of things. For example, it can mean cross-over tags:
some {+a}{+b}mixed tags{-a}{-b}
Addison Phillips
3 minutes ago
We don't show standalone tags anywhere in the examples nor do we explain that they are permitted. I'm pretty sure I saw paired-only somewhere recently in our docs, hence my comment.
If we mean to allow standalone tags, we should say so explicitly.
The text was updated successfully, but these errors were encountered: