From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Przemysław Sztoch <przemyslaw(at)sztoch(dot)pl> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Subject: | Re: [PATCH] Completed unaccent dictionary with many missing characters |
Date: | 2022-06-21 00:11:41 |
Message-ID: | YrEMvUs1bSBRz407@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 20, 2022 at 10:37:57AM +0200, Przemysław Sztoch wrote:
> But ligature check is performed on combining_ids (result of translation),
> not on base codepoint.
> Without it, you will get assertions in get_plain_letters.
Hmm. I am wondering if we could make the whole logic a bit more
intuitive here. The loop that builds the set of mappings gets now
much more complicated with the addition of the categories beginning by
N for the numbers, and that's mostly the same set of checks as the
ones applied for T.
> However, the current Latin-ASCII.xml suggests a conversion to x.
> I found an open discussion on the internet about this and the suggestion
> that the Latin-ASCII.xml file should be corrected for this letter.
> But I wouldn't expect that Unicode makes the revised Latin-ASCII.xml quickly
> into the official repo.
Yeah, Latin-ASCII.xml is getting it wrong here, then. unaccent
fetches the thing from this URL currently:
https://raw.githubusercontent.com/unicode-org/cldr/release-41/common/transforms/Latin-ASCII.xml
Could it be better to handle that as an exception in
generate_unaccent_rules.py, documenting why we are doing it this way
then? My concern is somebody re-running the script without noticing
this exception, and the set of rules would be blindly, and
incorrectly, updated.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2022-06-21 00:53:43 | Re: [PATCH] Completed unaccent dictionary with many missing characters |
Previous Message | Michael Paquier | 2022-06-20 23:58:38 | Re: CFM for 2022-07 |