Patrice Dumas wrote: > > > > 2) the translation of document strings fail both for Perl+XS and > > > > ctexi2any. (They succeed in the tta/perl/t/*.t tests.) > > > > > > What do you mean by "translation of document strings" and what are > > > the details of the failures? > > > > The strings in the output document are not translated. For example, the > > french language "Section suivante dans l’ordre de lecture" is not > > used: > > > > -<td class="nav-button">[<a href="#chapter" title="Section suivante dans > > l’ordre de lecture" rel="next"> > </a>]</td> > > +<td class="nav-button">[<a href="#chapter" title="Next section in reading > > order" rel="next"> > </a>]</td> > > > > It is not so easy to debug that kind of error without access to the > > platform because gettext does not say why the string is not found, one > > has to use prints and strace or similar to get an idea what is going wrong.
These two gettext FAQ entries should help: https://www.gnu.org/software/gettext/FAQ.html#integrating_noop https://www.gnu.org/software/gettext/FAQ.html#windows_setenv Eli Zaretskii wrote: > One possible cause could > be that the Windows setlocale doesn't look at the LC_* environment > variables (unless you are using Gnulib replacements). This could be the case if the setlocale function is called by Perl. If it's called by C code, the setlocale override in <libintl.h> and in Gnulib fix that problem. > Another > possibility is if you rely on the LC_MESSAGES category, which Windows > doesn't support. Likewise: The <libintl.h> and Gnulib provide the LC_MESSAGES category, since the Windows runtime library lacks it. Bruno
