Bug Tracker 
I’m currently working on a major new version of the datatool package. This may take a while. Please be patient. (Experimental version available for testing.)
| ID | 3🔗 |
|---|---|
| Date: | 2012-10-27 09:33:00 |
| Status | Closed (Fixed) |
| Category | glossaries |
| Version | v3.04 |
| Summary | xindy can't find module for language german |
Sign in to subscribe to notifications about this report.
Description
When the document language is (n)german and the inputenc package is loaded xindy currently can't find a suitable module and thus has to resort to language "general" in the end.Excerpt from the terminal output generated by makeglossaries:
xindy -L german -C utf8 -I xindy ... Cannot locate xindy module for language german in codepage utf8. Retrying using default codepage. xindy -L german -I xindy ... Cannot locate xindy module for language german. Retrying with -L general xindy -L general -I xindy ... Opening logfile ...
MWE
Download (264B)
\documentclass[ngerman]{article}
\usepackage{babel}
\usepackage[utf8]{inputenc}
\usepackage[xindy]{glossaries}
\makeglossaries
\newglossaryentry{Begriff}{name={Begriff}, description={Ein Begriff}}
\glsaddall
\begin{document}
\printglossary
\end{document}
Evaluation
For German, xindy needs to know whether to use "din5007" or "duden".
As from makeglossaries version 2.06 (glossaries v3.05) I've added "din5007" as the default to makeglossaries if the language is set to german.
Workaround for Earlier Versions
Either use
\GlsSetXdyCodePage{duden-utf8}
or
\GlsSetXdyCodePage{din5007-utf8}
Comments
2 comments.
Replying to Comment #2:
🔗Comment from Nicola Talbot 🦜
Date: 2015-07-09 10:22:00
Date: 2015-07-09 10:22:00
This should now be fixed in makeglossaries version 2.16 (glossaries version 4.16).
Replying to Comment #3:
Add Comment
Page permalink: https://www.dickimaw-books.com/bugtracker.php?key=3
Date: 2015-03-18 15:19:40
The issum mentioned above exists in v 4.12(Tex Live 2014). It can be reproduced by invoking makeglossaries on a file containing the MWE above, while the workaround is still applicable.