On 15.10.2018 13:04, Marko Myllynen wrote: > Hi, > > On 2018-10-13 19:58, Egor Kobylkin wrote: >> On 13.10.2018 02:59, Rafal Luzynski wrote: >> >>> Regarding the tests, I think there is no complete transliteration >>> test suite at the moment. Probably the only test is >>> localedata/bug-iconv-trans.c. You can also see the collation tests >>> placed in the same directory, they use those multiple *.UTF-8.in >>> files. >>> >>> You can skip the tests for now. >> >> First I though they could just be added but not all locales >> transliterate Umlauts so just extending the current test won't do as it >> will fail for those locales. > > I still think a one-time check against uconv(1) (part of Unicode's ICU > project) for discrepancies. Just an addition. I have changes a few constants to see whether localedata/bug-iconv-trans.c could be made to test cyrillic. Attached is the bug-iconv-trans-cyr.c that goes through in this form. I had to save it as UTF-8 instead of ISO-8859-15 for localedata/bug-iconv-trans.c. >>>> [...] diff -uNr a/localedata/locales/am_ET >>>> b/localedata/locales/am_ET --- a/localedata/locales/am_ET >>>> 2018-10-11 15:10:11.000000000 +0000 +++ b/localedata/locales/am_ET >>>> 2018-10-11 15:10:43.000000000 +0000 @@ -1394,6 +1394,7 @@ >>>> >>>> +include >>>> "translit_cyrillic";"" translit_end % END LC_CTYPE >>> >>> Shouldn't “include "translit_cyrillic";""” be placed before the >>> custom rules, together with other includes? The same in more files, >>> I will not mention them all. >> >> If I recall correctly it is because of the >> "translit_end >> END LC_CTYPE" >> part at the end of the translit_cyrillic. This way it works for any >> locale, regardless whether it has translit itself or not. And being at >> the end it does not supersede any previous transliteration that may be >> there for a reason. > > I suspect one problem would be that the latter rule wins, so if there > are some locale-specific rules than possible translit_* inclusions would > override them if not included before the locale-specific rules. What is the best way forward here? Can somebody make an explicit suggestion on how to change the current approach if needed? Bests, Egor