Requirements - MF wishlist

[romulocintra]

List of requirements to consider for MF

[romulocintra]

I'am listing requirements from the 1st meeting slides :

List of possible requirements

• Easier to use ICU “Select”
• Fluent could be considered as a starting point for the future of message format
• Have pluggable “formatters”(Date/Time/Number ...)
• HTML Markup
• Cross-platform / Universal Format
• Messages should have more context “description” or ”metadata”
• MessageFormat - More Readable
• Escaping(“ or ‘ ) and Interpolations (html tags)
• Rule Modifiers - Send Message or Send SMS  -> similar to select ICU feature
• Improve Translators / Developers  UX/DX
• I need to somehow be able to cache my translations
• Use Yaml or JSON as file format
• Message reference - from another Message

[zbraniecki]

Proposal for an additional requirement:

• Provides a translation of an XML/HTML element.

[jamuhl]

Sorry, I wasn't there in the first meetings so I'm not sure what is meant with "HTML Markup"?

But:

• fully agree on custom pluggable "formatters"

And add:

• extended plurals, like:

{ count , plural ,
   =0 {No candy left}
  one {Got # candy left}
  <10 {Got a few candies left}
  10-20 {Got a handful candies left}
other {Got # candies left} }

edit:
in i18next we use a postProcessing plugin to achieve that: https://github.com/i18next/i18next-intervalPlural-postProcessor#usage-sample

[zbraniecki]

HTML Markup

Ability to interpolate localization with HTML. Example:

<span>You have <b>6</b> unread messages from <img/> Mary.</span>

Fluent provides DOM Overlays which are heavily used in Firefox l10n - https://github.com/projectfluent/fluent.js/wiki/DOM-Overlays

[jamuhl]

@zbraniecki thank you for explaining...so basically take the innerhtml element(s) and extend it with the attributes and content contained in the translation...looks similar to the Trans component we have in react-i18next -> https://react.i18next.com/latest/trans-component (just we have no html elements but react components)

edit:
guess we could mimic DOM-Overlays by extending our Trans component...just not sure if this is part of the syntax or an extension that is provided by the i18n library?

[romulocintra]

@mihnita should i reference here the your entire document or we can break it in features to add here ?

[zbraniecki]

In our experience innerHTML in particular is a no-go for security reasons (l10n resources are treated as a third-party). I expect the requirements from the W3C to be similar here.

Instead, we whitelist allowed textual elements (<sup/>, <sub/>, <span/> etc.) and for everything else we require the developer to provide the elements in the source with a name, and then the localizer can position them using the same name:

<p data-l10n-id="key1">
  <a href="https://www.mozilla.org" data-l10n-name="link"/>
  <img src="./pics/img1.png" data-l10n-name="logo"/>
</p>

key1 =
    Welcome to <a data-l10n-name="link">Mozilla</a>!
    Please, click on <img data-l10n-name="logo"/> to proceed.

That's significantly more involved than innerHTML, but the end result is quite similar with a lot of linting, security, and sanity checks.
We're also discussing further extensions - https://github.com/zbraniecki/fluent-domoverlays-js/wiki/New-Features-(rev-3)

[jamuhl]

innerHTML was more referring to the content than to the implementation detail...same reason we do not just append translations into a react element by using dangerouslySetInnerHTML ;)

[mihnita]

I will break into features.But maybe also link, so that others can read the complete doc.I think that the current list of features will also need to "grow" with some more details. As it is some of them are so short that only the one who proposed it really understands what it means :-)MihaiOn Jan 6, 2020 11:41, Romulo Cintra <notifications@github.com> wrote:@mihnita should i reference here the your entire document or we can break it in features to add here ? —You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or unsubscribe.

[romulocintra]

@mihnita

• If you can break the into features great and link is important to Both are important
• I completely agree that some of features wont fit in one line and will need more detail, that ones IMHO deserve a unique issue or thread.

My Proposal :

• If you can break it into features will be perfect(agree that the link is important too)
• Some of the features won't fit in one line description needing more detail, that ones IMHO deserve a unique issue or thread, I suggest that we can create a new Issue tagged as "requirements", where we have all detail and discussion about that issue, but we can keep a reference with description here to keep the list in only one place.

I feel that also the short description ones will grow to have their own issue/task, but I think we can figure out later after we groom and filter the tasks/lists of requirements

[longlho]

My proposal for the process @romulocintra is to set a deadline, then de-dupe the list, then prioritize into mvp, v1, v2... so we can move this along.