This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH v12] Locales: Cyrillic -> ASCII transliteration [BZ #2872] ping for 2.30
- From: Egor Kobylkin <egor at kobylkin dot com>
- To: libc-alpha at sourceware dot org, libc-locales at sourceware dot org, Carlos O'Donell <carlos at redhat dot com>
- Cc: Marko Myllynen <myllynen at redhat dot com>, Rafal Luzynski <digitalfreak at lingonborough dot com>, Siddhesh Poyarekar <siddhesh at gotplt dot org>, Mike Fabian <mfabian at redhat dot com>
- Date: Mon, 4 Feb 2019 08:14:09 +0100
- Subject: Re: [PATCH v12] Locales: Cyrillic -> ASCII transliteration [BZ #2872] ping for 2.30
- References: <email@example.com> <20180412224352.GB2911@altlinux.org> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com>
are you comfortable to pick this up again this month?
I would really love to have a reliable action plan to get this committed
for 2.30. Maybe cut out a subset that is undisputed and commit only that
first. It looks kinda like an eternal moving target otherwise.
for you reference:
On 09.01.19 21:03, Marko Myllynen wrote:
On 09/01/2019 02.46, Egor Kobylkin wrote:
On 07.01.19 21:37, Marko Myllynen wrote:
On 05/01/2019 23.12, Egor Kobylkin wrote:
Good catch! Should we maybe split this into two patches, one for C and
the other for "country" locales? They have different codes and
functionality so it looks like it would be easier to keep focus.
That would probably make sense, the standard C/POSIX locale won't
support System A so it also narrows down solution alternatives with it.
"Country" locales in localedata/locales/ can then have the exact same
translit table included or they can have any other flavor - I don't see
a problem here.
Indeed, and since those files are not limited to ASCII, perhaps we could
now reconsider the v9 approach for them, i.e., prefer System A if
possible, otherwise use System B / ASCII (just need to make sure that
the ASCII fall-back for them will match the built-in C ASCII rule)?
Happy to hear the split seems to be a clear cut one.
How about I rename the "[PATCH v12]...[BZ #2872]" to "[PATCH v1]...
C/POSIX [BZ #2872]" and the "[PATCH v9]" gets its own bug-report
(number) and title for clarity in communication?
I'm not sure is a new BZ really needed for such an addition, perhaps a
NEWS entry might be more appropriate (with the full details explained in
the commit messages of course) but I'll leave this to others to decide.
This way it would probably be easier to have the decision making process
tied up for both patches (separately). We may want to get the v12 POSIX
out of the door in 2.30 then and can take all the time we need to set up
the rules for "Countries" locales as you need them to be.
Perhaps Rafal or Carlos have better suggestions but I would think we
could have a patch series where the patch 1/3 adds the C/POSIX locale
part (that would be what you posted as v12), then patch 2/3 adds
translit_cyrillic (based on your v9 so supports ISO 9.1995 / GOST 7.79
System A and GOST 7.79 System B as a fall-back (which would match the
C/POSIX rules)), and finally the patch 3/3 updates locales to use
translit_cyrillic as appropriate. But as said, Rafal or Carlos may have
alternative suggestions so it might be best to wait for their feedback
before doing anything yet (it's unfortunate you've had to do so many
iterations around this already but I think we've all learned something
during the process and the end result will be more correct than any of
the earlier versions).