On Sun, Nov 23, 2025 at 05:23:15PM +0100, Patrice Dumas wrote: > The issue you unveiled with transliteration in C is more general than > what you experienced with @expansion on sectioning command line. In > every situation where transliteration happens, there will be encoding > errors output and the output will be suboptimal for some characters > corresponding to @-commands. I actually do not think that a suboptimal > output is so bad, because there should not be any case where > transliteration needs to be externally consistent. But the error > messages are definitively bad to me.
Yes, I agree. > One possibility could be to ignore the encoding errors when calling > encode_with_iconv from unicode_to_transliterate. That would actually > have my preference. My preference is not to transliterate at all. As I remember, the transliteration produces okay results for French, not so okay results for German (missing umlauts), and disasterous results for Japanese (phonetic transcriptions of Chinese syllables are used). I also think it could be confusing for users to have different output for XS and non-XS and this is something that cause problems in the future. As it is not particularly user-visible anyway, I don't have a strong preference, as long as the error messages go away (and the resulting fragment identifiers remain valid and unique). > Another possibility would be to design configure tests that test whether > transliteration with "us-ascii//TRANSLIT" enoding gives correct > results/doesn't set EILSEQ. This is not my preference because it is > more complex, and also because the test would necessarily be a run test, > and when cross-compiling the Perl transliteration would always be > chosen. Yes, I'd rather not add configure tests.
