You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should write down what clients should do with extension keywords in non-fallback mode (preresolved or hybrid).
Currently, if a user requests ar-EG-u-nu-latn from the FixedDecimalFormatter, it will succeed. However, if they request en-US-u-nu-latn, it will fail, because there is no explicit data for that extension. Likewise, ar-EG-u-xx-yyyy will fail if xx is an irrelevant extension keyword from the constructor.
Also, if constructing a DateTimeFormatter, ar-EG-u-nu-latn will fail, even though FixedDecimalFormatter is one of the component parts. (We should probably add DTF::try_new_with_fixed_decimal_formatter to work around this)
We could:
Document this behavior and leave it as-is
Make constructors for extension-sensitive keys have some extra logic for extension handling, outside of data provider
Make all constructors have extra logic for extension handling, outside of data provider
I lean toward (1).
The text was updated successfully, but these errors were encountered:
We should write down what clients should do with extension keywords in non-fallback mode (preresolved or hybrid).
Currently, if a user requests
ar-EG-u-nu-latn
from the FixedDecimalFormatter, it will succeed. However, if they requesten-US-u-nu-latn
, it will fail, because there is no explicit data for that extension. Likewise,ar-EG-u-xx-yyyy
will fail ifxx
is an irrelevant extension keyword from the constructor.Also, if constructing a DateTimeFormatter,
ar-EG-u-nu-latn
will fail, even though FixedDecimalFormatter is one of the component parts. (We should probably addDTF::try_new_with_fixed_decimal_formatter
to work around this)We could:
I lean toward (1).
The text was updated successfully, but these errors were encountered: