-
Notifications
You must be signed in to change notification settings - Fork 108
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
Complete the extension keys + options + resolvedOptions set #105
Comments
Looking for feedback. |
cc @jshin |
obviously, the deprecation process is the problem here. I wonder if we can figure a way to have some sort of synergy here to preserve the
All that seems to be very straight forward and completely backward compatible, but... there is always a but... there is one more combination that is more complicated:
I wonder what can we do in this case? |
/cc @ericf @juandopazo |
Can we just assume that |
No, because that is not BC. Imagine that there is an app that is suppose to use hour12, (e.g.: an abstraction of |
Hmmm How about - if both are present in the same place (options) then the newer one takes precedence. But generally, options take precedence over extension keys, so: Intl.Locale('de-hc-h24', {
hour12: true
}).hourCycle; // 'h12'
Intl.Locale('de-hc-h24').hourCycle; // 'h24'
Intl.Locale('de', {
hour12: true,
hourCycle: 'h24'
}).hourCycle; // 'h24' |
That some of the parameters can’t be set from the locale was a deliberate design choice in the first edition of the specification. From my introduction to the API:
|
oh, good to know ! So, this is just a revisit of the same area after 4 years I guess. From the intro:
I guess that my point is that there seem to be more parameters that belong to the third group. Examples:
The only one that seems to clearly fall into the 2nd category (extension keys that shouldn't affect the API) is So, in the light of your comment, my updated proposal would be to do what I listed above minus What do you think @NorbertLindenberg ? |
I'm obviously interested to know @NorbertLindenberg's ideas about the above comment, but FWIW I support the goal of this issue, i.e., I believe that having an improved consistency between the mapping of formatter options and its correspondent locale Unicode keys is a good thing (as proposed above). |
Thanks, @NorbertLindenberg, for chiming in. I meant to say what you said, but haven't managed to. As @zbraniecki wrote, 'cu' clearly belongs to the 2nd category. I have a bit of reservation about 'timeZone' as well. And, overall, I also support the goal of this issue. |
As a general comment, I’d be cautious about adding parameters just for consistency. Everything you add to the API has a cost in terms of specification, conformance test suite, multiple implementations, multiple implementation test suites, and long-term maintenance of all of them. Without actual use cases that could be a high cost with no return. On @zbraniecki's specific examples:
|
I understand. Let's break down my proposed changes:
I believe there's a major value in supporting this extension key, since it's an elegant way to provide us an ability to use proposed
This is not necessary, but I believe it's better to aim for an API that is less confusing if we can, and there's an easy path forward to add
We currently support providing timezone as an option and we also look up the timezone in the host system, but if the locale string has it specified, we ignore this setting. If we make progress with let loc = new Intl.Locale('pl', {
timeZone: 'PST'
});
loc.toString(); // pl-u-tz-pst
let loc2 = new Intl.Locale('pl-u-tz-pst');
loc2.timeZone; // 'PST'
// or:
navigator.locales = ['pl-u-tz-pst', 'en-US-u-tz-pst'];
date.toLocaleString(navigator.locales); I understand your perspective, but I don't think there there will be a scenario where the locale string passed to the API will have
I think it's worth to add it now.
I believe that there are use cases where app author knows he wants to provide
Yeah, not supper attached to it I guess. I don't see any use case. Feedback? |
EDIT: Rereading this thread, I don't think the first paragraph made much sense, given the prior discussion from @NorbertLindenberg and @jungshik , and the second paragraph might be solved another way. |
I wrote the proposal for adding hourCycle to DateTimeFormat: https://github.com/zbraniecki/proposal-ecma402-hourcycle @caridy , @littledan - there seems to be an initial consensus on adding this feature. I'd like to propose it for Stage 1 or 2, depending on if there are any concerns. |
This proposal looks good to me. I appreciate the attention to detail here, including using |
current coverage of options and extension keys - https://docs.google.com/spreadsheets/d/1UoJap3c4Bqi6GCiT2CrG12-8-IFrxXFs9F25yKHcqrc/edit?usp=sharing I started by collecting it via a script - https://github.com/zbraniecki/ecma402-compare-options-and-extkeys but @littledan suggested that we should also look into the sources and try to see if there's more than this test covers. |
We informed the committee about the proposal for At the same time, we agreed to give implementers time to react to the proposal, so we'll wait the next 2 months and if there will not be any more feedback, we'll merge it into the spec. |
Committee also requested that we document the pattern used here for the deprecation/replacement for the future. |
@juandopazo - are you still interested in leading the hourCycle PR effort? |
I don't think this should be closed yet @caridy - we only added hc :) |
fair enough. |
This patch allows calendar and numberingSystem to be specified in the options bag of the DateTimeFormat and NumberFormat constructors. One use case for these options would be, when working with locales which have two numbering systems and calendars in use--the UA default may be the non-Western one, but in some contexts, it may be appropriate to use the Western one. Currently, without the patch, it would be necessary to parse the BCP 47 language tag in the application, but Intl provides no library to do so. For example, this all occurs in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1370086 Related bug: tc39#105 . This patch leaves out "collation" because of a lack of clear use cases.
From discussion at tc39/ecma402#105 , it seems that we don't have agreement to add these extension keys to locales. We can keep considering that option for the future, but for now, removing them from Intl.Locale.
This patch allows calendar and numberingSystem to be specified in the options bag of the DateTimeFormat and NumberFormat constructors. One use case for these options would be, when working with locales which have two numbering systems and calendars in use--the UA default may be the non-Western one, but in some contexts, it may be appropriate to use the Western one. Currently, without the patch, it would be necessary to parse the BCP 47 language tag in the application, but Intl provides no library to do so. For example, this all occurs in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1370086 This patch validates the calendar and numbering system by comparing them to the grammar allowed for Unicode extension tags, per the resolution documented at tc39#175 (comment) Related bug: tc39#105 . This patch leaves out "collation" because of a lack of clear use cases.
This patch allows calendar and numberingSystem to be specified in the options bag of the DateTimeFormat and NumberFormat constructors. One use case for these options would be, when working with locales which have two numbering systems and calendars in use--the UA default may be the non-Western one, but in some contexts, it may be appropriate to use the Western one. Currently, without the patch, it would be necessary to parse the BCP 47 language tag in the application, but Intl provides no library to do so. For example, this all occurs in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1370086 This patch validates the calendar and numbering system by comparing them to the grammar allowed for Unicode extension tags, per the resolution documented at tc39#175 (comment) Related bug: tc39#105 . This patch leaves out "collation" because of a lack of clear use cases.
@zbraniecki Where exactly do we stand on this issue? Do we still have any APIs that pivot based on locale extension keywords but don't have a corresponding option in the options bag? |
@sffc Yes, we do, for example we decided not to add the collation option. @NorbertLindenberg 's feedback in this thread. |
I synced with @NorbertLindenberg on this topic at IUC last October. The use case for having options able to be specified in the options bag rather than only in the locale string is that these user preferences often come from application settings. I'm a big advocate for using the locale string to hold the user preferences, but I also don't see harm in letting them be passed in on a case-by-case basis across the board. |
@sffc I don't really see the harm either. From your conversation, did you establish that @NorbertLindenberg no longer holds his previous concerns? |
I haven’t paid much attention to ECMA-402 in recent years, so please ignore whether I do or don’t hold my previous concerns. Instead, I’d suggest that you evaluate based on your knowledge of the current goals and constraints for ECMA-402, which differ in some ways from those for 1.0, which, if any, of the old concerns still apply, and proceed based on that evaluation. |
@FrankYFTang volunteer to work on this issue. |
Related: #380 |
It seems this issue is fixed. |
This is the first part of the spin-off from #68.
Currently, there are two ways of providing parameters into Intl APIs: via extension keys on locale tag and via
options
.There is also one way to test which values has been assigned to the options:
resolvedOptions
.The issue is that the list of extension keys only partially overlap with the list of options. Sometimes there is an option, but we ignore the available extension key, sometimes we don't have an option and only accept the param via extension key, sometimes we allow both.
In general, my recommendation is to get to the point where all params that are available through extension keys were also available through options, and options would take precedence.
Here's the break out per API:
Collator
This one is the simplest. We already allow for
kn
andkf
and their counterparts in options. The only missing option iscollation
.NumberFormat
Here we have extension keys supporting
nu
but notcu
and options that support the reverse.Adding
cu
to extension keys andnumberingSystem
to options gives us complete coverage.DateTimeFormat
Here's the most complex situation.
We don't support an extension key
hc
(hourCycle) which can take one of four values (h12, h11, h23, h24)[0] and instead we use a booleanhour12
option.I suggest that we add
hourCycle
option andhc
to extension keys and optionally deprecatehour12
.On top of that, we should add
tz
to relevant extension keys, and addcalendar
andnumberingSystem
tooptions
.[0] http://www.unicode.org/reports/tr35/#Locale_Extension_Key_and_Type_Data
The text was updated successfully, but these errors were encountered: