Month names in Russian Localization should be in lowercase

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue for you. Can you try with the latest Ubuntu release? Thanks in advance.

As Russian writing practice did not changed since first reporting, I still treat this bug is valid. We don't capitalize months names in Russian. We even don't capitalize the word Russian in Russian.

Nothing had changed in new Ubuntu (jaunty).

Sorry to hear that this is still a problem. I'd rather someone else could confirm this as well. Nevertheless, I have looked online at Russian grammar and translation documents, and I can confirm this fact of the non-capitalised words for mid-sentence words, regardless of the word itself.
Is it **just** the clock, i.e. Sun 24 May, or are other things wrong, such as documentation, other GNOME applets, the menu bar, etc. Thank you.

I comfirm this bug. Date needs to be improved in this way:

[Пн|Вт|Ср|Чт|Пт|Сб|Вс], $daynumber [января|февраля|марта|апреля|мая|июня|июля|августа|сентября|октября|ноября|декабря] $year года, $time

Is it just the date that has this problem?

As far as I understand, Ubuntu calendar widget doesn't have its own implementation of date formatting, but instead it uses something system. If it's not true please correct me. So it means we should dig deeply and try to correct it there.

Different languages have different writing traditions. In English months name are uppercased, in Russian they are not. Even more — Russian date formula requires months name to be in genitive case (differs from standard nominative).

Thank you for the update :)
Can you confirm what version of Ubuntu you are using please, and if you haven't already done so, can you try with the development release of Ubuntu (Karmic) which is now in beta - note you can try with the Live CD for this. Also, Launchpad is sometimes used for translations, it might help to try having a look at that part of Launchpad and change it as necessary for your language so it can be imported into Ubuntu for the next release if we can't get it in for this one. Thank you.

Here is the patch for the second problem.

I believe langpack-locales is more appropriate here, since definitions are coming from locales package.

Here is the patch for the first problem. diff on top of the 1st patch fixing 2nd problem.

Upon further testing... De-capitalization and using correct conjugation for non-abbreviated month titles brakes appearance of month names in other locations, where the word used standalone. For example, calendar applet itself. Since I do not know all underlying details, like whether it is possible to use some kind of logical selection for proper date representation, I guess the fix of issue with months is not so straightforward.

For abbreviated month titles and weekdays looks OK, although further testing is needed. May be I just miss something here.

Here is updated ru_RU file for testing.
Changes include:
* 2-symbol abbreviated week days
* abbreviated months start from lowercase letter

To test (root-privileges required):
1. Backup original /usr/share/i18n/locales/ru_RU
2. Replace /usr/share/i18n/locales/ru_RU with provided file
3. Run locale-gen

Finally, logout/login to pick up the changes. Happy testing.

Алексей, тут вот какая ерунда, обрати внимание, что сокращения делаются с точками, а часть месяцев не сокращается вовсе. Реально "июн" звучит как-то странно ))

"правильно ли сокращение дней недели: пн вт ср чтв пт сб вс ?

Ответ справочной службы русского языка

Корректно с точками: пн., вт., ср., чт. / чтв., пт., сб., вс. / воскр._"

"Подскажите, пож., как правильно сокращать названия месяцев года (янв, и т.д.). Спасибо

Ответ справочной службы русского языка

Верно: _янв., февр., март, апр., май, июнь, июль, авг., сент., окт., нояб., дек."

Влезет больше символов? Если да, то надо привести в соответствие.
Ответы взял с gramota.ru

Мдя. Тогда вообще непонятно, как быть.

Ну, с днями недели по количеству символов нет проблемы. Их изначально три, можно и точку вставить для правильности.

Если принять: янв., февр., март, апр., май, июнь, июль, авг., сент., окт., нояб., дек.
Получается, что нужно делать: янв., февр., марта(?), апр., мая(?), июня(?), июля(?), авг., сент., окт., нояб., дек. Так?

Однако, если принять всё это, то формат даты будет выглядеть дико:
Ср., 14 окт., 10:00
Вс., 14 февр., 10:00
Вс., 14 марта, 10:00 (?)
Пт., 14 мая, 10:00
или это с непривычки?

Я считаю, что стоит норм языка придерживаться и уходить в сторону только если нет возможности технической изменить или это вызовет существенные затруднения.

Вс., 14 марта, 10:00 (?)
Пт., 14 мая, 10:00

Так нормально и звучит, согласись, 15 июн звучит как-то очень странно. Потом баги будут слать, что мягкий знак пропустили.

> Получается, что нужно делать: янв., февр., марта(?), апр., мая(?), июня(?), июля(?), авг., сент., окт., нояб., дек. Так?

Именно так.

Тестируйте. Инструкция выше.

Может, правильней ставить запятую после даты? А потом сокращенное (или в мае
полное) название месяца с точкой:

Ср., 14, окт., 10:00
Вс., 14, фев., 10:00
Вс., 14, мар., 10:00
Пт., 14, май, 10:00

______________________________

Anton Gladkyy

2009/10/14 Alexey Balmashnov <email address hidden>

> Мдя. Тогда вообще непонятно, как быть.
>
> Ну, с днями недели по количеству символов нет проблемы. Их изначально
> три, можно и точку вставить для правильности.
>
> Если принять: янв., февр., март, апр., май, июнь, июль, авг., сент., окт.,
> нояб., дек.
> Получается, что нужно делать: янв., февр., марта(?), апр., мая(?), июня(?),
> июля(?), авг., сент., окт., нояб., дек. Так?
>
> Однако, если принять всё это, то формат даты будет выглядеть дико:
> Ср., 14 окт., 10:00
> Вс., 14 февр., 10:00
> Вс., 14 марта, 10:00 (?)
> Пт., 14 мая, 10:00
> или это с непривычки?
>
> --
> Month names in Russian Localization should be in lowercase
> https://bugs.launchpad.net/bugs/124987
> You received this bug notification because you are a member of Russian
> Ubuntu Translators, which is a bug assignee.
>
> Status in "langpack-locales" package in Ubuntu: Incomplete
>
> Bug description:
> Panel clock shows date for Russian locale in the following format:
> "Втр, 10 Июл, 00:31". It is not right.
>
> 1. According to Russian writing practice, month names are not capitalized.
> So if month name doesn't stay in the beginning of the sentence, its first
> letter should not be capital (for example: "10 июля" or "10 июл" for
> abbreviation).
>
> 2. 3 letter abbreviations for weekdays are very rare in Russian. It is
> better to use 2 letters (Пн, Вт, Ср, Чт, Пт, Сб, Вс).
>

> Получается, что нужно делать: янв., февр., марта(?), апр., мая(?),
июня(?), июля(?), авг., сент., окт., нояб., дек. Так?

Я согласен с таким вариантом.
______________________________

Anton Gladkyy

2009/10/14 Sergei Sedov <email address hidden>

> Я считаю, что стоит норм языка придерживаться и уходить в сторону только
> если нет возможности технической изменить или это вызовет существенные
> затруднения.
>
> Вс., 14 марта, 10:00 (?)
> Пт., 14 мая, 10:00
>
> Так нормально и звучит, согласись, 15 июн звучит как-то очень странно.
> Потом баги будут слать, что мягкий знак пропустили.
>
>
>
> Именно так.
>
> --
> Month names in Russian Localization should be in lowercase
> https://bugs.launchpad.net/bugs/124987
> You received this bug notification because you are a member of Russian
> Ubuntu Translators, which is a bug assignee.
>
> Status in "langpack-locales" package in Ubuntu: Incomplete
>
> Bug description:
> Panel clock shows date for Russian locale in the following format:
> "Втр, 10 Июл, 00:31". It is not right.
>
> 1. According to Russian writing practice, month names are not capitalized.
> So if month name doesn't stay in the beginning of the sentence, its first
> letter should not be capital (for example: "10 июля" or "10 июл" for
> abbreviation).
>
> 2. 3 letter abbreviations for weekdays are very rare in Russian. It is
> better to use 2 letters (Пн, Вт, Ср, Чт, Пт, Сб, Вс).
>

А не используются ли эти сокращения где-нить, в форматном выводе, где важна символьная длина строки?

Давайте господа тестировать, я вот навскидку помню, что в бразеро вроде диски также называются по датам.
Вечером потестю, посмотрю.

Алексей, а вы бы не могли уточнить у Teej какие приложения могут быть затронуты, сколько символов допустимо?

Поиск откуда есть растут все эти определения локалей вывел на проект CLDR - Unicode Common Locale Data Repository http://cldr.unicode.org/ в определениях, доступных в релизе 1.7.1 http://unicode.org/Public/cldr/1.7.1/ интересующие нас секции (см. архив posix.zip файл ru_RU.UTF-8.src) выглядят так:
*************
LC_TIME
*************

abday "Вс";/
        "Пн";/
        "Вт";/
        "Ср";/
        "Чт";/
        "Пт";/
        "Сб"

day "воскресенье";/
        "понедельник";/
        "вторник";/
        "среда";/
        "четверг";/
        "пятница";/
        "суббота"

abmon "янв.";/
        "февр.";/
        "марта";/
        "апр.";/
        "мая";/
        "июня";/
        "июля";/
        "авг.";/
        "сент.";/
        "окт.";/
        "нояб.";/
        "дек."

mon "января";/
        "февраля";/
        "марта";/
        "апреля";/
        "мая";/
        "июня";/
        "июля";/
        "августа";/
        "сентября";/
        "октября";/
        "ноября";/
        "декабря"

d_fmt "%d.%m.%y"

t_fmt "%H:%M:%S"

d_t_fmt "%e %B %Y г. %H:%M:%S %Z"

am_pm "<A><M>";"<P><M>"

t_fmt_ampm ""

END LC_TIME

В то же самое время в используемых в данный момент определениях оно выглядит вот так:
LC_TIME
day "Воскресенье";/
        "Понедельник";/
        "Вторник";/
        "Среда";/
        "Четверг";/
        "Пятница";/
        "Суббота"
abday "Вск";/
        "Пнд";/
        "Втр";/
        "Срд";/
        "Чтв";/
        "Птн";/
        "Сбт"
mon "Январь";/
        "Февраль";/
        "Март";/
        "Апрель";/
        "Май";/
        "Июнь";/
        "Июль";/
        "Август";/
        "Сентябрь";/
        "Октябрь";/
        "Ноябрь";/
        "Декабрь"
abmon "Янв";/
        "Фев";/
        "Мар";/
        "Апр";/
        "Май";/
        "Июн";/
        "Июл";/
        "Авг";/
        "Сен";/
        "Окт";/
        "Ноя";/
        "Дек"
d_t_fmt "%a %d %b/
 %Y %T"
d_fmt "%d.%m.%Y"
t_fmt "%T"
am_pm "";""
t_fmt_ampm ""
date_fmt "%a %b %e/
 %H:%M:%S /
%Z %Y"
first_weekday 2
first_workday 2
END LC_TIME

Налицо серьёзные расхождения. В CLDR с сокращёнными днями недели тоже не лады.

То, что опеределено в CLDR, однозначно сломает апплет календаря, как я уже писал выше. Апплет использует написания месяцев, заданные для формата даты в определениях локали. Впрочем, это уже баг соответствующего апплета, не так ли?

Как всегда вопрос: Что со всем этим знанием делать?

On Wed, Oct 14, 2009 at 10:17 AM, Sergei Sedov <email address hidden> wrote:
> Алексей, а вы бы не могли уточнить у Teej какие приложения могут быть
> затронуты, сколько символов допустимо?

Я бы мог. Но судя по его стандартным комментариям и вопросам он
обыкновенный стрелочник, который пытается понять, откуда могут расти
ноги у данной проблемы и на кого нужно навесить данный баг, чтобы его
в конце концов решить.

Про апплет календаря, который точно сломается, я выше уже написал.

Точки после дней недели выглядят ужасно если учесть что там еще и запятая дальше стоит

После месяца тоже стоит запятая.

2009/10/14 Dmitry <email address hidden>:
> Точки после дней недели выглядят ужасно если учесть что там еще и
> запятая дальше стоит

Это-то понятно. А что говорят ГОСТы?

--
Dmitry Agafonov

> Как всегда вопрос: Что со всем этим знанием делать?
Решить, что для нас главнее - апплет календаря или Unicode Common Locale Data Repository. И, соответственно, или ломать календарь, или забить.

А причём тут ГОСТы?
Это не тех. документация.

D.A. > Это-то понятно. А что говорят ГОСТы?

ГОСТ получается только один ГОСТ Р 6.30-2003, на оформление документов см [1], [2]. Там чётко регламентируется только формат «дд.мм.гггг», также написано, что возможно использование «дд месяц гггг», но о сокращениях - ни слова.

A. T. > > Как всегда вопрос: Что со всем этим знанием делать?
> Решить, что для нас главнее - апплет календаря или Unicode Common Locale Data Repository. И, соответственно, или ломать календарь, или забить.

Насколько я понял, читая всё что ечть по верхам, из CLDR ещё генерируется что-то IBM-овское, не только posix-определения (но glibc, откуда растёт локализация в Linux, CLDR похоже не использует).

На апплет-то точно можно забить, ибо он использует для левых целей список месяцев, сделанный исключительно для представления даты в определённом формате. Т.е. это проблема исключительно апплета. Является ли этот апплет единственной неправильной в этом отношении программой — вот в чём вопрос.

[1] http://ru.wikipedia.org/wiki/%D0%9A%D0%B0%D0%BB%D0%B5%D0%BD%D0%B4%D0%B0%D1%80%D0%BD%D0%B0%D1%8F_%D0%B4%D0%B0%D1%82%D0%B0
[2] http://forum.gramota.ru/forum/read.php?f=1&i=6676&t=6657&v=f

Угу, давайте отделим мух от котлет.

Факты:
1. Апплет «Часы 2.28.0» отображает дату в «левом» формате
2. Для формирования отображаемой даты указанный апплет использует информацию, определённую для локали ru_RU, не придавая значения тому, что определения из локали должны использоваться в конкретном(-ых) формате(-ах)
3. Текущее определение локали ru_RU в glibc не соответствует правилам русского языка
4. Текущее определение локали ru_RU в glibc не соответствует определению локали в проекте CLDR
5. Текущее определение локали в проекте CLDR не соответствует правилам русского языка (здесь минимальные расхождения)

Т.е. если делать по-уму, то нужно
а) исправить проблему несоответствия CLDR правилам русского языка, возможно выкинув также капитализацию сокращённых дней недели
б) привести в соответствие определения локали в glibc и CLDR
в) изменить апплет часов и/или его настройки по умолчанию

Как-то вот так. Надо будет написать контактному лицу, указанному в glibc/ru_RU и спросить, что он думает по поводу проекта CLDR.

Алексей, вы очень хорошо это всё подытожили, можно вас попросить тогда этому человеку написать, так как судя по всему вы в этом вопросе разбираетесь лучше всех.

Проблема конечно не первой важности, но реально было бы неплохо это всё же поправить, хотя бы для будущих релизов.

Личное имхо, и данные из gramota.ru, которые я привёл выше, говорят о том, что править надо.

Честно говоря, точки после сокращений меня тоже пугают. С некоторых пор я с осторожностью отношусь к ответам на грамоте.ру.

Не всегда сокращения требуют точки. Например, с, мм, кг, млн как раз пишутся без точки.

Мои выводы примерно такие:
1. Злоупотреблять сокращениями месяцев и дней недели не нужно. Только в случае необходимости следует сокращать.
2. Сокращенное название дней недели вообще, по-моему, только в табличном календаре бывает. Когда мы видим последовательность «пн, вт, ср, чт, пт, сб, вс» целиком, нам ее легче распознать. Лучше уж вообще не писать день недели, если не хватает места.
3. Трехбуквенные сокращения месяцев кажутся мне допустимыми, хотя и в очень редких случаях. Типа календаря. Именно трехбуквенные и без точки. То, что предлагает грамота, уместно в письменном тексте. И без даты. Потому что вариант «10 июнь 2009» не уместен нигде.
4. Кстати, MS Excel распознаёт только последовательность «пн» и «Пн», и не распознает «Пнд», «Пон», «Пнд.» и «пнд.» ни в каком виде. Месяцы он распознаёт либо целиком (со строчной или заглавной буквы, неважно) в именительном падеже, либо трехбуквенные («янв» или «Янв») и притом без точек.
5. Я не знаю как, но месяцы в именительном падеже тоже могут быть нужны — для какого-нибудь месячного виджета в календарях и расписаниях.

Предлагаю следующие варианты для виджета:
• Четверг, 15 октября 2009 г., 12:31
• 15 октября 2009 г., 12:31
• 15 окт 2009, 12:31 (тут у меня сомнения)
• 12:31

Эти форматы должны либо как-то сами подгоняться под необходимую ширину, либо у человека должна быть возможность как-то выбрать формат по громоздкости. Возможно даже путём сжимания/растягивания виджета.

> Честно говоря, точки после сокращений меня тоже пугают. С некоторых пор я с осторожностью отношусь к ответам на грамоте.ру

Ну... можно посмотреть словарь, не думаю, что они ошиблись :)

> 4. Кстати, MS Excel распознаёт только последовательность «пн» и «Пн», и не распознает «Пнд», «Пон», «Пнд.» и «пнд.» ни в каком виде. Месяцы он распознаёт либо целиком (со строчной или заглавной буквы, неважно) в именительном падеже, либо трехбуквенные («янв» или «Янв») и притом без точек.

А это к нам как относится? Или где-то важно будет при импорте файлов?

Я думаю нам надо чётко понять, следует ли отказаться от правил языка и придумать свои или всё же их соблюдать :)))

>> Updated ru_RU locale file, fix for abbreviated entities + gramota.ru (5.3 KiB, text/plain)

Я вот пробую, у меня всё работает, никакие календари не ломаются, апплет показывает нормально.
Кто-то ещё тестит?

Не ломается потому, что там подправлены только сокращённые названия, полные названия дней недели и месяцев оставлены как и в оригинале: «Понедельник», «Январь» (тут вообще-то, по стандарту для отображения даты вида «дд месяц гггг» должно быть «января», которое и вылезет в апплете, если поменять).

Давайте мухи от котлет или я что-то не понял.

Сейчас в апплете стоит вот так, насколько я понял по тестированию.

"> Получается, что нужно делать: янв., февр., марта(?), апр., мая(?),
июня(?), июля(?), авг., сент., окт., нояб., дек. Так? "

То есть правила по сокращению собюдаются так?

> полные названия дней недели и месяцев оставлены как и в оригинале: «Понедельник», «Январь» -- ммм, так они и должны такими остаться или я чего то не понимаю. В чём соль проблемы? Я вот визуально вижу, что все приложения вроде работают нормально.

В любом случае я патчем точно буду пользоваться, уже за это спасибо :)

Проблема вылезет, если попытаться использовать длинный формат даты, тогда сегодняшнее число будет выглядеть примерно так: «15 Октябрь 2009 г.».

В каком приложении можно это наблюдать?
И... я так понимаю, мы правим ведь только сокращения?
То есть проблема была и ранее?

I think it is safe to mark this Triaged, there is more than enough information here, and it seems to be being worked on. Thank you.

This patch:
1) Replaces artifical 3-letter weekday abbreviations with 2-letter, without trailing dots. Such abbreviations are intended for calendar headings, so have no dots.
2) Adds geninitive, lowercase month names as alternative digits (for use with %Om sprintf specificator).

Please commit it immediately, such bugs should not be unattended for 3 years.

I DEMAND immediate commiting of that patch. What the hell are you doing instead of maintaining? That trivial bug is opened for 3 years!

Thanks a lot for the patch, but please, refrain from using strong words or demand for a bug to be fixed. There is a lot to do in Ubuntu, and if something is not fixed, it is generally because they might be busy with other stuff - not to forget that many developers work on a volunteer basis as well.

We're working in an open project, and if a bug has not been fixed for a number of years, there are several ways to bring it to attention: the translators mailing list, on meetings, etc. See https://wiki.ubuntu.com/Translations/Contact/ for example.

In the meantime, I'm going to contact the maintainers to comment on it.

In order to forward this upstream, we need a reference to a reasonably official document of any kind which shows that the month names are usually written that way. Do you have some URLs for that? A bunch of examples would also work. Thank you!

I can't find GOST but maybe president web-site is enough?
http://www.kremlin.ru/news

I turned Alexey's updated localel file into a patch and forwarded it upstream. Committed to langpack-locales bzr.

This bug was fixed in the package langpack-locales - 2.13+git20100825-1

---------------
langpack-locales (2.13+git20100825-1) maverick; urgency=low

  * Update to current upstream glibc git head localedata.
  * Add debian/patches/ubuntu-ru_RU-daymonthnames.patch: Russian month names
    are written in lower case, and weekday names are usually abbreviated in
    two-letter form. Thanks Alexey Balmashnov! (LP: #124987)
  * Drop debian-fr_BE-first_weekday.diff, applied upstream.
  * Refresh patches to apply to new upstream version.
  * debian/control: Bump Standards-Version to 3.9.1 (no changes necessary).
 -- Martin Pitt <email address hidden> Wed, 25 Aug 2010 15:46:48 +0200

It looks *awful* now. At *very least* remove dots in weekdays.

I would also consider replacing short month names with Roman numerals {I..XII} and using alternative digit symbols to represent months in genitive case, as it was done in Ukrainian locale.

_There also should be no dots in month names. There is no dots in Russian headers, which weekday and month labels ultimately are._

If I'm not mistaken, translations for Maverick are already frozen.

I suggest you discuss this on the (linked) upstream bug. This shouldn't be a matter of opinion, there must be some document which defines the official norm for displaying abbreviated month names.

Russian language standards allow several different ways to write months, both abbreviations and roman numerals are allowed, so we can choose any of them.
Using dots after month abbreviation is not regulated by GOST, it's absolutely up to us, and I agree that now it looks awful.

Хотели как лучше, а получилось как всегда.... Ребята, давайте не будем путать аббривеатуры и сокращения. Посмотрите, какая ересь с вашем патчем получилась: http://static.itmages.ru/i/10/1011/h_1286828573_87dac3fa20.png

В локализации месяцев и дней недели под abday и abmon подразумевается именно аббривеатуры дней и месяцев а не их сокращения по правилам русского языка. В общем, кто как, а я лучше пропатчу ка это дело под трехбуквенные аббривеатуры месяца и двухбуквенные дней. http://goo.gl/OZnK

Я тоже согласен с этим.

This bug was fixed as per the patch submitted.

As suggested by Martin, if the change did not fix the bug satisfactorily, I'd suggest discussing this either on the upstream bug or on the Ubuntu Russian translators mailing list, and when consensus has been reached then come back here to propose an alternative solution if necessary.

Thanks!

Спасибо инициативным полуграмотным дикарям, разломавшим перевод в glibc ради несчастного аплета.

Thanks to the hyperactive half-literate morons (yes morons in this locale) who degraded the glibc translation for the weenie applet.

Это же надо -- трое суток скакать, чтобы умудриться из лежащего в стороне хлама вытянуть основание для регрессии... ребята, вот как вы думаете -- за что убунтушные переводы ненавидят решительно все знакомые переводчики? Да за то же: фанерная инициативность и реальная некомпетентность.

Те, кто пишет хоть немного грамотно -- лезут не туда. Те, кто смотрит на результат и понимает, что он крив -- пишут неграмотно.

Если вам требуется основание для отката этого безобразия, помимо элементарной грамотности и здравого смысла -- см. текущую версию того же CLDR: http://unicode.org/cldr/trac/browser/tags/release-21-0-2/posix/ru_RU.UTF-8.src#L3153

И на будущее запомните: стандарты хороши тем, что есть из чего выбрать, и вот как раз при этом выборе и положено применять голову по назначению. Нечего с каждого забора вроде википедии брать основания для разламывания сделанного _уже_ качественно.

С неуважением,
Михаил Шигорин

Всё супер, много слов, кроме главного. Как и где надо исправлять?
Пока неинициативные суперграмотные не будут делиться заниями о
способах решения _видимых всеми_ проблем - будет бардак.
И вообще, где эти все грамотные переводчики?

Пожалуйста, не обижайтесь и не обижайте. Учите!

--
Dmitry Agafonov ~ http://agafonov.pp.ru/

> Как и где надо исправлять?

Я думаю, надо завести баг в Glibc (Eglibc?) с просьбой откатить патч из http://sourceware.org/bugzilla/show_bug.cgi?id=11945.

Шигорин, перестань подписывать меня на спам.

Саш, я тебя на этот спам не подписывал.

Дмитрий, достаточно откатить этот коммит, как Ваш тёзка и пишет. Майнтейнеру glibc в используемом дистрибутиве (и апстримному контрибутору) эту просьбу уже изложил.

Насчёт "не обижайте" -- дело не в обидах, а в системном потакании безграмотности в убунте (для себя я это выяснил ещё в 2005/6, общаясь с sabdfl@). И боюсь, что никаким желанием помочь, научить, исправить не получится ничего сделать с оравой людей, которые несутся куда-то делать что-то, пока сами эти люди за ум взяться не захотят.

Поэтому и говорю: хотя бы не делайте того, по поводу чего возникают малейшие сомнения. И тем более не спешите кланяться стандарту -- как видите, бывает проруха и здравый смысл не отменяли.

--- по просьбе коллеги заменяю комментарий #60 его почти полной копией ---

PS: посмотрите ещё, в каком контексте вообще всплыло это "февр.", попавшее в старый CLDR (которому доверия примерно как забору с такими процедурами):

ГОСТ 7.12-93
Система стандартов по информации, библиотечному и издательскому делу. Библиографическая запись. Сокращение слов на русском языке. Общие требования и правила

http://www.complexdoc.ru/text/ГОСТ%207.12-93

Библиографическая запись -- довольно узкая специализация, где благозвучность либо элегантность в табличном виде не являются существенными.