[PATCH 5/5][v9] Update the i18n, UTF-8, and translit_* files to Unicode 8.0.0

[Carlos O'Donell]

On 12/10/2015 12:32 PM, Joseph Myers wrote:
> On Thu, 10 Dec 2015, Carlos O'Donell wrote:
> 
>>> There's also the matter of adding tr_TR LC_CTYPE updates to the Unicode 
>>> update automation (see bug 18491).
>>
>> Yes, it would require special automation to fix tr_TR.
>>
>> Shall I commit something like this?
> 
> How about fixing Turkish instead of documenting that it's unfixed?  Like 
> in this patch (testing pending).

Certainly, that's better than documenting it unfixed.

Please commit this when your testing is done, it looks
good to me. See below.

> Automate LC_CTYPE generation for tr_TR, update to Unicode 8.0.0.
> 
> This patch makes the automation of Unicode LC_CTYPE generation also
> support generating the modified LC_CTYPE used for Turkish (where case
> conversions of 'i' and 'I' differ from ASCII conventions), so allowing
> that to be more readily kept in sync for future Unicode updates.  The
> patch includes the locale update generated by the scripts.
> 
> 2015-12-10  Joseph Myers  <joseph@codesourcery.com>
> 
> 	[BZ #18491]
> 	* unicode-gen/unicode_utils.py (to_upper_turkish): New function.
> 	(to_lower_turkish): Likewise.
> 	* unicode-gen/gen_unicode_ctype.py (output_tables): Support
> 	producing output with Turkish case conversions.
> 	(--turkish): New command-line option.
> 	* unicode-gen/Makefile (GENERATED): Add tr_TR.
> 	(tr_TR): New rule.
> 	* locales/tr_TR: Regenerate LC_CTYPE.

The solution appears correct to me and avoids the duplication.

Manual inspection of tr_TR LC_CTYPE should be all that's required
really unless you want to write a test case for it? Which is never
a bad idea, but a bit of overkill.

Cheers,
Carlos.