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
The MessageValue should not have a locale property. That's what Parts are for.
Consider {$count :number}. The number stored in $count may be decorated with formatting options like minimumFractionDigits etc., but it's not in any particular locale just yet. It's the locale of the message (or the placeholder if we allow overriding it) that decides how $count will be formatted.
There's nothing inherently language-specific about the mathematical value of 5 :) Same goes for many string literals, like user names or Wi-Fi network names.
I understand that we need the locale somewhere for toString and toParts to work. I think we should just pass it as argument: toString(locale). Perhaps also call it toLocaleString() for consistency with other JS APIs.
Alternatively, we can consider passing in a larger structure: toString(fmtctx). Such "formatting context" may be useful if we want to allow implementations to cache formatters.
(A formatting context should be passed into formatting methods rather than be referenced by a property of MessageValue to help avoid memory leaks and facilitate IPC use-cases.)
The
MessageValue
should not have alocale
property. That's whatParts
are for.Consider
{$count :number}
. The number stored in$count
may be decorated with formatting options likeminimumFractionDigits
etc., but it's not in any particular locale just yet. It's the locale of the message (or the placeholder if we allow overriding it) that decides how$count
will be formatted.There's nothing inherently language-specific about the mathematical value of
5
:) Same goes for many string literals, like user names or Wi-Fi network names.I understand that we need the
locale
somewhere fortoString
andtoParts
to work. I think we should just pass it as argument:toString(locale)
. Perhaps also call ittoLocaleString()
for consistency with other JS APIs.Alternatively, we can consider passing in a larger structure:
toString(fmtctx)
. Such "formatting context" may be useful if we want to allow implementations to cache formatters.(A formatting context should be passed into formatting methods rather than be referenced by a property of
MessageValue
to help avoid memory leaks and facilitate IPC use-cases.)Originally posted by @stasm in #22 (comment)
The text was updated successfully, but these errors were encountered: