messageformat.net

messageformat.net copied to clipboard

We encountered an incompatibillity with messageformat.js. When you use a boolean für a select, then messageformat.js converts it to true/false for the key, but messageformat.net converts it to True/False.

I think lowercase true/false is the better option an it should be fixed here. (Maybe an option should be introduced, then it could be fixed while maintaining backwards compatibility.)

Thats a .NET thing 😀 what does the spec say?

http://userguide.icu-project.org/formatparse/messages: Use a "select" argument to select sub-messages via a fixed set of keywords.

Sounds like only strings should be used. But as your readme states compatibility with messageformat.js, I think booleans should be allowed and converted to lowercase.

But as your readme states compatibility with messageformat.js, I think booleans should be allowed and converted to lowercase.

I state somewhat compatibility. 😉

If the spec does not dictate how booleans should be treated, then it is up to the underlying platform to provide stringification. JS uses lowercase, .NET uses pascal case. I think we should stick with that, as doing myBool.ToString().ToLowercase() isn't that big of a deal in userland code. 😄

If you feel strongly that this should be addressed specifically by this library, please submit an API proposal (and even better, a Pull Request! It is Hacktober after all 😉 )

I would suggest an option to provide a type-converter to the message formatter, so anyone could provide their own approach/implementation for this. It would not only be useful with select (to convert to string from any value type), but also e.g. when you have a number value placeholder (e.g. { x, number }, { x, plural, ... } or { x, selectordinal, ... }) and the value provided is not a number, the type-converter would be used (to convert to number). Similarly for a date/time placeholder (e.g. when a date is provided in a string in a weird/custom format or using a custom class).

What would the API for that look like @hilari0n ?

@glen-84 do you have an opinion on this?

PHP (8.2.1) also seems to use a string conversion/cast, so boolean true actually matches 1. Boolean false is an empty string, so it probably can't even be matched.

In that sense, this library is consistent. However, I'm not sure if there is a proper specification for MessageFormat 1.0. It might also be worth checking the Java and/or C(++) implementations. If they also use some form of string conversion, then I don't think that the default behaviour of this library should change.

As you've mentioned, if the user wants to use true/false keys, then they can pass in a true/false string instead of a boolean.

Custom type converters (or similar) would be a separate feature request.

If anything, we could extend the new CustomValueFormatter to include a TryFormatDefault which can be called when formatting {simple} values without a format or style.

Will close this issue for now. Thanks!