Please fix Russian locale months abbreviations

[uvizhe]

It now goes as: янв. февр. мар. апр. мая июня июля авг. сент. окт. нояб. дек.
which is correct abbreviation in written language, but de facto is an odd way to abbreviate months in computing/engineering area.

If you look at Python and C you find standard abbreviations to be янв фев мар апр мая июн июл авг сен окт ноя дек
which primary purpose is to fit a fixed length string (MMM).

I can make a PR if you approve the change.

[uvizhe]

Looking at tests I see that the issue is broader than just months abbreviation.
@socketpair, are you willing to discuss if we should adopt a de facto standard for printed short dates (as per C and Python), or have to stick to a language norm?

I think that language norm stems from a corpus of written texts, while programming usually deals with and produces an output text which is a different substance. The purpose of printed short dates is to fit in tight space, preferably fixed length.
It has nothing to do with abbreviations in written text, it hardly affects writing rules, and it shouldn't be affected by them.

[socketpair]

Ideally, different specificator should exist. Fixed width abbreviations are for terminals only, right ? Terminals have some obvious restrictions. So, user of Momentjs should be able to choose between fixed formatting and natural.

I don't have statistics, but I seem Momentjs is mostly used in web.

Also. I dislike the standard (GOST) where they choose such a stupid forms (especially with dot), but in order not to be a Microsoft, we have to stick to the standards.

Yep, I'm ready to discuss.

[uvizhe]

Great!

Fixed length abbreviations are not just for terminals, it's for engineering in general. Think of spreadsheets, timetables at airports, small screen displays which one can find nearly everywhere from fitness trackers to printers, from IoT devices to subway cars. This is where software output is usually being used.

On the other hand there are rules for written text (GOST and language norm), which main purpose is to guide writers of an official documentation, e.g., bills, contracts, dissertations and other scientific literature. It's clearly don't rely on automatic date abbreviation that much.

So, I think we need to comply with other software. It's about both compatibility and a predictability (even MS Excel in this camp).

By the way, we already defy language norm when it comes to week days. Their abbreviations have to be appended with a period the same as months (e.g., вс. not вс).

[socketpair]

I have a new idea!
Is it OK to make two translations?

1. ru_RU with programmers-friendly translations
2. ru_RUGOST (or similar) with GOST-friendly translations

[uvizhe]

This would be a good solution, indeed. However I wonder if it's up to a maintainer to decide things like this. Because this introduces the practice of adding new non-existent locales.

[socketpair]

So, who should we ask ? Mention them here

[uvizhe]

I'd ask @marwahaha but...

On a second thought there is a clear statement in a moment.js docs that
If the string or format you are asking to change is reflected in the CLDR, then you must submit a change there first and have it accepted.

Digging into the CLDR shows that some anonymous localizers pushed to change months abbreviations from 3 letter to a current GOST form few years ago (https://unicode-org.atlassian.net/browse/CLDR-4226).

So @marwahaha, do we really have to alter CLDR first or the arguments provided here are sufficient for the change?

To @socketpair: also, regarding a ru_RUGOST quasi-locale, how are people supposed to learn about its existence?

[socketpair]

Ru_rugost: look at the list of locales ? Possibly by creating GH issue and asking ?

[marwahaha]

I'd prefer not to modify ru, but it might make sense to have a new locale. Of course, you can always make a custom locale file for your project.

[socketpair]

You know, what? I changed my attitude to this. Now, I think to swerve from standards in favour to nice looking dates. So, let's also remove point between comma in full date+time format.