message-format-wg
message-format-wg copied to clipboard
unicode-org
Developing a standard for localizable message strings
registry.md says that time zone IDs are "A valid time zone identifier" with links to LDML and TZDB. However, LDML and TZDB define two different standards for time zone identifiers:...
The stability policy is too weak to be useful: Consider the following. - After v47 releases, implementation X defines its own custom function :unit. This formats unit names, like “mètre”...
In `u-options.json` we have the following test case: ```json { "src": "{#tag u:dir=rtl u:locale=ar}content{/ns:tag}", "exp": "content", "expErrors": [{ "type": "bad-option" }, { "type": "bad-option" }], "expParts": [ { "type": "markup",...
The `:unit` formatter/selector function should have spec tests.
Conflicts between time zones coming from different sources has been a persistent pain point that the Temporal champions have worked to avoid. It would be nice for MessageFormat to not...
This is similar to https://github.com/unicode-org/message-format-wg/issues/961, but about calendars. There could be two sources for calendars: the input type being formatted, and the message string. (Actually, there is a third, the...
Added text 2024-11-24 ---- I think we need to be careful about our usage of the terms 'well-formed' and 'valid'. The following is not fully fleshed out; it is more...
I had made a comment about adding the short timezone identifiers to > timeZone (default is system default time zone or UTC) > - valid identifier per [BCP175](https://www.rfc-editor.org/rfc/rfc6557) That we...
For consideration after the initial release. See also #125. We should support formatting (and potentially selection on) both numeric and datetime ranges.
Metadata
Owner
Metadata
Developing a standard for localizable message strings