Question: more languages to support alternative month names?

Question: more languages to support alternative month names?

[Rafal Luzynski]

Hi,

Bug 10871 has been fixed and any language and any application can have
a choice between two grammatical cases of the month names.  But having
a choice does not mean actually using it.  I had only little more
than one week between accepting the change by the community and the final
release date so I was unable to contact every language community to
ask about their opinion.  Only 7 languages have been fixed so far while
I have identified about 20 probably needing an update.  4 out of them
probably don't want two grammatical cases.  There are ~9 more languages
who I'm contacting only now.  It seems to me that at least few of them
will want this change.  So my question is: if they agree how to provide
them the change:

* push the change to master and tell them that they have to wait
  for glibc 2.28?
* push the change both to 2.27 and 2.28?

The first choice seems reasonable to me.  Those 7 fixed languages
have relatively large number of native speakers and the impact of the
bug was rather large.  Other languages either have low number of
speakers and it's difficult to find people actually using them with
computers or do not consider using an incorrect case as a language
error or have working or almost working workarounds.  So I think
it's OK for them to wait a little more.

Also, if we backport a change to a stable 2.27 release it is not
obvious to me if the distributions actually apply the upstream
patches to their binaries. What are your experiences?

Regards,

Rafal

Re: Question: more languages to support alternative month names?

[Carlos O'Donell]

On 02/12/2018 05:45 PM, Rafal Luzynski wrote:
> Hi,
> 
> Bug 10871 has been fixed and any language and any application can have
> a choice between two grammatical cases of the month names.  But having
> a choice does not mean actually using it.  I had only little more
> than one week between accepting the change by the community and the final
> release date so I was unable to contact every language community to
> ask about their opinion.  Only 7 languages have been fixed so far while
> I have identified about 20 probably needing an update.  4 out of them
> probably don't want two grammatical cases.  There are ~9 more languages
> who I'm contacting only now.  It seems to me that at least few of them
> will want this change.  So my question is: if they agree how to provide
> them the change:
> 
> * push the change to master and tell them that they have to wait
>   for glibc 2.28?
> * push the change both to 2.27 and 2.28?
> 
> The first choice seems reasonable to me.  Those 7 fixed languages
> have relatively large number of native speakers and the impact of the
> bug was rather large.  Other languages either have low number of
> speakers and it's difficult to find people actually using them with
> computers or do not consider using an incorrect case as a language
> error or have working or almost working workarounds.  So I think
> it's OK for them to wait a little more.
> 
> Also, if we backport a change to a stable 2.27 release it is not
> obvious to me if the distributions actually apply the upstream
> patches to their binaries. What are your experiences?

You can do either option depending on how much free time you have.

Fedora *routinely* imports upstream release branches.

For example Fedora 28 will be based on glibc 2.27, and over the
6 months of support for Fedora 28 it will be updated routinely
from upstream release/2.27/master to pull in the latest fixes.

There are other distributions doing much the same, and I know Debian
probably also rebases on releases branches.

So you can do either.

As the localedata subsystem maintainer you can commit the fixes to
master and cherry-pick into 2.27 release branch immediately after.

-- 
Cheers,
Carlos.

Re: Question: more languages to support alternative month names?

[Rafal Luzynski]

15.02.2018 22:30 Carlos O'Donell <carlos@redhat.com> wrote:
> [...]
> You can do either option depending on how much free time you have.

Updating locales is really a minor part of the task, especially
since I've had them prepared and waiting for approval from the
language communities for about 1 year now.  Approaching applications
and libraries and patching them to use "%OB" is the really hard part.
So now the locales depend on the actual native speakers.

Currently I'm talking to Catalan translators and it seems that
they want this update already. [1]

> Fedora *routinely* imports upstream release branches.
>
> For example Fedora 28 will be based on glibc 2.27, and over the
> 6 months of support for Fedora 28 it will be updated routinely
> from upstream release/2.27/master to pull in the latest fixes.
>
> There are other distributions doing much the same, and I know Debian
> probably also rebases on releases branches.

That's very good news.  I was concerned that either they will have
to wait another 6 months for glibc 2.28 release or they will update
the translations (in their case this means removal of "de" before
the month name, everywhere) and then their applications will run
on some systems with vanilla glibc 2.27.0, some with patched or
partially patched glibc, some on even older glibc.

> So you can do either.
>
> As the localedata subsystem maintainer you can commit the fixes to
> master and cherry-pick into 2.27 release branch immediately after.

This is what I will do, of course when the patch is ready, reviewed,
etc.  Also if possible I will try to update Asturian and Walloon
because their grammatical rules seem to be similar.

Thank you for your answers.

Regards,

Rafal


[1] https://sourceware.org/bugzilla/show_bug.cgi?id=22848

Re: Question: more languages to support alternative month names?

[Rafal Luzynski]

15.02.2018 22:30 Carlos O'Donell <carlos@redhat.com> wrote:
>
> On 02/12/2018 05:45 PM, Rafal Luzynski wrote:
> > Hi,
> >
> > Bug 10871 has been fixed and any language and any application can have
> > a choice between two grammatical cases of the month names. But having
> > a choice does not mean actually using it. I had only little more
> > than one week between accepting the change by the community and the final
> > release date so I was unable to contact every language community to
> > ask about their opinion. Only 7 languages have been fixed so far while
> > I have identified about 20 probably needing an update. 4 out of them
> > probably don't want two grammatical cases. There are ~9 more languages
> > who I'm contacting only now. It seems to me that at least few of them
> > will want this change. So my question is: if they agree how to provide
> > them the change:
> >
> > * push the change to master and tell them that they have to wait
> > for glibc 2.28?
> > * push the change both to 2.27 and 2.28?
> >
> > [...]
>
> You can do either option depending on how much free time you have.
>
> Fedora *routinely* imports upstream release branches.
>
> For example Fedora 28 will be based on glibc 2.27, and over the
> 6 months of support for Fedora 28 it will be updated routinely
> from upstream release/2.27/master to pull in the latest fixes.
>
> There are other distributions doing much the same, and I know Debian
> probably also rebases on releases branches.
>
> So you can do either.
>
> As the localedata subsystem maintainer you can commit the fixes to
> master and cherry-pick into 2.27 release branch immediately after.

So I have 4 patches ready to be committed for the following languages:

ca_ES: https://sourceware.org/ml/libc-alpha/2018-03/msg00166.html
lt_LT: https://sourceware.org/ml/libc-alpha/2018-03/msg00202.html
el_*:  https://sourceware.org/ml/libc-alpha/2018-03/msg00203.html
cs:CZ: https://sourceware.org/ml/libc-alpha/2018-03/msg00325.html

lt_LT fixes 2 strings (month names), it is a minor change.  el_CY
and el_GR add ab_alt_mon which turned out to be necessary but this
is not a major change taking into account that altmon is already
present in el_* locales.  cs_CZ introduces altmon; it has been
discussed for a long time but glib2 translator has already provided
the equivalent translation, it will be used as a fallback for older
systems so it does not make sense *not* to support the genitive
cases in cs_CZ in 2.27.  ca_ES introduces altmon, ab_alt_mon, and
few minor typo changes as requested by the translator.  The
translations for GNOME project have been already adapted to the
new format ("%d de %B" replaced with "%d %B").

IIUC it is OK to commit these changes to master.

Also I'd like to cherry-pick them all into 2.27 release branch.
Can you guys explain me the process of committing to the stable
branch? I should update ChangeLog, that is obvious.  What about
NEWS?  Should I retroactively add new languages and bugs to the
list of languages supporting the genitive case of month names
and to the list of bugs fixed in 2.27, just as if they were fixed
2 months ago?  Create a new section for 2.27.1?  Do not update
NEWS?  Do not cherry-pick anything to 2.27?

Regards,

Rafal

Re: Question: more languages to support alternative month names?

[Florian Weimer]

On 03/14/2018 01:10 PM, Rafal Luzynski wrote:
> Also I'd like to cherry-pick them all into 2.27 release branch.
> Can you guys explain me the process of committing to the stable
> branch? I should update ChangeLog, that is obvious.  What about
> NEWS?  Should I retroactively add new languages and bugs to the
> list of languages supporting the genitive case of month names
> and to the list of bugs fixed in 2.27, just as if they were fixed
> 2 months ago?  Create a new section for 2.27.1?  Do not update
> NEWS?  Do not cherry-pick anything to 2.27?

NEWS updates for 2.27.1 should happen in the 2.27.1 section.  There is 
only the bug list so far, so you should add a new section for these 
changes.  Post a patch for review to libc-stable if unsure.

Thanks,
Florian

Re: Question: more languages to support alternative month names?

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]

On Wed, Mar 14, 2018 at 01:10:28PM +0100, Rafal Luzynski wrote:
[...]
> Also I'd like to cherry-pick them all into 2.27 release branch.
> Can you guys explain me the process of committing to the stable
> branch? I should update ChangeLog, that is obvious.  What about
> NEWS?  Should I retroactively add new languages and bugs to the
> list of languages supporting the genitive case of month names
> and to the list of bugs fixed in 2.27, just as if they were fixed
> 2 months ago?  Create a new section for 2.27.1?  Do not update
> NEWS?  Do not cherry-pick anything to 2.27?

You main backporting tool is "git cherry-pick -x",
the process of cherry-picking is straightforward assuming that
you have a working merge-changelog referenced by .gitattributes file.

When a cherry-picked commit fixes a bug, the commit has to be amended
to explicitly list this fixed bug in "Version 2.27.1" part of NEWS.
You can look at the output of
git log -p glibc-2.27..glibc-2.27-27-gb63daad -- NEWS
command to get an idea how this works.

If you are going to list languages supporting the genitive case of month
names, a new section should be within "Version 2.27.1" part of NEWS, too.

Hope this helps,


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Question: more languages to support alternative month names?

[Rafal Luzynski]

14.03.2018 13:20 Florian Weimer <fweimer@redhat.com> wrote:
> [...]
> NEWS updates for 2.27.1 should happen in the 2.27.1 section. There is
> only the bug list so far, so you should add a new section for these
> changes. Post a patch for review to libc-stable if unsure.

Thank you for the explanation about NEWS and mentioning libc-stable.
It's never hurting so it's better to post.  Here it is:

https://sourceware.org/ml/libc-stable/2018-03/msg00012.html

14.03.2018 13:28 "Dmitry V. Levin" <ldv@altlinux.org> wrote:
> [...]
> You main backporting tool is "git cherry-pick -x",
> the process of cherry-picking is straightforward assuming that
> you have a working merge-changelog referenced by .gitattributes file.
>
> When a cherry-picked commit fixes a bug, the commit has to be amended
> to explicitly list this fixed bug in "Version 2.27.1" part of NEWS.
> You can look at the output of
> git log -p glibc-2.27..glibc-2.27-27-gb63daad -- NEWS
> command to get an idea how this works.

Thank you, this is exactly the information which I missed.

> If you are going to list languages supporting the genitive case of month
> names, a new section should be within "Version 2.27.1" part of NEWS, too.

Added, patches sent for a quick review to libc-stable (see the link above).

I will especially appreciate the proofreading of NEWS updates.

Best regards,

Rafal