Intl | Hacker News Reader

Intl

developer.mozilla.org

281 pointsevo_968 comments

Hi all!

I've been working on ECMA-402 for the last 6 years on behalf of Mozilla. I'm excited to see it showcased on HN! We have an amazing, inclusive and open community of engineers, linguists and standardization exports from all of the World from largest corporations to smallest non profits and maintainers of open source little libraries.

If you'd like to see what we're working on, see https://github.com/tc39/proposals/blob/master/ecma402/README...

If you'd like to join us, please check out https://github.com/tc39/ecma402/blob/master/CONTRIBUTING.md

Our biggest challenge now is to make sure that anyone can use ECMA-402 - either with a well supported JS engine (V8, SpiderMonkey, JSShell etc.) or via library. To achieve that we're working on Rust project called ICU4X which aims to be able to back ECMA-402 in web browsers, on servers, in client solutions and offer FFI to many programming languages including to JS over WASM.

If you'd like to help us with that, there's tons of work and we're very eager to grow our community! Check out https://github.com/unicode-org/icu4x/blob/main/CONTRIBUTING.... and https://github.com/unicode-org/icu4x/tree/main/docs

If you have any questions, AMA!

Something to be aware is that there is a subtle difference between supporting the APIs and supporting appropriate data sets.

Specifically, the table lists Node 12 as supporting Intl, but critically, Node 12 defaults to being built with the `small-icu` dataset. This is not actually sufficient if, for example, you want to correctly format brazilian currency (among many other use cases). For that you want the `full-icu` data set, which can be configured via a env var. Node 14+, however, does thankfully come w/ full-icu by default.

This is also something to be aware also if you're looking at custom size-optimized docker images, since skimping on ICU is a "low-hanging" size optimization.

Related. I can't wait for [Temporal](https://github.com/tc39/proposal-temporal) - which hit Stage 3 a few months ago - to bring sanity to time in the browser. Combined with Intl, it will be much easier to build universal calendaring.

I think the major thing that will take time behind getting Temporal to Stage 4 is aligning with IETF on [a draft update RFC 3339](https://github.com/ryzokuken/draft-ryzokuken-datetime-extend...)

I recently rewrote a very complex, 600-ish lines, legacy date mangling algorithm from moment to the Temporal poly fill and was a breeze to use.

If you have some experience with Luxon or similar immutable date/time data types then you’ll get to use Temporal in no time. The API is incredibly ergonomic and apparently useless things (such as YearMonth) become so useful for even simpler cases.

> [...] apparently useless things (such as YearMonth) become so useful for even simpler cases.

That piqued my interest. In my opinion partial date components are only useful for alternative calendar systems or localizations (previously: [1]), so if your use cases are not one of them I'd like to hear more about that.

[1] https://news.ycombinator.com/item?id=26284353

I don't know the specifics of this implementation, but if YearMonth is what it sounds like - an object representing a specific month in a specific year and nothing more granular than that, then I'm all for it. Some examples of where I've used such constructs in the past (often having to hackily implement them myself on top of native datetime libs):

- data processing and graphing: a lot of data is collected on a monthly basis and represents the aggregate for that month (like monthly energy use). Naively storing it as a full date and ignoring the day means that you now have a compatibility issue with other data, collected monthly, that isn't aggregate (like the height of a tree) - "[THING] of the month": something is chosen by a community poll or admin or however else to be highlighted for/of that month You need something to use as a key for it and a YearMonth captures the requirements perfectly. Especially when you then have to display a localised title above it, having it be a distinct class and not just a full date will save you a lot of trouble. - same as above, but a more business-y use case: various monthly reports. Usually created in the next month, you need a way to represent which month it's "for"

I should clarify that my dislike of YearMonth and ilks is for standard types without any localization [1] or non-Gregorian support. They do crop up from time to time but you have a very straightforward representation of YearMonth in any reasonable language: a pair of (year, month), essentially interpreted as a mixed-radix number. Date and general date-time components are not that simple (thanks to the calendar system itself, leap seconds and time zones) and deserves separate types.

[1] I firmly believe that the localization support is too large for standard libraries. In particular, that "localization support" usually means that you have a ripoff version of CLDR & ICU interface and no equivalent to something like gettext, essential to any actual localization task.

More devs should know about Intl - it's a great resource for a HUGE number of tasks as well as being a great way to smooth localization. I only became fully aware of it in the last 12 months, so I'd wager there's a lot of other devs who've missed out.

One helping hand is that libraries like date-fns (http://date-fns.org) use it liberally under the hood.

I know about it, but I can't use it because it isn't supported in Internet Explorer 11:

https://caniuse.com/?search=Intl

Hopefully, more people will follow suit and ban IE11 when O365 no longer supports it: https://docs.microsoft.com/en-us/lifecycle/announcements/int...

Most stuff can be polyfilled. Is this not one of these?

The locale data for the polyfills can add a lot to bundle size.

Well, you either need to format dates or you don't. The idea that you won't use Intl because the IE11 polyfill adds to much to your bundle size is a bit of a head scratcher.

The issue is whether it’s worth spending that bundle size on an obsolete browser. If not, it could be reasonable to do some naive formatting on IE11 and show a message mentioning that the browser is unsupported and things may render incorrectly.

Your IE11 polyfills don't have to be in the same bundle as everything else.

https://cdn.polyfill.io/v3/url-builder/ is pretty great for this, it'll detect the browser user agent and send down the right polyfill. Ie on modern browsers it'll send down an empty response.

Well, great sometimes. Not great if you don't trust a random 3rd party to host essential client-side code for you or if you don't feel like running yet another, maybe unsupported in the future, service for the next X years.

You can always self-host it: https://github.com/financial-times/polyfill-service

True. We have an "if IE then emit polyfill.io <script> tag" call in the backend, which limits the security surface area to IE and also prevents an otherwise unnecessary extra HTTP request (we only use it for Intl). We feel that's a reasonable middle ground.

If I'd use it for all polyfills (which we should maybe consider!), we'd likely self-host the service.

I'm one of the leaders of the ICU4X project which is a Rust implementation of ECMA-402 aiming to back client-side solutions.

We hope to eventually back SpiderMonkey (Firefox JS engine) implementation with it, but we also want to target WASM and in result expose it as a polyfill for any browser to use.

I don't know if by the time ICU4X is 1.0 IE11 will still matter, but it may be possible to compile it to asm.js and run in IE11 maybe?

Just stumbled upon it a few weeks ago and just in time for handling some stuff in my current project!

date-fns actually barely uses Intl. Rather, it has custom locale files that must be imported to use: https://date-fns.org/v2.22.1/docs/I18n. There is a single intlFormat function: https://date-fns.org/v2.22.1/docs/intlFormat

Once I realized this I switched to Luxon, which is entirely Intl based: https://moment.github.io/luxon/docs/manual/intl.html

Good to know about, but the really great contribution that Mozilla has made to localization is in Project Fluent (https://projectfluent.org/) which enables sophisticated translation with asymmetric localization, progressive enhancement, and other features critical to high quality localization. If you are just swapping in some strings then the usual combination of gettext and Intl are probably fine, but high quality localization often requires more than that.

Not sure why you're mentioning Mozilla here, the only thing in common with the submission is that it happens to be hosted under mozilla.org. The ECMAScript Internationalization API seems to have been written and contributed to by mostly non-mozillians, none of the contributors listed at https://webplatform.github.io/docs/apis/internationalization... are related to Mozilla as far as I can tell.

Project Fluent is a great recommendation though, haven't seen before but looks really useful.

The list your linked is from 2012. In the last 9 years ECMA-402 has been heavily influenced by Mozilla's projects like Firefox OS and MozIntl APIs. :)

Ah, I see... :-T

Yeah, I guess the specification was finalized in 2012? The specification itself has the same list of contributors: https://402.ecma-international.org/ecma-402/1.0/ECMA-402.pdf

Unless the specification has been rewritten under another name, I'm not sure why the date matters? The specification was mostly written by non-mozillians and I still don't quite get the point from m0llusk. Firefox OS and MozIntl APIs is not mentioned nor linked in the submission either. Maybe I'm just missing both of your points entirely, if so, I'm sorry.

Fair question, thanks for asking!

There have been 9 revisions of ECMA-402 since 2012. We are, in fact, following TC-39 on a yearly cadence of releases.

You can see the history of editions here: https://www.ecma-international.org/publications-and-standard...

The first edition (finished in 2012), had just NumberFormat, Collator and basic DateTimeFormat.

Since then, we added Locale, PluralRules, ListFormat, RelativeTimeFormat, DisplayNames, two new revisions of NumberFormat, two major additions to DateTimeFormat, and we're now adding Segmenter, LocaleInfo, CalendarInfo and working on MessageFormat 2.0.

Here's a very incomplete list of finished proposals that have been merged into the standard and implemented in browsers - https://github.com/tc39/proposals/blob/master/ecma402/finish...

I may or may not be involved in majority of them! :)

Thank you a lot for clarifying and educating! Also thanks to your contributions, you've definitely made the web a better place :)

> If you are just swapping in some strings

Besides currency, date/time, numeric separators, and unit selection/conversion, that's all that's usually necessary (assuming the app's strings are translated).

I think “swapping in some strings” sounds deceptively simple. You need the strings to be designed with localisability in mind. In particular there may be several variants of the same string in one language, but just one in another, depending on factors such as number or gender…

An app I was working on was translated into 5 or 6 languages, and I never saw differing variants in any of those languages.

Sounds like they were all Western European languages.

One of the downsides of Intl is that there is no way to change the formatting in any sensible way. Our client wanted the date names to be localized to the UK time and date format, but use "-" instead of spaces between date parts. There was no way to do that using Intl, other than replacing spaces with dashes... Or deconstructing the date into parts and composing it into a string by ourselves, but if we have to do that then why use Intl? So we used dayjs for that.

It would be ideal to be able to use localized short and long month names, but be able to format the date and time as required.

Or there should be some other standard library/tool to format dates and times, because the JS ecosystem is a mess. Python is great in that way, that it includes everything needed, and you don't have to reinvent the wheel constantly, or try to find which random library does reinventing the best.

Right, that's because Intl isn't a formatting API, it's an internationalization one. There are expectations in the UK about which order month and day are supposed to appear in a date string, and they differ from the order adopted by various other localizations. For example `01/02/2021` and `1.000` mean very different things in certain parts of the world than they do in the en locale. Matching these types of local expectations given a locale is what Intl is for. It sounds like your client just wants a custom arbitrary format, in which case dayjs is a fine choice.

Wanting to replace space (" ") with dashes ("-") or slashes ("/") is not an outrageous request. People will understand 2020/02/02 as easily as 2020-02-02 or 2020 02 02. Offering an easy way to replace that character would not have been too hard, instead we're stuck with string replacement or regex to achieve a fairly common operation when it comes to dates.

Why is using string replacement to, well, replace spaces with dashes if one wants a non-standard string format an outrageous request then? Personally, I've been bitten time and time again by non-standard, hard-coded strftime formats. Either show a localized time and let my system decide the format, or use ISO 8601/RFC 3339. If one must have full control over the format, the Date object exposes getters for each component.

Unfortunately, dates can be deceptively messy. Formatting as 2021-01-02 instead of 2021/01/02 may not seem like a big deal, until you try to parse them back. Then this happens:

    const a = new Date("2021/01/02"); // Sat Jan 02 2021 00:00:00 GMT-0800 (Pacific Standard Time)
    const b = new Date("2021-01-02"); // Fri Jan 01 2021 16:00:00 GMT-0800 (Pacific Standard Time)

Date library authors have been bit hard because date parsing is hard, and they thought it would be easier to let the Date constructor do the job... only to find out via bug reports about the nasty obscurities of the date parsing rabbit hole.

That second example is particularly ugly. It assumes the input is UTC, then it quietly converts that Date to your local time zone.

Proper date input usually requires a widget.

The context of the conversation is showing dates, not parsing dates. Obviously I'm not advocating in changing your data model to something that would be harder to parse, I'm advocating providing APIs for easier show the date in a format that you want it to show as.

Yes, as a software person, I understand that. I brought this up because we were veering into "client asked" territory, and that where we see clashes between seemingly innocent real world asks and technology rabbit holes.

> For example `01/02/2021` and `1.000` mean very different things in certain parts of the world than they do in the en locale.

The date means different things between the various English locales. In most of them, it means 1st February. In the USA, January 2nd.

Unfortunately, the very unusual US format is the default locale in many systems.

Can't you use formatToParts() to get most of the way there?

We have been talking about this problem a bit. The tension here is that UX mocks a particular locale as "pixel perfect" and doesn't really "care" about how it'll i18n into other locales.

So they want "do the right thing" for 103 out of 104 locales, but "do what I told you" for "MY" locale.

This is a bit of a conundrum because we don't want to treat any locale as "special". To translate it to code you'd write something like:

  if (currentLocale == "THE_ONE_UX_CREATED_MOCKS_FOR") {
    let value = formatToUXProvidedPattern(data);
  } else {
    let value = data.toLocaleString(currentLocale);
  }

I don't have a great answer how to approach it since there are severe drawbacks and risks to all known potential approaches to "squeeze just one particular format that UX provided into i18n database", but I just wanted to say that we're aware that Intl API has the clash with the UX-driven-development.

I think the problem is that design teams don't bake in internationalization when it is not explicitly asked for. It used to be the same thing for responsive pages.

Design tools are also severely lacking here. Even modern tools like Figma have no way to manage copy well (e.g. swap out copy for different "sets" of strings to test the design with variable-length translations). Heck, you can't even use the spell checker or Grammarly on text boxes or comments despite it being a browser-based app.

It's still in early stages, but I'm excited for Intl.Segmenter[0], which will let you do locale-aware text segmentation. Maybe not useful for a typical webpage, but probably has some cool niche applications.

[0] https://github.com/tc39/proposal-intl-segmenter

Thanks! If you'd like to help we just merged Segmenter API into ICU4X with an intention to back the ECMA-402 Segmenter API! See https://github.com/unicode-org/icu4x/pull/717

We could definitely use some help :)

Intl is great for formatting dates, but parsing of culture-specific dates (and numbers) can be tricky. I wrote a small library that helps with that - https://github.com/codaxy/intl-io.

I18n parsing is indeed hell. I'm very very reluctant to try to add it to ECMA-402 for that particular reason.

Thank you for writing a user land library for it. It's a thankless task and a very important one and I think such a complex problem deserves a userland solution!

I'm glad we're getting further and further down all this, just waiting patiently for a `strftime` that gives better control over formatting.

Especially given that everyone and their dog was using moment.js for the longest time, it's always a bit surprised me that spec improvements didn't try to get more coverage for the "generalzied formatting" stuff. Maybe this stuff is all just calling OS internals

`strftime` is not an internationalization API! It's a datetime formatting API! :)

I can see an appeal for it, and I wouldn't mind `Date` or `Temporal` to have such pattern-driven formatting, but it is critical to recognize that it is not internationalization and thus doesn't belong there.

In particular, if you use `strftime` like formatting you're doing the opposite - you're hardcoding the formatting into a single pattern. It may be the right thing for your project, but it definitely is not i18n :)

In practice, though, to implement Intl you pretty much need a robust implementation of a strftime-like date formatting function, as well as a full set of month/weekday/etc strings for every language you support. So it's less "add this functionality" and more "expose the functionality this clearly already has".

You're correct. Intl formatting has two components: - Selecting the appropriate pattern for a given locale - Formatting numbers and words into the given locale (example: eastern-arabic numerals and Arabic month/week names).

You might say "I want to supply my own pattern, you just do step two for me" and technically we can provide that functionality by exposing it.

The issue is that from the API design perspective it would lead to people misusing the API misunderstanding what is going on and believing that they "internationalized their UI" which is not the case. In fact, they'd make things worse for their users than if they just displayed a date in a single locale with consistent pattern+localization because in some cases "MM/DD" and "DD/MM" are indistinguishable when expanded and that may lead to data loss, security loss, or just confusion.

I'd argue that every case where you want to supply your own pattern is a case where you should not attempt to internationalize that pattern. I also recognize that it's just my opinion.

I would like to see a Deno column on the Browser Compatibility table. I see Node.js has one.

Yet Opera still gets a column, despite how no one should be using it under any circumstance.

Yeah, Opera gets grandfathered in from the days when the dominant browsers were IE, Firefox and Opera (later joined by Safari and later still by Chrome). It's hard to see them getting listed based on modern market share. Obviously it's a bit harder to tell from e.g. user agent statistics when Chrome, Edge, Brave, Opera, Vivaldi etc. are all basically Chrome, but I would expect Brave to have more users than Opera at this point. And if Brave doesn't qualify because they don't have their own browser engine, well neither does Opera any more.

Deno is still quite a young project. I'm sure it will be added in the future.

Especially considering that Node has exactly zero interest in compatibility with the web (search for "node atob" if you don't believe me), whereas Deno does, I think Deno should be listed.

Here's the corresponding GitHub issue: https://github.com/mdn/browser-compat-data/issues/5476

Are there any libraries that do string comparison for unicode characters that look alike?

There is ICU Normalization which supports different "Normalization Forms". After two strings, which differ only in a look-alike character, are both normalized according to the same form, they (might/should, depending on the form) compare as equal.

https://unicode-org.github.io/icu/userguide/transforms/norma...

https://www.unicode.org/reports/tr15/

Thanks. That was the missing term making my search results turn up nothing.

We should be getting rid of locales, not putting them into more things.

The place where I live shouldn't define the way numbers or dates are presented to me, or the measurement units I use. That's what international standards are for.

No person is wanting "standard" for date, which are the yyyy/mm/dd. Only dd/mm/yyyy or mm/dd/yyyy. I am agreeing for a setting is better comparing with locale. We are needing a default for a person, though, this is the locale purpose.

Uhhh I'm a person and I use YYYY/MM/DD and DD Mon YYYY (1 Jun 2021). I worked in a chemical lab for a while with a fairly international group of chemists, and those were the two preferred timestamp formats.

YYYY-MM-DD is actually the standard date format in a few countries, such as Sweden.

> We should be getting rid of locales,

You are welcome to try to convince everyone to use the same language and conventions, go ahead.

In the meantime, the rest of us need tools to deal with the world as it is.

Or just move to a place where the locale matches your taste.

Reply on news.ycombinator.com