best effort internationalization

[icambron]

Replacement for #86. Because I'm like, all kinds of American, I don't actually know if these changes are right. Specifically, I'd love for someone to tell me if these would be right for your non-American locale (assuming "May" got translated and capitalized in a locally-appropriate way):

• 25 - 26 May 1982
• 25 May 1982, 0:00 - 1:00
• 25 May, 0:00 - 26 May, 1:00 1982

If so, I'll merge it and call it day. If not, I may do that anyway.

This probably won't fix Twix for all languages because it's conceptually kinda wrong. It should parse the format and use that to build the collapsing rules, but last time I tried to do that, it didn't work so well. So this is a compromise between doing it right and not doing it at all.

[coveralls]

Coverage increased (+0.02%) to 97.662% when pulling 6df4a714cdda211a2e18e18040a9919b0889f571 on intl into 03b055d47cd02505b88730525ae03ee42e2d0135 on master.

[jymbob]

In the UK I would expect:

0:00 - 1:00 26 May 1982 26 - 28 May 1982 28 May - 2 June 1982 0:00 25 May - 1:00 26 May 1982

Will try to find a citation

[icambron]

@jymbob Moment's locale functions agree about the comma's absence but not about the time going before the date:

> moment().locale("en-gb").format("LLL")
'4 July 2016 12:52'

Chrome's built-in CLDR support seems to agree with me:

> new Intl.DateTimeFormat('en-GB', {year: 'numeric', month: 'long', day: 'numeric', hour: 'numeric', minute: 'numeric' }).format(new Date());
"4 July 2016, 13:00"

But that's all I know; I could easily be convinced that's wrong.

[jymbob]

@icambron Having searched extensively, I can't find any hard documentation on whether time is generally before or after the date.

I think my expectation for time before date comes from trying to keep the little-endianness of en-gb dates consistent (i.e. finest detail first), whilst acknowledging that no-one wants SS:MM:HH DD-MM-YYYY

Most conventions seem to land back at rules regarding spoken English. In the UK it's much more common to say "The tenth of August" than "August tenth" (more common in the US). However when identifying a point in time, I'd have a hard time convincing anyone that "Two pm on the tenth of August" is more common than "The tenth of August at two pm".

For time spans, on the other hand, I have a strong preference for "From two 'til four pm on the tenth of August" over "The tenth of August from two 'til four pm". This expands naturally to "From two pm on the tenth of August 'til four pm on the eleventh of August".

As with anything British, it's changed so many times over the centuries that no-one really has firm rules. That's the problem with evolving language and culture.

I expect it's easier to be consistent across as many of these as possible, hence my previous comment regarding time first.

[celalo]

Any plans about when to merge this?

[icambron]

I mean, the only piece of feedback I've gotten so far is "this doesn't seem right for my locale" so it's a bit hard for me to say "yup, this is good to go".

[murraybauer]

hi @icambron many thanks for maintaining this library.

I'm not an expert but Wikipedia defines three general date formats - YMD, DMY, MDY for each country - some varies per sub-region.

Your americanish looks version good, but only covers MDY (default en-US locale) and DMY (en-GB locale in your tests) - not the YDM case.

Perhaps rather than americanish the following labels could be usedYMD, DMY, MDY

I think you are on the right tack with logic like the below which is based off the moment locale settings: americanish = localFormat.indexOf('M') < localFormat.indexOf('D')

I suspect for sub-regions within countries that have different YMD, DMY, MDY formats would have a different locale. If in doubt an optional paramater specifying either `YMD, DMY, MDY could be provided.

Not sure how hard it would be to do all 3, otherwise you could release support for the 2 modes now (which covers my DMY case). Keen to get a solution. Thoughts?

[icambron]

Yeah, I'm just gonna merge this. Notes:

• Anyone who needs YMD can write me a PR.
• I can't think of a good solution to @jymbob's concerns re: time placement. In any case, I don't think the behavior in this PR is worse for Brits, so it's not really a reason not to merge it.

[murraybauer]

@icambron perfect thanks. Noticed the NPM package is still at v1.1.5, not v1.20 which has these changes. Are you able to update so I can try test it out?

[icambron]

@murraybauer Yeah, as usual I forgot a step. Published

[jymbob]

Thanks for the merge. As you say, it's a definite improvement, even for picky Brits like me!

[murraybauer]

@icambron both modes worked in my tests. thanks