On Mon, Jul 04, 2005 at 11:25:34PM +0200, Keld Jørn Simonsen wrote: > On Mon, Jul 04, 2005 at 01:15:09AM +0200, Denis Barbier wrote: > > Hi, > > > > I will give a talk about glibc locale data format during Debian > > conference > > http://www.debconf.org/debconf5/ > > next week (10-17th July) at Helsinki. > > The aim of this talk is to give clues about data format so that > > more people are interested in contributing to locale files. > > Slides are available at > > http://people.debian.org/~barbier/talks/debconf5/glibc-locale.pdf > > I am still polishing them, and will be glad to receive comments. > > A few comments:
I am very glad to hear from you, my knowledge of ISO 14652 history is of course weak. > ISO 14652 was approved as a TR last year. Ack, I will mention that. > on page 11, you say that 14652 is not always backwards compatible with > POSIX. Could you give examples? We did try hard to be backwards > compatible. This is emphasized when describing LC_TIME around slide 26; day and abday are not backward compatible, which is really annoying. You will answer that LC_IDENTIFICATION is meant to disambiguate those situations, but I disagree, application developers (like cal writers) should not have to worry about this field. This "issue" is also mentioned in appendix D of this TR. > On page 13, LC_VERSION is mentioned, and some talk about late drafts. > Is that meant to be late drafts of 14652? > If so I can assure you that there has not been anything about changing > LC_IDENTIFICATION to LC_VERSION. If it is not 14652, then I would like > to know what it is... It looks like I was confused; LC_VERSION and LC_VERSIONS appear in some drafts: http://www.open-std.org/jtc1/sc22/wg20/docs/14652fcd.txt http://www.open-std.org/jtc1/sc22/wg20/docs/n897-14652w25.pdf but LC_IDENTIFICATION is what is found in the technical report. I will remove all mentions of LC_VERSION* categories. > A date of 2004 should mean adherance to ISO TR 14652:2004 I will add it. > Page 26: 14652 is designed to be backwards compatible with POSIX. > That is, if you just have a LC_TIME spec conformant to POSIX, > it will work the same way in 14652. But you can with 14652 set the > first day of the week (In the USA this is Sunday, in most of Europe > this is Monday) and you can set different week numbering behaviours in > 14652, which is not possible in POSIX. > > Also the issue on the months, 14652 does allow you to specify that you > have 13 months in a year. Indeed, mon and abmon accept 13 month names, but how is the mapping performed since the "week" keyword has no "month" counterpart? > I think it is wrong to say that 14652 is not backwards compatible here. > Whether it is controversial could be true, many misunderstandings can > lead to heated discussions:-) > > Page 32: Why is .* useles? > People may write "no" or "yes", and the answer will still be recognized. > I know, you and I would never do that, but some newbies could. Because in a regular expression, ^[nN].* matches the exact same expression as ^[nN] > Maybe you could mention LC_PAPER - which is probably the most useful of > the new 14652 categories. Yes, I was wondering about adding it. My talk is already too long, so I do not know if I will write a new slide, but I will certainly mention it during the presentation. > Else it is good to see such talks! And I would like if you get comments > on it and probably missing features, if you could post such feedback to > the list. Thanks for your support, do not hesitate to harass me if I forget to send feedback ;) Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
