Author lemburg
Recipients lemburg, loewis, serhiy.storchaka
Date 2013-12-21.21:38:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <52B60A58.8070106@egenix.com>
In-reply-to <1387654406.9.0.104686216013.issue20046@psf.upfronthosting.co.za>
Content
On 21.12.2013 20:33, Serhiy Storchaka wrote:
> 
> Serhiy Storchaka added the comment:
> 
> Example.
> 
>      'br_fr':                                'br_FR.ISO8859-1',
> -    'br_fr.iso88591':                       'br_FR.ISO8859-1',
> -    'br_fr.iso885914':                      'br_FR.ISO8859-14',
> -    'br_fr.iso885915':                      'br_FR.ISO8859-15',
> -    'br_fr.iso885915@euro':                 'br_FR.ISO8859-15',
> -    'br_fr.utf8@euro':                      'br_FR.UTF-8',
> -    'br_fr@euro':                           'br_FR.ISO8859-15',
> 
> Only one of 7 br_fr entities are left. For br_fr.iso88591, br_fr.iso885914 and br_fr.iso885915 just replaced encoding of base br_fr locale. For br_fr.iso885915@euro and br_fr.utf8@euro the @euro modifier is dropped because ISO8859-15 and UTF-8 already contains the euro character. For br_fr@euro default ISO8859-1 encoding replaced to ISO8859-15 and the @euro modifier is dropped.
> 
> So now the table contains only base entities which map lang_country to lang_country.encoding and special cases for deprecated and obscure aliases.

Looks like an interesting approach, but I'd like to think about it
a day or two.

Some notes:
* the patch seems to include some unrelated changes, e.g. the
  devanagari fixes and a few new mappings
* the optimize step is called twice for some reason - is this
  intended ? if yes, please add a comment why this is done
* the patch would need some tests to make sure that the removed
  aliases indeed still map to the correct C locale strings

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com
History
Date User Action Args
2013-12-21 21:38:44lemburgsetrecipients: + lemburg, loewis, serhiy.storchaka
2013-12-21 21:38:44lemburglinkissue20046 messages
2013-12-21 21:38:44lemburgcreate