mihnita
commented
2 years ago Some thoughts on this topic.
When implementing support for MF2 in a commonly used library like ICU we should consider that ICU is used in many-many places. It is now the base for i18n support in Windows, MacOS, iOS, Android, several Linux UI frameworks, browsers, many applications.
So the functionality we expose should allow ALL if these customers to implement what they need on top of this ICU implementation.
And some of these users have their own ways to model rich UIs that might not map to a linear view of the world (sequence of parts), or a tree view of the world (DOM). We cannot force one single paradigm on them, we need something flexible.
For example text to speech support often requires the generation of parallel "tracks" of text. Text UI: "Your credit card expires on Aug. 21, 2022" TTS: "Your credit card expires on August 21st, 2022"
Depending on the expressiveness of TTS available one might do that by tagging a sequence of text with semantic info:
tts_info : {
type: date
value: Date {year: 2022 month: 9 day: 21 }
fields: year, month, day
}Or the tts might be very basic, and you might want ICU to add an "explicit spellout text stream"
tts_info : {
type: alternate_reading
value: "August twenty-first, two thousands twenty one"
}The second approach is especially handy when you have custom formatters and you know the underlying TTS engine is not rich enough to know how to read it. Think people names: "Mr. Johnson" / "Mister Johnson", measurement units: "2m/s" / "2 meters per second", currency: "3.2 $US" / "3.2 American dollars", IP addresses, etc.
Another form of "overlapping parts"
Imagine you format an interval:
"Schedule a vacation between {$vacation :interval year:numberic month:abbreviated day=numeric}."
The result might be plain text ("...between Aug 27-Sep 9, 2022.")
Or you want the look like the one above, but clicking in various areas to invoke various pickers. Click on Aug, and show a drop-down list with month names, click on 2022 show a dropdown list of years. Another implementation might want two date pickers, for start / end. So you click on "Aug 27" you show a start date picker, click on "Sep 9, 2022" you show an end date picker. Yet another might want to reach to a click anywhere in the full range and show a date-range picker (https://www.daterangepicker.com/)
So a library should be able to convey the information that various ranges represent different concepts, and that they might overlap:
- a date range (with info on start / end)
- a date, the start in a range
- a date, the end in a range
- a starting day
- a starting month
- an starting year
- an ending day
- an ending month
- an ending year
Which means that a simple placeholder ({$vacation :interval skeleton:yMMMd}) can result in many overlapping parts.
And how many these are, or what those parts are can only be determined after invoking the formatting function (in the example above there is no explicit starting year)
Some existing frameworks that don't use HTML for formatting, but still format things in UI:
- Android : Spanned, which is used for formatting spans, but also for TTS and locale annotations, or custom spans.
- iOS: AnnotatedString
- Windows components usually build on top of RichTextBox
TLDR: what should a library return to support ALL of these use cases.
zbraniecki
eemeli
romulocintra
aphillips
From all I know all parties agree that we need to format to "something that is not text"
We need to decide what that is. Or to decide if is not for the Tech Preview.
Something like format-to-parts, or the "paradigm change" that Zibi advocates, or the (Fluent inspired?) "binding" of formatting functions with variables (I think it was called "formatable"?)