From cldr-users at unicode.org Wed Jul 25 04:16:36 2018 From: cldr-users at unicode.org (Denis Jacquerye via CLDR-Users) Date: Wed, 25 Jul 2018 10:16:36 +0100 Subject: =?UTF-8?Q?Igbo_=5Big=5D_exemplar_characters_set_should_not_have_?= =?UTF-8?Q?=E1=BA=B9?= Message-ID: Hi, I?m posting this here since the spambot refuses to let me open new issues on the Bug Tracking site. ? U+1EB9 doesn?t seem to be used in Igbo, yet it is listed in the CLDR Igbo [ig] locale default exemplar characters set. It cannot be found in: - Igbo Wikipedia site - BBC Igbo site - Wikipedia Igbo Language article - Kay Williamson, *Dictionary of O??ni??cha? Igbo*, 2006 - Yvonne C. Mbanefo, *Okowaokwu Igbo Umuaka : Igbo Dictionary for Children*, 2016 - Windows Igbo keyboard layout - I haven?t checked Ayo Bamgbose, Orthographies of Nigerian languages: manual I, Lagos, Federal Ministry of Education, National Language Centre, 1982. ? U+1EB9 should be removed from the Igbo [ig] default exemplar characters set Cheers, -- Denis Moyogo Jacquerye -------------- next part -------------- An HTML attachment was scrubbed... URL: From cldr-users at unicode.org Wed Jul 25 04:40:08 2018 From: cldr-users at unicode.org (Marcel Schneider via CLDR-Users) Date: Wed, 25 Jul 2018 11:40:08 +0200 (CEST) Subject: =?UTF-8?Q?Re:_Igbo_[ig]_exemplar_characters_set_should_not_have_=E1=BA=B9?= In-Reply-To: References: Message-ID: <738445478.4216.1532511608734.JavaMail.www@wwinf1m18> On 25/07/18 11:20, Denis Jacquerye via CLDR-Users wrote: > > I?m posting this here since the spambot refuses to let me open new issues on the Bug Tracking site. I?m sorry about that. Issues with Akismet are common. Once I?ve filed a sidenote: http://unicode.org/cldr/trac/ticket/11223 It has been accepted, and hopefully we?ll be able to log in for filing tickets, getting around that aggressive spam checker. Cheers, Marcel From cldr-users at unicode.org Wed Jul 25 12:34:17 2018 From: cldr-users at unicode.org (Hugh Paterson via CLDR-Users) Date: Wed, 25 Jul 2018 10:34:17 -0700 Subject: =?UTF-8?Q?Re=3A_Igbo_=5Big=5D_exemplar_characters_set_should_not_hav?= =?UTF-8?Q?e_=E1=BA=B9?= In-Reply-To: <738445478.4216.1532511608734.JavaMail.www@wwinf1m18> References: <738445478.4216.1532511608734.JavaMail.www@wwinf1m18> Message-ID: The entry in Alphabets of Africa (1993) (for Igbo) also does not have the under-dotted < e >: https://www.sil.org/resources/archives/5133 The Igbo writing system (1961 by S. E. Onwu) as reported by Conrad Taylor in Typesetting African Languages does not have under-dotted < e > However it is argued for in this paper: https://doi.org/10.2478/v10010-007-0009-0 FWIW - Hugh On Wed, Jul 25, 2018 at 2:40 AM, Marcel Schneider via CLDR-Users < cldr-users at unicode.org> wrote: > On 25/07/18 11:20, Denis Jacquerye via CLDR-Users wrote: > > > > I?m posting this here since the spambot refuses to let me open new > issues on the Bug Tracking site. > > I?m sorry about that. Issues with Akismet are common. Once I?ve filed a > sidenote: > http://unicode.org/cldr/trac/ticket/11223 > It has been accepted, and hopefully we?ll be able to log in for filing > tickets, getting around that aggressive spam checker. > > Cheers, > Marcel > > _______________________________________________ > CLDR-Users mailing list > CLDR-Users at unicode.org > http://unicode.org/mailman/listinfo/cldr-users > -- *Hugh Paterson III *Innovation Analyst *Innovation Development & Experimentation*, *SIL International* *Web*: Contact & CV *Video chat: *Appear in *Skype*: misionpilot *Time Zone*: UTC-7/8 *Collaborative Note Pad*: Spline -------------- next part -------------- An HTML attachment was scrubbed... URL: From cldr-users at unicode.org Wed Jul 25 13:15:49 2018 From: cldr-users at unicode.org (Denis Jacquerye via CLDR-Users) Date: Wed, 25 Jul 2018 19:15:49 +0100 Subject: =?UTF-8?Q?Re=3A_Igbo_=5Big=5D_exemplar_characters_set_should_not_hav?= =?UTF-8?Q?e_=E1=BA=B9?= In-Reply-To: References: <738445478.4216.1532511608734.JavaMail.www@wwinf1m18> Message-ID: That paper, Ugorji 2007, argues that the standard Igbo alphabet, the Onwu alphabet, should be extended to accomodate Igbo variants or dialects and has e? among other additions like ?, t? or z? that are not in the standard Igbo alphabet. The CLDR Igbo default exemplar character set should represent the current standard Igbo alphabet. If that character or others occur in Igbo documents but are not part of the standard orthography, they should be in the auxiliary exemplar character set. On Wed, 25 Jul 2018 at 18:34, Hugh Paterson wrote: > The entry in Alphabets of Africa (1993) (for Igbo) also does not have the > under-dotted < e >: https://www.sil.org/resources/archives/5133 > > The Igbo writing system (1961 by S. E. Onwu) as reported by Conrad Taylor > in Typesetting African Languages does not have under-dotted < e > > > However it is argued for in this paper: > https://doi.org/10.2478/v10010-007-0009-0 > > FWIW > - Hugh > > > On Wed, Jul 25, 2018 at 2:40 AM, Marcel Schneider via CLDR-Users < > cldr-users at unicode.org> wrote: > >> On 25/07/18 11:20, Denis Jacquerye via CLDR-Users wrote: >> > >> > I?m posting this here since the spambot refuses to let me open new >> issues on the Bug Tracking site. >> >> I?m sorry about that. Issues with Akismet are common. Once I?ve filed a >> sidenote: >> http://unicode.org/cldr/trac/ticket/11223 >> It has been accepted, and hopefully we?ll be able to log in for filing >> tickets, getting around that aggressive spam checker. >> >> Cheers, >> Marcel >> >> _______________________________________________ >> CLDR-Users mailing list >> CLDR-Users at unicode.org >> http://unicode.org/mailman/listinfo/cldr-users >> > > > > -- > *Hugh Paterson III *Innovation Analyst > *Innovation Development & Experimentation*, *SIL International* > > *Web*: Contact & CV > *Video chat: *Appear in > *Skype*: misionpilot > *Time Zone*: UTC-7/8 > *Collaborative Note Pad*: Spline > > > -- Denis Moyogo Jacquerye -------------- next part -------------- An HTML attachment was scrubbed... URL: From cldr-users at unicode.org Wed Jul 25 13:55:00 2018 From: cldr-users at unicode.org (Hugh Paterson via CLDR-Users) Date: Wed, 25 Jul 2018 11:55:00 -0700 Subject: =?UTF-8?Q?Re=3A_Igbo_=5Big=5D_exemplar_characters_set_should_not_hav?= =?UTF-8?Q?e_=E1=BA=B9?= In-Reply-To: References: <738445478.4216.1532511608734.JavaMail.www@wwinf1m18> Message-ID: @Denis, Agreed. Is there a source authority for the content in CLDR? I know there is the recommendation system; with voting. But I don't recall any pointers to source authorities. I recall looking at various old Igbo Bible texts, but I was also looking at Yoruba at the same time and I don't have my notes in front of me (and Yoruba does have under-dotted < e > ). Also, in reference to an alphabet in the past which is not the current standard, how does CLDR represent that? On Wed, Jul 25, 2018 at 11:15 AM, Denis Jacquerye wrote: > That paper, Ugorji 2007, argues that the standard Igbo alphabet, the Onwu > alphabet, should be extended to accomodate Igbo variants or dialects and > has e? among other additions like ?, t? or z? that are not in the standard > Igbo alphabet. > The CLDR Igbo default exemplar character set should represent the current > standard Igbo alphabet. > If that character or others occur in Igbo documents but are not part of > the standard orthography, they should be in the auxiliary exemplar > character set. > > On Wed, 25 Jul 2018 at 18:34, Hugh Paterson wrote: > >> The entry in Alphabets of Africa (1993) (for Igbo) also does not have the >> under-dotted < e >: https://www.sil.org/resources/archives/5133 >> >> The Igbo writing system (1961 by S. E. Onwu) as reported by Conrad >> Taylor in Typesetting African Languages does not have under-dotted < e > >> >> However it is argued for in this paper: https://doi.org/10. >> 2478/v10010-007-0009-0 >> >> FWIW >> - Hugh >> >> >> On Wed, Jul 25, 2018 at 2:40 AM, Marcel Schneider via CLDR-Users < >> cldr-users at unicode.org> wrote: >> >>> On 25/07/18 11:20, Denis Jacquerye via CLDR-Users wrote: >>> > >>> > I?m posting this here since the spambot refuses to let me open new >>> issues on the Bug Tracking site. >>> >>> I?m sorry about that. Issues with Akismet are common. Once I?ve filed a >>> sidenote: >>> http://unicode.org/cldr/trac/ticket/11223 >>> It has been accepted, and hopefully we?ll be able to log in for filing >>> tickets, getting around that aggressive spam checker. >>> >>> Cheers, >>> Marcel >>> >>> _______________________________________________ >>> CLDR-Users mailing list >>> CLDR-Users at unicode.org >>> http://unicode.org/mailman/listinfo/cldr-users >>> >> >> >> >> -- >> *Hugh Paterson III *Innovation Analyst >> *Innovation Development & Experimentation*, *SIL International* >> >> *Web*: Contact & CV >> *Video chat: *Appear in >> *Skype*: misionpilot >> *Time Zone*: UTC-7/8 >> *Collaborative Note Pad*: Spline >> >> >> > > -- > Denis Moyogo Jacquerye > -- *Hugh Paterson III *Innovation Analyst *Innovation Development & Experimentation*, *SIL International* *Web*: Contact & CV *Video chat: *Appear in *Skype*: misionpilot *Time Zone*: UTC-7/8 *Collaborative Note Pad*: Spline -------------- next part -------------- An HTML attachment was scrubbed... URL: From cldr-users at unicode.org Wed Jul 25 14:36:08 2018 From: cldr-users at unicode.org (Richard Wordingham via CLDR-Users) Date: Wed, 25 Jul 2018 20:36:08 +0100 Subject: Igbo [ig] exemplar characters set should not have =?UTF-8?B?4bq5?= In-Reply-To: References: <738445478.4216.1532511608734.JavaMail.www@wwinf1m18> Message-ID: <20180725203608.5e132f93@JRWUBU2> On Wed, 25 Jul 2018 11:55:00 -0700 Hugh Paterson via CLDR-Users wrote: > Also, in reference to an alphabet in the past which is not the current > standard, how does CLDR represent that? Different locale! Also, there's nothing to stop a keyboard supporting auxiliary characters. The handling of the old spelling of names could be awkward - I can certainly imagine exemplar characters only used in names. Richard. From cldr-users at unicode.org Fri Jul 27 15:18:37 2018 From: cldr-users at unicode.org (Marcel Schneider via CLDR-Users) Date: Fri, 27 Jul 2018 22:18:37 +0200 (CEST) Subject: Unable to follow instruction of ST Admin (per e-mail) Message-ID: <1221683490.12595.1532722717172.JavaMail.www@wwinf1m18> Admin e-mail from Survey Tool urges us to (2.) address and fix any error in our locale. Only very few errors can actually be fixed, while others that came up during vetting phase cannot, by lack of write privileges, or by lack of response to tickets and forum threads. After posting and filing, we shouldn?t wait until the extended deadline, as we don?t know whether a TC member can eventually pick each issue. A read-only vetting phase (with a few exceptions at SurveyTool?s discretion) is pointless. Better we were urged to complete submission by a pre-deadline, and then to focus on vetting. addressing and fixing by final deadline. We are unable to follow instruction #2 in ST admin message from this evening. Regards, Marcel P.S. I?m on the computer because we cannot see the lunar eclipse due to cloudy sky. From cldr-users at unicode.org Fri Jul 27 16:15:18 2018 From: cldr-users at unicode.org (Marcel Schneider via CLDR-Users) Date: Fri, 27 Jul 2018 23:15:18 +0200 (CEST) Subject: Unable to follow instruction of ST Admin (per e-mail) Message-ID: <193832359.12915.1532726118668.JavaMail.www@wwinf1m18> Better to quote the original e-mail, now attached below. ? Admin e-mail from Survey Tool urges us to (2.) address and fix any error in our locale. Only very few errors can actually be fixed, while others that came up during vetting phase cannot, by lack of write privileges, or by lack of response to tickets and forum threads. After posting and filing, we shouldn?t wait until the extended deadline, as we don?t know whether a TC member can eventually pick each issue. A read-only vetting phase (with a few exceptions at SurveyTool?s discretion) is pointless. Better we were urged to complete submission by a pre-deadline, and then to focus on vetting. addressing and fixing by final deadline. We are unable to follow instruction #2 in ST admin message from this evening. Please note below that we are both welcome to ?consider whether or not [we] would like to make a change,? and ?address every and fix error in [our] locale.? Actually we cannot ?make a change? except in votes *if* we have more than 1 option, and except in those rare items that still are in the benefit of an edit button. And we cannot ?fix *every* error,? for the same reasons. 7 weeks are not enough to discuss and fix all the data, including writing up the required forum posts and bug reports. Now we?re all caught, as you ask us to do things that you don?t grant us the privileges of doing. Regards, Marcel P.S. I?m on the computer because we cannot see the lunar eclipse due to cloudy sky. ? > Message du 27/07/18 20:01 > De : "CLDR SurveyTool" > A : "Marcel Schneider" > Copie ? : > Objet : CLDR SurveyTool message from admin > > This message is being sent to you on behalf of admin" (Survey Tool) - user #1 > SurveyTool Message --- > The vetting period has been extended to next Monday at 8:00 am Pacific Time, due to the automatic mail generation for forum entries being blocked for some days. > > 1. Please look at the forum posts for your language back to July 10, and consider whether or not you would like to make a change. > > 2. Please also address every and fix error in your locale > > ? You can, however, skip the problems with the currencies VES and VEF: the committee will address those. > > ? For minimal pairs, please read the new information in > http://cldr.unicode.org/index/cldr-spec/plural-rules#TOC-Determining-Plural-Categories > -------- > > Survey Tool: http://st.unicode.org/cldr-apps/survey > > > ---------- > This email was generated automatically as part of the CLDR survey process > http://www.unicode.org/cldr > If you have any questions about it, > please contact your organization's CLDR Technical Committee member, > or: surveytool at unicode.org > TO UNSUBSCRIBE: You must permanently disable your account to stop receiving these emails. See: > From cldr-users at unicode.org Fri Jul 27 21:38:33 2018 From: cldr-users at unicode.org (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?= via CLDR-Users) Date: Fri, 27 Jul 2018 19:38:33 -0700 Subject: Unable to follow instruction of ST Admin (per e-mail) In-Reply-To: <1221683490.12595.1532722717172.JavaMail.www@wwinf1m18> References: <1221683490.12595.1532722717172.JavaMail.www@wwinf1m18> Message-ID: By "errors", we mean those in the Dashboard. Those need to be fixed, one way or another, before v34 is released so that . It should have been more clearly stated in the message. As for disputes between vetters, there is always room for improving the process, and we are looking at ways to encourage more effective participation and use of the forums in settling disputes. Right now, people can't tell what it means when nobody responds to their posts. For example, it could mean (a) people didn't see the post, or (b) people saw the post but disagreed with it (seeing no reason to change their votes), or some other reason. In the past, we were only showing the forum posts from the current release, but we are now preserving all of them. That way people will be able to see and consider the threads in the next cycle(s) of submission. We also now have a full-time engineer working to remove some of the worst "rough edges" in the tool, so we're prioritizing the tickets to try to get the highest ROI ones fixed for the next cycle. Mark On Fri, Jul 27, 2018 at 1:18 PM, Marcel Schneider via CLDR-Users < cldr-users at unicode.org> wrote: > Admin e-mail from Survey Tool urges us to (2.) address and fix any error > in our locale. > Only very few errors can actually be fixed, while others that came up > during vetting phase > cannot, by lack of write privileges, or by lack of response to tickets and > forum threads. > After posting and filing, we shouldn?t wait until the extended deadline, > as we don?t know > whether a TC member can eventually pick each issue. > > A read-only vetting phase (with a few exceptions at SurveyTool?s > discretion) is pointless. > Better we were urged to complete submission by a pre-deadline, and then to > focus on > vetting. addressing and fixing by final deadline. > > We are unable to follow instruction #2 in ST admin message from this > evening. > > Regards, > Marcel > P.S. I?m on the computer because we cannot see the lunar eclipse due to > cloudy sky. > > _______________________________________________ > CLDR-Users mailing list > CLDR-Users at unicode.org > http://unicode.org/mailman/listinfo/cldr-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cldr-users at unicode.org Sat Jul 28 02:56:08 2018 From: cldr-users at unicode.org (Marcel Schneider via CLDR-Users) Date: Sat, 28 Jul 2018 09:56:08 +0200 (CEST) Subject: Unable to follow instruction of ST Admin (per e-mail) In-Reply-To: References: <1221683490.12595.1532722717172.JavaMail.www@wwinf1m18> Message-ID: <1117563654.1742.1532764569021.JavaMail.www@wwinf1m18> On 28/07/18 04:38, Mark Davis ?? wrote: > > By "errors", we mean those in the Dashboard. Those need to be fixed, one way or another, > before v34 is released so that . It should have been more clearly stated in the message. There was actually a set of red-flagged errors, that have been fixed following your instructions and Philippe Verdy?s recommendation. Seeing these in the dashboard was useful, ST heuristics made that possible as they succeed in catching conflicts. However we?ve been lucky, given ST typically red-flags only one side of a conflicting pair, and it happened to be the right one. That is not always true. Better to flag both sides, so vetters can always pick the one that is actually to be changed. But many many errors are not caught by ST heuristics, such as a short form mistakenly used where a long form is required (2+1 items were overlooked). ST already checks the length of the narrow forms. It could check, too, for consistent length between long and short forms. But that would merely allow to red-flag those errors, allowing vetters to fix them. Now we?re aware of these 3 items, as they came up in the vetting phase, but for 2 of them there are even no means to fix them any more. A set of other items are not fixed because ST diverted vetters from upvoting them, by wrongly flagging them as "fallback" with darker blue background as if they were inherited from English, while actually they?ve been added during survey. As many as 4 instances fall under this category. This ST bug has been reported in ticket 11298. http://unicode.org/cldr/trac/ticket/11298 The casing issue with the names of the signs of the zodiac is fixed in fr-CA but should be so in fr. ST should red-flag those items. It already checks whether sublocales are diverging on a given item, so it should simply put them on the dashboard, because of multiple cases where various sublocales corrected on their part instead of correcting fr for inheritance. By what I consider as a design mistake, the narrow display forms of measurement units are excluded from coverage level "Modern". Many organizations don?t allow their vetters to work under coverage Comprehensive, or did allow in one era and forbid in present days, so that people are prevented from checking and fixing the errors, let alone that narrow display forms don?t have enough support. So that part of CLDR is simply unusable, and CLDR/ICU are deceiving users by delivering sort of fake data simply because whole categories are added and then vetters are discouraged from catering for the data. >From all that it becomes clear we should not narrow error-fixing to the dashboard, nor to coverage level "Modern"; and that if nonetheless we do, many errors pass through, and the release is unreliable and has limited usability. > As for disputes between vetters, Sorry, we don?t have any ?disputes?. > there is always room for improving the process, and we are looking at ways to encourage more effective > participation and use of the forums in settling disputes. That is always a good concern. The big big problem in use of ST fora is in alert settings. Actually we get alerts from any post, including those that we?ve posted ourselves. Sorry to say bluntly that this is sheer nonsense as it annihilates effectiveness of those alerts that are really relevant as coming from co-vetters, actually drowned in a flood of e-mails of similarly looking sender (not completed with submitter name as from the mailing lists). That is how I happened missing other people?s posts, as I?m unwilling to open dozens of alerts bringing to me some content I already know for having posted it myself. I?ve filed a ticket about that on July 13: http://unicode.org/cldr/trac/ticket/11266 > Right now, people can't tell what it means when nobody responds to their posts. In these days, my only concern with forum posts is that *no TC member* does respond in any of our threads. (Except in fr-CA threads.) > For example, it could mean (a) people didn't see the post, See above about how that typically happens. > or (b) people saw the post but disagreed with it (seeing no reason to change their votes), or some other reason. OK sometimes I saw a post but was so busy with submitting data that I?d no mind left over, or didn?t make up my mind until I came round another day. Regularly browsing the forum is very important, and that?s the way I ultimately found threads and posts I wasn?t aware of. But again, that?s unrelated to my actual concern about TC review. > In the past, we were only showing the forum posts from the current release, but we are now preserving all of them. > That way people will be able to see and consider the threads in the next cycle(s) of submission. Very good. Thanks! > We also now have a full-time engineer working to remove some of the worst "rough edges" in the tool, > so we're prioritizing the tickets to try to get the highest ROI ones fixed for the next cycle. What would have been the Right Thing to Do is just copy-paste the provided patch into survey.js for ST to display the confusable spaces in a useful way. That feature alone, requested on June 29, with patches posted from July 7?10, would significantly reduce the amount of time required for survey, actually with the use of a JS function in the browser console. And hence if timely implemented as requested, it would have drastically reduced the error rate. It will be useful to check letter apostrophe and an extensible set of other characters as well. See: http://unicode.org/cldr/trac/ticket/11235 I?ve pleaded for high priority on July 10: http://unicode.org/cldr/trac/ticket/11235#comment:18 Best regards, Marcel From cldr-users at unicode.org Sat Jul 28 03:26:00 2018 From: cldr-users at unicode.org (Marcel Schneider via CLDR-Users) Date: Sat, 28 Jul 2018 10:26:00 +0200 (CEST) Subject: Unable to follow instruction of ST Admin (per e-mail) Message-ID: <1603015160.2100.1532766360408.JavaMail.www@wwinf1m18> Sorry, ultimately below I forgot to mention a typo I left in 2 values so they couldn?t be upvoted, leaving inconsistent data because we aren?t able to correct any value during the vetting phase. That is documented on the forum (but ST fora cannot be viewed without credentials) and in ticket 11296: http://unicode.org/cldr/trac/ticket/11296 Another way to fix that problem, if write privileges must be refused during vetting, is to add an edit button to each value a given contributor added during survey, so everybody will be able to correct his or her own data, while being forbidden to add values to other items. But still the efficiency and ROI of that scheme is doubtful as it wouldn?t allow to fix issue 4 below (cf. note to #4 below). On 28/07/18 04:38, Mark Davis ?? wrote: > > By "errors", we mean those in the Dashboard. Those need to be fixed, one way or another, > before v34 is released so that . It should have been more clearly stated in the message. #1 There was actually a set of red-flagged errors, that have been fixed following your instructions and Philippe Verdy?s recommendation. Seeing these in the dashboard was useful, ST heuristics made that possible as they succeed in catching conflicts. However we?ve been lucky, given ST typically red-flags only one side of a conflicting pair, and it happened to be the right one. That is not always true. Better to flag both sides, so vetters can always pick the one that is actually to be changed. #2 But many many errors are not caught by ST heuristics, such as a short form mistakenly used where a long form is required (2+1 items were overlooked). ST already checks the length of the narrow forms. It could check, too, for consistent length between long and short forms. But that would merely allow to red-flag those errors, allowing vetters to fix them. Now we?re aware of these 3 items, as they came up in the vetting phase, but for 2 of them there are even no means to fix them any more. #3 A set of other items are not fixed because ST diverted vetters from upvoting them, by wrongly flagging them as "fallback" with darker blue background as if they were inherited from English, while actually they?ve been added during survey. As many as 4 instances fall under this category. This ST bug has been reported in ticket 11298. http://unicode.org/cldr/trac/ticket/11298 #4 The casing issue with the names of the signs of the zodiac is fixed in fr-CA but should be so in fr. ST should red-flag those items. It already checks whether sublocales are diverging on a given item, so it should simply put them on the dashboard, because of multiple cases where various sublocales corrected on their part instead of correcting fr for inheritance. Note: Issue 4 came up during vetting, while another issue related to these items was discussed with respect to fr-CA. During submission I didn?t get aware as I hadn?t enough time to review all data. See my second e-mail in this thread: http://unicode.org/pipermail/cldr-users/2018-July/000806.html #5 By what I consider as a design mistake, the narrow display forms of measurement units are excluded from coverage level "Modern". Many organizations don?t allow their vetters to work under coverage Comprehensive, or did allow in one era and forbid in present days, so that people are prevented from checking and fixing the errors, let alone that narrow display forms don?t have enough support. So that part of CLDR is simply unusable, and CLDR/ICU are deceiving users by delivering sort of fake data simply because whole categories are added and then vetters are discouraged from catering for the data. >From all that it becomes clear we should not narrow error-fixing to the dashboard, nor to coverage level "Modern"; and that if nonetheless we do, many errors pass through, and the release is unreliable and has limited usability. > As for disputes between vetters, Sorry, we don?t have any ?disputes?. > there is always room for improving the process, and we are looking at ways to encourage more effective > participation and use of the forums in settling disputes. That is always a good concern. The big big problem in use of ST fora is in alert settings. Actually we get alerts from any post, including those that we?ve posted ourselves. Sorry to say bluntly that this is sheer nonsense as it annihilates effectiveness of those alerts that are really relevant as coming from co-vetters, actually drowned in a flood of e-mails of similarly looking sender (not completed with submitter name as from the mailing lists). That is how I happened missing other people?s posts, as I?m unwilling to open dozens of alerts bringing to me some content I already know for having posted it myself. I?ve filed a ticket about that on July 13: http://unicode.org/cldr/trac/ticket/11266 > Right now, people can't tell what it means when nobody responds to their posts. In these days, my only concern with forum posts is that *no TC member* does respond in any of our threads. (Except in fr-CA threads.) > For example, it could mean (a) people didn't see the post, See above about how that typically happens. > or (b) people saw the post but disagreed with it (seeing no reason to change their votes), or some other reason. OK sometimes I saw a post but was so busy with submitting data that I?d no mind left over, or didn?t make up my mind until I came round another day. Regularly browsing the forum is very important, and that?s the way I ultimately found threads and posts I wasn?t aware of. But again, that?s unrelated to my actual concern about TC review. > In the past, we were only showing the forum posts from the current release, but we are now preserving all of them. > That way people will be able to see and consider the threads in the next cycle(s) of submission. Very good. Thanks! > We also now have a full-time engineer working to remove some of the worst "rough edges" in the tool, > so we're prioritizing the tickets to try to get the highest ROI ones fixed for the next cycle. What would have been the Right Thing to Do is just copy-paste the provided patch into survey.js for ST to display the confusable spaces in a useful way. That feature alone, requested on June 29, with patches posted from July 7?10, would significantly reduce the amount of time required for survey, actually with the use of a JS function in the browser console. And hence if timely implemented as requested, it would have drastically reduced the error rate. It will be useful to check letter apostrophe and an extensible set of other characters as well. See: http://unicode.org/cldr/trac/ticket/11235 I?ve pleaded for high priority on July 10: http://unicode.org/cldr/trac/ticket/11235#comment:18 Best regards, Marcel From cldr-users at unicode.org Sat Jul 28 10:28:02 2018 From: cldr-users at unicode.org (Marcel Schneider via CLDR-Users) Date: Sat, 28 Jul 2018 17:28:02 +0200 (CEST) Subject: Unable to follow instruction of ST Admin (per e-mail) Message-ID: <1835532384.5772.1532791682272.JavaMail.www@wwinf1m18> The bug report about inaccurate flagging of values as inherited fallback in SurveyTool is now completed: ? http://unicode.org/cldr/trac/ticket/11298#comment:2 ? I think this is worth fixing for next survey. But unlike implementing confusables display that is done in? no time (as of the remaining copy-paste), this may require an unknown amount of work and thus might? be postponed with a caveat in the guidelines, if only the spaces and other confusables are displayed as? named entities (additionally to display as literals) like what is already done for RLM and LRM where I?ve? taken the code from. ? Regards, Marcel ? > #3 A set of other items are not fixed because ST diverted vetters from upvoting them, by wrongly? > flagging them as "fallback" with darker blue background as if they were inherited from English,? > while actually they?ve been added during survey. As many as 4 instances fall under this category. > This ST bug has been reported in ticket 11298. > http://unicode.org/cldr/trac/ticket/11298 ? From cldr-users at unicode.org Sun Jul 29 02:11:04 2018 From: cldr-users at unicode.org (Marcel Schneider via CLDR-Users) Date: Sun, 29 Jul 2018 09:11:04 +0200 (CEST) Subject: Ordinal Minimal Pairs Message-ID: <572231998.497.1532848264735.JavaMail.www@wwinf1g32> CLDR features short forms of ordinals in an element called in /main/. About this, new information has been linked in the aforementioned e-mail as a warning for vetters: http://cldr.unicode.org/index/cldr-spec/plural-rules#TOC-Determining-Plural-Categories We?re urged not to merely translate what is found in English if that doesn?t account for what we have in our locales, and to file a ticket whenever the required data exceeds what can be done in SurveyTool. For instance it seems that we need some new attributes if CLDR should provide all forms of ordinal indicators used in French. Please see ticket #11302: http://unicode.org/cldr/trac/ticket/11302 My concern is whether there is a demand on CLDR user side for complete sets of ordinal indicators including plural forms, or whether the data can be limited to what is typically used in GPS. Another point of concern is about formatting and display. Regular ordinal indicators in French and a set of other Latin script using languages are superscripted, and require the use of preformatted superscript letters in plain text, ie the data format of CLDR (inside LDML), to be truly Unicode conformant wrt accuracy and interoperability. Depending on font size, an implementation may convert these superscripts to base letters, but I think CLDR should not enforce that by default. This is a call for feedback to the attention of the industry and everyone involved and/or interested in CLDR. I wish to use this occasion to apologize for the outburst of wrath in my past e-mails [1] [2] about SurveyTool. In fact the set of converging misadventures is not complete without what I did not tell, and that is about varying efficiency of its GUI depending on the sections we?re working on. Please see: http://unicode.org/cldr/trac/ticket/11250 http://unicode.org/cldr/trac/ticket/11253 I highly recommend using SurveyTool?s upload functionality whenever submitting and voting by clicking and typing gets wearisome, as opposed to upstream use of a plain text editor. Regards, Marcel [1] http://unicode.org/pipermail/cldr-users/2018-July/000808.html [2] http://unicode.org/pipermail/cldr-users/2018-July/000809.html From cldr-users at unicode.org Tue Jul 31 01:54:46 2018 From: cldr-users at unicode.org (Rachna Goel via CLDR-Users) Date: Tue, 31 Jul 2018 12:24:46 +0530 Subject: Regarding display names for "America/Santa_Isabel" and "America/Tijuana" timezone. Message-ID: <26937db2-e854-fcb1-2992-ea4a57925a61@oracle.com> Hi, CLDR 33 declares "America/Santa_Isabel" timezone as an alias of "America/Tijuana" timezone. Ideally these two zones then should have same display names. But "America/Tijuana" has been using America_Pacific metazone and "America/Santa_Isabel" using Mexico_Northwest .(In Metazones.xml) So, Both America_Pacific and Mexico_Northwest currently have different display names. Is this a bug in CLDR data? or am I missing something here? -- Thanks, Rachna -------------- next part -------------- An HTML attachment was scrubbed... URL: