From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130505 invoked by alias); 25 Nov 2019 11:20:22 -0000 Mailing-List: contact libc-locales-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-locales-owner@sourceware.org Received: (qmail 130439 invoked by uid 48); 25 Nov 2019 11:20:18 -0000 From: "digitalfreak at lingonborough dot com" To: libc-locales@sourceware.org Subject: [Bug localedata/25206] strcoll sort result incorrect locale lv_LV.UTF-8 Date: Mon, 25 Nov 2019 11:20:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: localedata X-Bugzilla-Version: 2.31 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: digitalfreak at lingonborough dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2019-q4/txt/msg00079.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=3D25206 Rafal Luzynski changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |digitalfreak@lingonborough. | |com --- Comment #2 from Rafal Luzynski = --- Probably this should be addressed to Agris and I hope he is able to read th= is comment. (In reply to Carlos O'Donell from comment #0) > Created attachment 12082 [details] > lv_LV.UTF-8.in_sorted >=20 > In the downstream bug report: > https://bugzilla.redhat.com/show_bug.cgi?id=3D1696729 > [...] These details look suspicious to me for the following reasons. 1. The quoted rule says that "the string with capital letter is preferred".= =20 What does it mean "preferred"? To me it seems it means it should be sorted first. This rule would be difficult for us to implement because probably we would have to reorder all letters. I'm not sure if this is worth the effor= t.=20 But then the sample sort file lists uppercase letters second. Which is fine for me but contradicting the rule. 2. My understanding of the rule quoted above is that it should be applied w= hen the words differ only in the upper/lower case of the letter. The letters should be compared ignoring the case first. But the sample file sorts all uppercase words after all lowercase, for example: a ab abc ad ... az azzzxxyz A Abc Az AB Is this really what we want? I think that this rule would be very inconven= ient for the users because they would have to be aware of this rule all the time= and be ready to search for uppercased words always after the respective lowerca= se letters. 3. I totally understand and agree with one point. The letters 'a' and '=C4= =81' should be separated. For example, now we have: a =C4=81 ab =C4=81cc add =C4=81fe ah but if I understand correctly this should be: a ab add ah =C4=81 =C4=81cc =C4=81fe This is understandable and easy to implement but that means that we all were wrong, by "all" I mean including CLDR. But in order to confirm that CLDR w= as wrong I would like at least to see a ticket filed against CLDR and at least= see no objection at their side. 4. Please note that the current sorting rules for lv_LV distinguish letters= 'c' vs '=C4=8D', 'g' vs '=C4=A3', 'k' vs '=C4=B7' and several more. Do I under= stand correctly that those letters work fine and the same rule should be applied to 'a' vs = '=C4=81' and several more characters? (In reply to Carlos O'Donell from comment #1) > Created attachment 12083 [details] > lv_LV.UTF-8_with_more_chars_and_removed.in >=20 > Additional sorted file. 5. This does not look good to me, either. I mean, adding more test chars i= s a good idea but removing other test chars just because they are foreign to Latvian is not. The sorting rules must somehow deal with even the most exo= tic characters. This is the reason why we aim at starting the collating rules = with =E2=80=9Ccopy "iso14651_t1"=E2=80=9D which aims to include all Unicode char= acters and only then we add rules specific for the current language. TL;DR: If adding a rule to distinguish 'a' vs '=C4=81' plus several more si= milar characters is sufficient then we can easily implement this but the attached test cases need to be fixed. Otherwise we'll have to verify if the required rules are correct. --=20 You are receiving this mail because: You are on the CC list for the bug.