Fix for Xindy language options

[cgudrian]

Bugfix

Purpose

The current language options for Xindy do not work if there are variants involved (din5007, cyrillic, etc.). The reason is that Xindy's module lookup derives the variant from the language argument (-L) and not from the codepage argument (-C).

This patch has been tested with TeXLive 2019 (Xindy 2.5.1).

[tk0miya]

I'm not good at xindy. But it seems the man page of xindy says the variant is a part of codepage. So it should be passed via -C option.

Available Codepages
This is not yet written. You can look them up in your xindy distribution, in the modules/lang/language/ directory (where language is your language). They are named variant−codepage−lang.xdy, where variant− is most often empty (for german, it’s din5007 and duden; for spanish, it’s modern and traditional, etc.)
http://www.xindy.org/doc/xindy-man.pdf

@jfbu Could you check this please? I can't understand this is correct fix or not.

[cgudrian]

That part of the documentation describes how module names are composed – the variant is part of the module name, not part of the codepage.

Here is the relevant part of xindy.pl:

my @lang_base_dirs = ("$modules_dir/contrib/lang", "$modules_dir/lang");
my ($lang_dir, $variant);
foreach my $ld ( @lang_base_dirs ) {
    if ( -d "$ld/$language" ) {
        $lang_dir = "$ld/$language";
        last;
    } else {
        $language =~ /^([^-]*)-(.*)/ ; # language name ends with 1st hyphen
        if ( $2 && -d "$ld/$1" ) { # $2 is not set if the regex didn't match
            $language = $1;
            $lang_dir = "$ld/$language";
            $variant = "$2-"  unless ( $2 eq 'iso' );
            $variant eq 'din-'  and  $variant = 'din5007-';
            last;
        }
    }
}

In the else-Branch the $variant is extracted from the $language variable if it contains a hypen. If not, the $variant variable remains empty.

Digging deeper I've found out, why this has obviously been no problem before: I'm using XeLaTeX. And with XeLaTeX the @codepages variable gets explicitly set to qw(utf8) dropping the variant.

During regular LaTeX processing the module lookup works even with the mixed up language/variant setup. But that's just a coincidence due to the way Xindy builds up the module path names later on.

[cgudrian]

I did not find much documentation regarding the variant part, apart from this:

# Revision 1.4  2004/08/05 14:10:54  jschrod
#     Language variant names may have hyphens now. Language names must
# not have hyphens -- the first hyphen of the -L option argument
# separates language and variant name.

We must not confuse how the -L argument is interpreted with the way modules are named internally.

[cgudrian]

I've seen this is tagged as an "enhancement" while in fact it is a bugfix. Without these changes one cannot compile the generated documentation with XeTeX if using one of the affected languages. Should I file an appropriate bug report first?

[jfbu]

It seems I may have been misled by Xindy phrasing of documentation. @cgudrian are you sure this does not break regular pdflatex usage? if yes, then +1 for merge

[cgudrian]

The patch works for PDFLaTeX as well. xindy doesn't care about the TeX engine. However, the LaTeX builder does not set XINDYOPTS at all if the "pdflatex" engine is used. Is this another bug? Just found out about the latex_use_xindy option and can now confirm: PDFLaTeX now works (tested with a patched 2.4.4), since it has also been broken before (for the affected languages like German).

[tk0miya]

Thank you for detailed explanation. +1 for merging.

[tk0miya]

Merged. thank you for your work!

[cgudrian]

Well, thank you for your work!