On Mon, Jan 22, 2018 at 09:16:23AM +0100, Petr Pisar wrote:
> On Sun, Jan 21, 2018 at 10:54:52PM +0100, Petr Kovar wrote:
> > On Sun, 21 Jan 2018 00:10:28 +0100 (CET)
> > Rafal Luzynski <digitalfr...@lingonborough.com> wrote:
> > >
> > However, changing anything in glibc is very tricky so I won't vote
> > for this change without hearing what other Czech translators think. I
> > think other language groups might share the same sentiment, actually.
> >
> It's not tricky. It's incompatible. "%B" means a month name in a dictionary
> form (i.e. nominativ in case of flective languages) now. Existing translations
> of other programs expect it and changing in into a different form would break
> them.
>
> I'm unable to decide if the change is overall positive of negative. But
> if it happens, it needs proper documentation in nl_langinfo(3), strftime(3)
> etc. E.g. nl_langinfo(3) reads:
>
> MON_{1???12} (LC_TIME) Return name of the n-th month.
>
> With the proposed change it would return the non-dictionary form that cannot
> be used a standalone label and that's wrong. Try running "cal" command.
>
> Also MON and ALT_MON difference should not be explained with cases. Cases are
> a language specific matter. It should talk about "a dictionary form" and "a
> form used in a date string".
>
> Actually the more I think about it the less I like the change. How do you want
> to solve the breakage of nl_langinfo(3) that's defined by POSIX? I'd rather
> reverse the change. Keep MON for the dictionary form and use ALT_MON for the
> date form and either change strftime's "%x" and "%c" definitions to use
> ALT_MON instead or keep the decision up to translators of the glibc.
Yes, I think this change is not clean design. We should keep the meaning of mon
to be the nominative name of the month.
Otherwise it would break cal and other programs
Making a new notion for what we need here like genitive form, would be a
cleaner design.
When we make the change, and we apply it in a locale, we can then both change
the
date format and the info for the genitive form. As this can happen
simultaneously,
there is no need for backwards compatibility for the date format.
The idea of CLDR to use %Om for uppercased first letter is to me another
case of bad design. How can an application know that for languages using
genitinve
names this would apply and it would be good to have for all other languages the
month
name spelled with an initial upper case? And why should languages with genitive
month
names not have the possibility to have an initial upper case?
In my mind it would be better to have a special formatting letter to say that
the initial letter should be upper case, and that would then also apply
to abbereviations and day names.
POSIX has recently also adressed the problem end made new provisions,
I think we should look carefully into this. Has this been done?
Best regards
Keld
_______________________________________________
gnome-i18n mailing list
gnome-i18n@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-i18n
