Implement missing internationalization related methods

[jedel1043]

Probably follows from #1180.

This is the list of methods we are currently missing from builtin objects because we don't have an internationalization API yet:

String

• [x] String.prototype.localeCompare()
• [x] String.prototype.toLocaleLowerCase()
• [x] String.prototype.toLocaleUpperCase()

Date

• [ ] Date.prototype.toLocaleDateString()
• [ ] Date.prototype.toLocaleTimeString()

General

• [ ] ***.prototype.toLocaleString()

Please comment or edit this issue if you find any other method that depends on internationalization.

[davimiku]

Would this also cover the Intl global object and its constructors?

[jedel1043]

Would this also cover the Intl global object and its constructors?

Not really. That would be it's own issue, I think.

[NorbertGarfield]

@jedel1043 I would like to clarify several things about Date.prototype.toLocaleDateString()

1. Is anybody working to implement this method right now?
2. Would you mind if I decompose the implementation into several pull requests for sub-tasks like "implement toDateTimeOptions()", "implement BestAvailableLocale()", etc.?
3. I have found several approaches to get default locale: sys-locale, locale_config, rust_icu to name a few. Which one would you recommend? Or is it better to postpone the actual implementation of "DefaultLocale()" and return some placeholder locale (e.g. "en-US") instead?

[Razican]

Hi @NorbertGarfield, nobody is working on this right now as far as I can tell, so feel free to work on it. You can of course decompose the implementation in several pull requests :)

I think the idea here was to use ICU4X to do all this: #1180 About the default locale, you can start by hardcoding a default locale. At some point, we will probably want to leave this to Boa implementers, so that by default we use the system locale in one of those crates, but we let the crate user set a Rust callback to retrieve the locale as they wish.