[PATCH v4 4/4] Add generic C.UTF-8 locale (Bug 17318)

Carlos O'Donell carlos@redhat.com
Sun May 2 19:18:04 GMT 2021


On 4/30/21 2:20 PM, Florian Weimer wrote:
> * Carlos O'Donell:
> 
>> On 4/29/21 4:05 PM, Carlos O'Donell wrote:
>>> - LC_CTYPE, includes "translit_combining" which is wrong for a C locale IMO.
>>>   - Upstream C.UTF-8 includes no transliteration, all characters pass
>>>     through because UTF-8 supports all such characters.
>>
>> It turns out that this is related to bug 26984.
>>
>> I was wrong too, the C locale has a builtin set of ~1600 transliterations that
>> it uses internally (I even reviewed a patch for that you committed).
>> I had completely forgotten about this internal detail.
>>
>> This transliteration affects converters ability to use //TRANSLIT, and so I
>> think we should include all the netural transliterations e.g.
>>
>> translit_start
>> include "translit_neutral";""
>> translit_end
>>
>> This makes things *better* with respect to harmonization with Debian/Ubuntu.
>>
>> Thoughts?
>>
>> In summary:
>> - POSIX says nothing about transliteration.
>> - C/POSIX already includes a partial set of ~1600 translit entries, and they
>>   are largely incomplete. It would be nice to harmonize them with the proper
>>   translit_neutral set.
>> - C.UTF-8 including translit_neutral would bring in ~25,000 translit rules
>>   for conversions from UTF-8 to other charmaps. This would be a superset of
>>   those offered by C/POSIX.
>> - Fixing C/POSIX is another issue.
> 
> I'm in favor of including those transliterations.

Thanks. I'll spin a v5, test and repost.

I need to look at the size impact of the additional transliterations.

-- 
Cheers,
Carlos.



More information about the Libc-alpha mailing list