Re: [HEADS UP] Changes in date formatting (strftime, nl_langinfo)
On Sat, Jan 27, 2018 at 3:58 PM, Rafal Luzynski
<digitalfreak@lingonborough.com> wrote:
> 28.01.2018 00:23 Ihar Hrachyshka <ihar.hrachyshka@gmail.com> wrote:
>> On Wed, Jan 24, 2018 at 3:46 AM, Viktar Siarheichyk <vics@fsfe.org> wrote:
>> > [...]
>> > Thus the list of Belarusian month names in genitive case in Latin script is
>> > the following:
>> >
>> > studzienia
>> > lutaha
>> > sakavika
>> > krasavika
>> > traŭnia
>
> This should be "maja", shouldn't it?
Oh right, I totally missed that one. Yes. 'Travien' is an alternative
variant that is not as widely used, and we should stick to existing
terminology (so 'maja').
>
>> > červienia
>> > lipienia
>> > žniŭnia
>
> OK, here I was asking if "Žnivień" -> "žniŭnia" is correct but now I can see
> the same in Cyrillic in CLDR: "жнівень" -> "жніўня" which confirms that this
> is correct.
Yes, it's correct. The upper/lower case letter depends on where the
word is in the sentence. If it's the first word, it's upper case,
otherwise lower (it's of course obvious, but it's better to be
explicit). I don't know if Žnivień is always the first word, or not.
>
>> > vierasnia
>>
>> ^ there is a mistake here, it's vieraśnia, not vierasnia. Other names are
>> fine.
>
> OK, I'm fixing locally and in github:
>
> https://github.com/rluzynski/glibc/commits/master
>
> Please review and... it looks that we can prepare the patch and push
> it on Monday? Seems like we are going to fix the largest (by the number
> of speakers) and the most affected languages.
I think what should be fixed is:
https://github.com/rluzynski/glibc/blob/master/localedata/locales/be_BY%40latin#L108
Also this one is weird:
https://github.com/rluzynski/glibc/blob/master/localedata/locales/be_BY%40latin#L159
because if we apply Belarusian Latin script, it would be: biełaruskaja
mova, but maybe I miss something.
As for Cyrillic versions, it's not easy to parse it, so I haven't
checked. I actually think that the files should contain proper unicode
strings that, if needed, would be converted back to U-notation for
machine parsing, but maybe that's just me.
>
> Regards,
>
> Rafal
Reply to: