[HN Gopher] Intl
___________________________________________________________________
Intl
Author : evo_9
Score : 121 points
Date : 2021-06-01 16:57 UTC (6 hours ago)
(HTM) web link (developer.mozilla.org)
(TXT) w3m dump (developer.mozilla.org)
| skeletal88 wrote:
| 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.
| lhorie wrote:
| 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.
| evangow wrote:
| 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...)
| yuchi wrote:
| 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.
| mstijak wrote:
| 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.
| benatkin wrote:
| I would like to see a Deno column on the Browser Compatibility
| table. I see Node.js has one.
| mark_and_sweep wrote:
| Deno is still quite a young project. I'm sure it will be added
| in the future.
| earthboundkid wrote:
| 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.
| ravenstine wrote:
| Yet Opera still gets a column, despite how no one should be
| using it under any circumstance.
| Macha wrote:
| 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.
| [deleted]
| simon04 wrote:
| Here's the corresponding GitHub issue:
| https://github.com/mdn/browser-compat-data/issues/5476
| tkzed49 wrote:
| 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
| johnzim wrote:
| 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.
| colonelpopcorn wrote:
| 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...
| heinrich5991 wrote:
| Most stuff can be polyfilled. Is this not one of these?
| fiddlerwoaroof wrote:
| The locale data for the polyfills can add a lot to bundle
| size.
| skrebbel wrote:
| 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.
| afavour wrote:
| 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.
| fiddlerwoaroof wrote:
| 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.
| stephenhuey wrote:
| Just stumbled upon it a few weeks ago and just in time for
| handling some stuff in my current project!
| lhorie wrote:
| 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.
___________________________________________________________________
(page generated 2021-06-01 23:00 UTC)