[Bug localedata/10580] New file for hr_HR localedata

[Bug localedata/10580] New file for hr_HR localedata

[pasky at ucw dot cz]

http://sourceware.org/bugzilla/show_bug.cgi?id=10580

Petr Baudis <pasky at ucw dot cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING
                 CC|                            |pasky at ucw dot cz

--- Comment #10 from Petr Baudis <pasky at ucw dot cz> 2013-02-16 00:39:45 UTC ---
Dragan, thank you for your work.

It is true that the locales in glibc are not fully ISO/IEC 14652 compliant, in
particular some fields that should be used in fact are not. I'm not personally
sure why this is the case, probably it's for purely historical reasons.
However, I believe the greatest value lies in consistency, and if no current
locales use %n in postal_fmt and %e and %t in tel_*_fmt, neither should hr_HR
as the programs using these locales probably do not expect to find these field
descriptors there.

So let's not conflate the issue of unsupported field descriptors with the new
hr_HR locale; could you please submit an hr_HR locale version that does not use
these field descriptors? Since you got a buy-in from other Croatians active in
this area, I think we can commit the new locale speedily afterwards.

(Regarding the issue of unsupported field descriptors, if you are interested in
pursuing that further. A simple technical fix is to simply patch
locale/programs/ld-{telephone,address}.c to allow these. However, we should do
this with consideration to locale consistency and current usage of these
categories in programs. This needs to be researched and I think the next
reasonable step is to document the currently supported field descriptors in
"glibc style locales". We can then think of how to proceed further while our
users will already have a valuable reference. This process can be done
gradually, category by category. Does that sound sensible?)

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: [Bug localedata/10580] New file for hr_HR localedata

[Keld Simonsen]

On Sat, Feb 16, 2013 at 12:39:45AM +0000, pasky at ucw dot cz wrote:
> (Regarding the issue of unsupported field descriptors, if you are interested in
> pursuing that further. A simple technical fix is to simply patch
> locale/programs/ld-{telephone,address}.c to allow these. However, we should do
> this with consideration to locale consistency and current usage of these
> categories in programs. This needs to be researched and I think the next
> reasonable step is to document the currently supported field descriptors in
> "glibc style locales". We can then think of how to proceed further while our
> users will already have a valuable reference. This process can be done
> gradually, category by category. Does that sound sensible?)

I would rather take another approach, and that would be to further implement
ISO TR 14652 or the new version thereof, ISO TR 30112. ISO TR 30112 is closer
to glibc, as some things that glibc implements is now specified in
30112, including LC_PAPER. 

Best regards
Keld

[Bug localedata/10580] New file for hr_HR localedata

[keld at keldix dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=10580

--- Comment #11 from keld at keldix dot com <keld at keldix dot com> 2013-02-16 18:49:08 UTC ---
On Sat, Feb 16, 2013 at 12:39:45AM +0000, pasky at ucw dot cz wrote:
> (Regarding the issue of unsupported field descriptors, if you are interested in
> pursuing that further. A simple technical fix is to simply patch
> locale/programs/ld-{telephone,address}.c to allow these. However, we should do
> this with consideration to locale consistency and current usage of these
> categories in programs. This needs to be researched and I think the next
> reasonable step is to document the currently supported field descriptors in
> "glibc style locales". We can then think of how to proceed further while our
> users will already have a valuable reference. This process can be done
> gradually, category by category. Does that sound sensible?)

I would rather take another approach, and that would be to further implement
ISO TR 14652 or the new version thereof, ISO TR 30112. ISO TR 30112 is closer
to glibc, as some things that glibc implements is now specified in
30112, including LC_PAPER. 

Best regards
Keld

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/10580] New file for hr_HR localedata

[invisible@hidden-city.net]

http://sourceware.org/bugzilla/show_bug.cgi?id=10580

--- Comment #12 from Dragan Stanojevic - Nevidljivi <invisible@hidden-city.net> 2013-02-16 19:10:32 UTC ---
Thank you for your comments!

So if I understand correctly, I just need to trim LC_ADDRESS and LC_TELEPHONE
to comply with current support in glibc, and you'll accept the whole patch?

That would be great, since it resolves a lot of issues, shortens the file,
makes it more manageable for future changes, and so on...

Back then I've read whole ISO/IEC TW 14652, tried to mimic other locale format
as much as possible and I think I made good patch. In the end I thought I'd
need to learn flex & bison to improve glibc parsing of those data, but that was
beyond me.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

moderation of libc-licales list

[Keld Simonsen]

Hi

I am one of the moderators of the libc-locales list.
I am wondering what is happening there.
I see messages to the list accepted before I  even get
to accept the message. That is really fine with me,
as these all are from people that send something useful.
Presumably the senders are on the list allready.
But I do not think the other moderator has had the time
to do the acceptance. So it looks like the accptance
has been done automatically.

So if some automatic acceptance is done, I would appreciate
that the message is not also sent to me. Sometimes
there are many messages and I have some difficulty finding out
which messages allready have been accepted, and which have not,
so I then go on accepting them all, after checking that
they are not spam etc. That is a bit of a waste of time.

What is actually the procedure in effect here, and could it be improved?

Best regards
Keld

[Bug localedata/10580] New file for hr_HR localedata

[pasky at ucw dot cz]

http://sourceware.org/bugzilla/show_bug.cgi?id=10580

--- Comment #13 from Petr Baudis <pasky at ucw dot cz> 2013-02-17 00:13:28 UTC ---
Keld, of course using the newer standard makes sense; however, I'm not sure
what do you mean by "further implement" and how that differs from what I wrote.
If you are interested in discussing this further, I propose we move the
discussion to the mailing list where more people could follow it. (Note that I
myself don't have the time to pursue the issue itself, so it makes sense to
talk more about it only if someone intends to do anything about it.)

Dragan, I'm sorry, I missed the LC_COLLATE syntax error. Any reason why we
cannot use the unicode entity there instead?

Also, I'm wondering, how was testing of this locale done if it doesn't even
compile with glibc's localedef now? And which of the people that provided
support for the new locale actually tested it rather than just embraced the
idea?

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: [Bug localedata/10580] New file for hr_HR localedata

[Keld Simonsen]

On Sun, Feb 17, 2013 at 12:13:28AM +0000, pasky at ucw dot cz wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=10580
> 
> --- Comment #13 from Petr Baudis <pasky at ucw dot cz> 2013-02-17 00:13:28 UTC ---
> Keld, of course using the newer standard makes sense; however, I'm not sure
> what do you mean by "further implement" and how that differs from what I wrote.
> If you are interested in discussing this further, I propose we move the
> discussion to the mailing list where more people could follow it. (Note that I
> myself don't have the time to pursue the issue itself, so it makes sense to
> talk more about it only if someone intends to do anything about it.)

So where should we do the discussion? I did think that
this list was relevant. Anyway, the differences are not big,..
It is mostly to align with current glibc implementation, and then
introduce 2 novelties.

Best regards
Keld

Re: [Bug localedata/10580] New file for hr_HR localedata

[Petr Baudis]

On Sun, Feb 17, 2013 at 02:41:35AM +0200, Keld Simonsen wrote:
> On Sun, Feb 17, 2013 at 12:13:28AM +0000, pasky at ucw dot cz wrote:
> > http://sourceware.org/bugzilla/show_bug.cgi?id=10580
> > 
> > --- Comment #13 from Petr Baudis <pasky at ucw dot cz> 2013-02-17 00:13:28 UTC ---
> > Keld, of course using the newer standard makes sense; however, I'm not sure
> > what do you mean by "further implement" and how that differs from what I wrote.
> > If you are interested in discussing this further, I propose we move the
> > discussion to the mailing list where more people could follow it. (Note that I
> > myself don't have the time to pursue the issue itself, so it makes sense to
> > talk more about it only if someone intends to do anything about it.)
> 
> So where should we do the discussion? I did think that
> this list was relevant. Anyway, the differences are not big,..
> It is mostly to align with current glibc implementation, and then
> introduce 2 novelties.

I see. I'm sorry, I didn't notice that the messages are sent to the
libc-locales list as well as the bugreport. :-)

				Petr "Pasky" Baudis

[Bug localedata/10580] New file for hr_HR localedata

[invisible@hidden-city.net]

http://sourceware.org/bugzilla/show_bug.cgi?id=10580

--- Comment #15 from Dragan Stanojevic - Nevidljivi <invisible@hidden-city.net> 2013-02-17 13:56:29 UTC ---
Hi,

let me be frank. This was made in 2009. I've spend at least a week reading ISO
documents, comparing to other locales similar to hr_HR, contacting Croatian
Linux User Group and writing tests.

Every question considering compile errors was answered in the huge description
of the patch, and repeated on comment #9, since obviously Drepper didn't read
it in the first place when he dissed the patch.

If you don't want LC_ADDRESS or LC_TELEPHONE, copy them from C locale. If you
don't want to implement "<d><z>", comment it out...

Also there is no standard test suite for this locale categories. I find it hard
to believe that I (or any locale writer) have to write custom test suites from
scratch again, nor do I have the time.

I repeat, this patch was a big improvement in 2009. I don't have time to again
write test suites from scratch. Let alone to reread ISO documents, and patch
libc itself.

It's your choice will you ever apply this patch.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/10580] New file for hr_HR localedata

[pasky at ucw dot cz]

http://sourceware.org/bugzilla/show_bug.cgi?id=10580

--- Comment #16 from Petr Baudis <pasky at ucw dot cz> 2013-02-17 15:05:21 UTC ---
I have read everything you have written in this bugreport; I might have missed
something, but I asked my questions because I believe they weren't answered in
the previous comments.

My question was not geared at test suites, though I appreciate your effort to
test the collation rules. I was just wondering whether and how this locale
(considering that it cannot be compiled by localedef as it is now) was tried
out with actual commonly used software, and whether that was done just by you
or by the other people supporting it too.

If you could adjust the locale into a compilable form, we can easily ask other
to test it so that we can incorporate any bugfixes before the next release;
this (besides few simple sanity checks I'll do) does not need to block
committing the new locale.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/10580] New file for hr_HR localedata

[invisible@hidden-city.net]

http://sourceware.org/bugzilla/show_bug.cgi?id=10580

--- Comment #17 from Dragan Stanojevic - Nevidljivi <invisible@hidden-city.net> 2013-02-17 18:16:42 UTC ---
Heyyah Petr,

thanks for reading and a reply. Give me a few days, and I'll try to test and
fix this patch to compile using 2.17.

I cannot vouch for testing of others who saw and gave approval of this patch. I
did it myself as I was displeased of the state of hr_HR locale back then.

I was mainly interested in collation, but did a lot more research then
intended, and in turn patched all categories of locale. During that, I've
cleaned, commented and trimmed the locale file considerably.

bye for now,
N::

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/10580] New file for hr_HR localedata

[pasky at ucw dot cz]

http://sourceware.org/bugzilla/show_bug.cgi?id=10580

--- Comment #18 from Petr Baudis <pasky at ucw dot cz> 2013-02-17 18:23:29 UTC ---
Hi! Yes, I fully appreciate your efforts - I just want to confirm the status of
the new locale regarding how it has been tested.

Glad you decided to update your version of the locale, we will be looking
forward to the new version. I can't think of specific updates that would be
required for 2.17 (there were no changes in stock hr_HR since 2009), so mainly
making it compile would be great.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/10580] New file for hr_HR localedata

[invisible@hidden-city.net]

http://sourceware.org/bugzilla/show_bug.cgi?id=10580

Dragan Stanojevic - Nevidljivi <invisible@hidden-city.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #6876|0                           |1
        is obsolete|                            |
             Status|WAITING                     |NEW
         AssignedTo|libc-locales at sourceware  |invisible@hidden-city.net
                   |dot org                     |

--- Comment #20 from Dragan Stanojevic - Nevidljivi <invisible@hidden-city.net> 2013-02-19 06:50:42 UTC ---
Created attachment 6877
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6877
An updated version of hr_HR which solves problems with LC_COLLATE, LC_ADDRESS
and LC_TELEPHONE sections

Fixed small typos in comments...

Reset the bug status to "NEW", to signify it's ready for review by mainteiners
of the library...

Thanks for your time,
N::

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug localedata/10580] New file for hr_HR localedata

[invisible@hidden-city.net]

http://sourceware.org/bugzilla/show_bug.cgi?id=10580

Dragan Stanojevic - Nevidljivi <invisible@hidden-city.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #4175|0                           |1
        is obsolete|                            |

--- Comment #19 from Dragan Stanojevic - Nevidljivi <invisible@hidden-city.net> 2013-02-19 06:32:41 UTC ---
Created attachment 6876
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6876
An updated version of hr_HR which solves problems with LC_COLLATE, LC_ADDRESS
and LC_TELEPHONE sections

This is promised update to the hr_HR locale.

Changes are:
- bumped revision to 2.1 and a date to current date
- removed duplicate character transliterations from LC_CTYPE which are found in
i18n
- changed LC_COLLATE error, and tested with the small Croatian dictionary
provided in 2009 using "sort -R dict_file > scrambled_file; sort scrambled_file
> sorted_file" md5 sums of original <dict_file> and <sorted_file> are the same
- updated some comments, and some spacings
- changed thousands_sep and mon_thousands_sep to " " instead of "." char to
comply with the suggestions in language books published since 2009.
- updated LC_ADDRESS to remove %n (persons name) field since it's not yet
available in the code. Other locales fall back to %a (care of person or
organization) and that's ok for now.
- cleaned LC_TELEPHONE by removing %t (space or null string) and %e (extension)
fields which are currently unsupported in the code. Falled back to "+%c %a %l"
and "%A %l" as seen in other locales.

Locale now compiles cleanly using localedef...

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: moderation of libc-licales list

[Carlos O'Donell]

On 02/16/2013 06:24 PM, Keld Simonsen wrote:
> I am one of the moderators of the libc-locales list.
> I am wondering what is happening there.
> I see messages to the list accepted before I  even get
> to accept the message. That is really fine with me,
> as these all are from people that send something useful.
> Presumably the senders are on the list allready.
> But I do not think the other moderator has had the time
> to do the acceptance. So it looks like the accptance
> has been done automatically.
> 
> So if some automatic acceptance is done, I would appreciate
> that the message is not also sent to me. Sometimes
> there are many messages and I have some difficulty finding out
> which messages allready have been accepted, and which have not,
> so I then go on accepting them all, after checking that
> they are not spam etc. That is a bit of a waste of time.
> 
> What is actually the procedure in effect here, and could it be improved?

There is no procedure in effect :-)

You can contact overseers@sourcware.org to determine if moderation
is enabled for libc-locales@sourceware.org.

My preference is that there be *no* moderation on this list, like
we have now for libc-alpha and libc-help.

I would suggest using filtering to remove email messages you
don't need.

Cheers,
Carlos.
 

Re: moderation of libc-licales list

[Keld Simonsen]

On Tue, Feb 19, 2013 at 10:36:46AM -0500, Carlos O'Donell wrote:
> On 02/16/2013 06:24 PM, Keld Simonsen wrote:
> > I am one of the moderators of the libc-locales list.
> > I am wondering what is happening there.
> > I see messages to the list accepted before I  even get
> > to accept the message. That is really fine with me,
> > as these all are from people that send something useful.
> > Presumably the senders are on the list allready.
> > But I do not think the other moderator has had the time
> > to do the acceptance. So it looks like the accptance
> > has been done automatically.
> > 
> > So if some automatic acceptance is done, I would appreciate
> > that the message is not also sent to me. Sometimes
> > there are many messages and I have some difficulty finding out
> > which messages allready have been accepted, and which have not,
> > so I then go on accepting them all, after checking that
> > they are not spam etc. That is a bit of a waste of time.
> > 
> > What is actually the procedure in effect here, and could it be improved?
> 
> There is no procedure in effect :-)
> 
> You can contact overseers@sourcware.org to determine if moderation
> is enabled for libc-locales@sourceware.org.
> 
> My preference is that there be *no* moderation on this list, like
> we have now for libc-alpha and libc-help.
> 
> I would suggest using filtering to remove email messages you
> don't need.

I would prefer moderation with a  whitelist of the people that are
on the list. Is that a possibility?

best regards
keld

Re: moderation of libc-licales list

[Carlos O'Donell]

On 02/19/2013 12:15 PM, Keld Simonsen wrote:
>> I would suggest using filtering to remove email messages you
>> don't need.
> 
> I would prefer moderation with a  whitelist of the people that are
> on the list. Is that a possibility?

My last discussion with overseers on this topic was that such a 
configuration was not supported by the current mailing list
software. Thus we made libc-alpha unmoderated.

I see no reason why libc-locales should not be unmoderated also.

Cheers,
Carlos.