-
-
Notifications
You must be signed in to change notification settings - Fork 35
Add u: options namespace #846
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 3 commits
0117fee
f969ab6
3a3d4ab
6c20950
087bd0d
9c307cb
af2d4e9
b4b2921
680d25d
01fed13
de56e4c
0c9414b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||
|---|---|---|---|---|---|---|---|---|
|
|
@@ -214,9 +214,21 @@ the following steps are taken: | |||||||
|
|
||||||||
| 3. Perform _option resolution_. | ||||||||
|
|
||||||||
| 4. Call the function implementation with the following arguments: | ||||||||
| 4. Determine the **_<dfn>function context</dfn>_** for calling the function implementation. | ||||||||
| This includes: | ||||||||
|
|
||||||||
| - The current _locale_. | ||||||||
| - The current _locale_, | ||||||||
| potentially including a fallback chain of locales. | ||||||||
| - The base directionality of the _message_ and its _text_ tokens. | ||||||||
|
|
||||||||
| If the resolved mapping of _options_ includes any `u:` options | ||||||||
|
||||||||
| If the resolved mapping of _options_ includes any `u:` options | |
| Implementations are encouraged to support _options_ defined in | |
| the Unicode Reserved Namespace (`u:`). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not "just a namespace", because it needs special powers to affect the function context, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that the "function context" context distinction is an implementation detail.
In most formatters implementations the locale and the options on how to format are passed to the constructor as parameters, at the same time.
I would rather look at this as "universal function parameters" that might be recognized and honored by several / all functions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the problem here is that the current set of u: options behaves that way, but we might introduce one that isn't function context affecting in the future? If our intention to is to require that all such options be context-affecting, we should set that as a requirement in the design doc and elsewhere. We might need to contemplate an additional namespace in the future as well, although I can't think of any universal options just at the moment that we wouldn't just put in the default namespace.
Note: I am not disagreeing with doing this. Just making sure we're consistent and clear about it.
eemeli marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
aphillips marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
| Original file line number | Diff line number | Diff line change | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| @@ -0,0 +1,65 @@ | ||||||||||||||||||||
| # MessageFormat 2.0 Unicode Registry | ||||||||||||||||||||
eemeli marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||||||||||||||||||||
|
|
||||||||||||||||||||
| The `u:` namespace is reserved for use by the Unicode Consortium. | ||||||||||||||||||||
|
||||||||||||||||||||
| The `u:` namespace is reserved for use by the Unicode Consortium. | |
| This registry is for items in the namespace `u:` | |
| which is reserved for use by the Unicode Consortium. | |
| This registry can contain _functions_ or _options_. | |
| Implementations are not required to implement entries found in this registry. | |
| Items in this registry are stable and subject to stability guarantees. | |
| This registry might sometimes be used to incubate functionality before promotion to the RGI or default registry in a future release. | |
| In such cases, the `u:` namespace version is retained, but deprecated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first paragraph is mostly fine, but as #634 is only a PR at this time, it's way too early to refer to the RGI, for instance, or talk about incubation. We can add this language later, when we get consensus on these processes and their names.
I would also find it a bit odd to say e.g. that this "can contain functions", when AFAIK no such u: function has been proposed by anyone.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Permission to do something does not obligate us to actually do it. No one has proposed a u: function, but there's no reason to forbid them.
Are you disagreeing with the design in #634? More specifically, do you disagree with my thinking about how to organize the registries? I do think we should lock-step these efforts to some degree. We'll probably rename RGI somewhere along the way, for example. But I think we'll likely end up with the same concepts at least.
We could replace my line 9 above with something like:
Items in this registry might be deprecated but will not be removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am in general agreement about having definitions for non-required functions and options, but I'm honestly not really sure what the current state of #634 is, and whether e.g. the registry development process added to the PR last Friday is final, or whether it's being iterated on. When we last discussed this on a call in May, it was "Still in progress".
I'm also not sure whether the current design doc proposal's language "Implementations are not required to implement any values found in this registry and may adopt or ignore registry entries at their discretion." ought to be strengthened into something more like a SHOULD.
My preference would be to not lockstep processes that do not strictly need lockstep, and to focus first on the concrete (i.e. this PR), and use that experience to inform the registry maintenance plan. On which we ought to have a separate discussion, if/once it's in a stable state.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why functions?
The idea for the parameters is "u: parameters are potentially recognized / honored by all functions"
What would be the meaning of a "u:" function?
If we think "u:function" is a Unicode function, it is redundant.
All functions in the standard registry are Unicode functions, since this is a Unicode spec.
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps:
| This section describes common options which each implementation SHOULD support | |
| for all _functions_ and _markup_. | |
| This section describes _options_ which are intended to be common to all _functions_. | |
| Implementations SHOULD support resolving and passing these _options_. | |
| _Function_ authors SHOULD implement each _option_ as described here to ensure interoperability. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The proposed language doesn't quite match the accepted design, though. These are not intended to be options that are handled by each function, but by the implementation, and they e.g. apply changes to the function context, so that function authors explicitly do not need to do anything to enable their use.
eemeli marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
eemeli marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
eemeli marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
aphillips marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
eemeli marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
eemeli marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -269,6 +269,9 @@ | |
| "name": { | ||
| "type": "string" | ||
| }, | ||
| "id": { | ||
| "type": "string" | ||
| }, | ||
| "options": { | ||
| "type": "object" | ||
| } | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,105 @@ | ||
| { | ||
| "$schema": "https://raw.githubusercontent.com/unicode-org/message-format-wg/main/test/schemas/v0/tests.schema.json", | ||
| "scenario": "Unicode u: Registry", | ||
| "description": "Common options affecting the function context", | ||
| "defaultTestProperties": { | ||
| "locale": "en-US" | ||
| }, | ||
| "tests": [ | ||
| { | ||
| "src": "{#tag u:id=x u:dir=rtl u:locale=ar}content{/ns:tag u:id=x}", | ||
| "exp": "content", | ||
| "expParts": [ | ||
| { | ||
| "type": "markup", | ||
| "kind": "open", | ||
| "id": "x", | ||
| "name": "tag" | ||
| }, | ||
| { | ||
| "type": "literal", | ||
| "value": "content" | ||
| }, | ||
| { | ||
| "type": "markup", | ||
| "kind": "close", | ||
| "id": "x", | ||
| "name": "tag" | ||
| } | ||
| ] | ||
| }, | ||
| { | ||
| "src": "hello {4.2 :number u:locale=fr}", | ||
| "exp": "hello 4,2" | ||
| }, | ||
| { | ||
| "src": "hello {world :string u:dir=ltr u:id=foo}", | ||
| "exp": "hello world", | ||
| "expParts": [ | ||
| { | ||
| "type": "literal", | ||
| "value": "hello " | ||
| }, | ||
| { | ||
| "type": "string", | ||
| "source": "|world|", | ||
| "dir": "ltr", | ||
| "id": "foo", | ||
| "value": "world" | ||
| } | ||
| ] | ||
| }, | ||
| { | ||
| "src": "hello {world :string u:dir=rtl}", | ||
| "exp": "hello \u2067world\u2069", | ||
| "expParts": [ | ||
| { | ||
| "type": "literal", | ||
| "value": "hello " | ||
| }, | ||
| { | ||
| "type": "string", | ||
| "source": "|world|", | ||
| "dir": "rtl", | ||
| "value": "world" | ||
| } | ||
| ] | ||
| }, | ||
| { | ||
| "src": "hello {world :string u:dir=auto}", | ||
| "exp": "hello \u2068world\u2069", | ||
| "expParts": [ | ||
| { | ||
| "type": "literal", | ||
| "value": "hello " | ||
| }, | ||
| { | ||
| "type": "string", | ||
| "source": "|world|", | ||
| "dir": "auto", | ||
| "value": "world" | ||
| } | ||
| ] | ||
| }, | ||
| { | ||
| "locale": "ar", | ||
| "src": "أهلاً {بالعالم :string u:dir=rtl}", | ||
| "exp": "أهلاً \u2067بالعالم\u2069" | ||
| }, | ||
| { | ||
| "locale": "ar", | ||
| "src": "أهلاً {بالعالم :string u:dir=auto}", | ||
| "exp": "أهلاً \u2068بالعالم\u2069" | ||
| }, | ||
| { | ||
| "locale": "ar", | ||
| "src": "أهلاً {world :string u:dir=ltr}", | ||
| "exp": "أهلاً \u2066world\u2069" | ||
| }, | ||
| { | ||
| "locale": "ar", | ||
| "src": "أهلاً {بالعالم :string}", | ||
| "exp": "أهلاً \u2067بالعالم\u2069" | ||
| } | ||
| ] | ||
| } |
Uh oh!
There was an error while loading. Please reload this page.