On Sun, Mar 02, 2025 at 12:27:49PM +0100, pertu...@free.fr wrote:
> There is another change that I would like to do. To have
> TRANSLITERATE_FILE_NAMES remain relevant and does not prevent
> corss-references to/from external manuals from working, I propose to add
> another variable to control the rule for external manuals, like
> TRANSLITERATE_EXTERNAL_FILE_NAMES. This would not be backward
> compatible, as the current situation would be obtained by setting both
> TRANSLITERATE_FILE_NAMES and TRANSLITERATE_EXTERNAL_FILE_NAMES instead
> of setting only TRANSLITERATE_FILE_NAMES explicitly, but it seems to me
> to be better. The idea is that TRANSLITERATE_FILE_NAMES could be set in
> general, such that the user can generate locally files with more
> readable names, but TRANSLITERATE_EXTERNAL_FILE_NAMES would only be set
> in the rare cases when the users want to have only transliterated file
> names for external links.
>
> What do you think?
Could we look at extending the htmlxref.cnf format?
As well as mono/chapter/section/node, like:
GS = ${G}/software
hello mono ${GS}/hello/manual/hello.html
hello chapter ${GS}/hello/manual/html_chapter/
hello section ${GS}/hello/manual/html_section/
hello node ${GS}/hello/manual/html_node/
- there could be suffixed versions giving the transliteration status.
It could be something like "node.translit" to give the location of
an online manual split by node, which nodes are named using transliteration:
hello node.translit ${GS}/hello/manual/html_node/
If this is the line that is used for links to "hello", then any links
to that manual would have transliteration applied.
This would allow only using transliteration for links to external
manuals that need it.
As below, we should always use Text::Unidecode for transliteration
if possible.
> Date: Mon, 10 Feb 2025 15:11:03 +0100
> From: pertu...@free.fr
> To: Werner LEMBERG <w...@gnu.org>
> Cc: gavinsmith0...@gmail.com, bug-texinfo@gnu.org
> Subject: Re: normalization problem with `@anchor` targets
>
> Note that the transliteration may also be different in tests and in
> regular output, to get reproducible output. If C is used, for instance,
> iconv //TRANSLIT is used in output (which is actually a risk for
> reproducible cross manuals references), while Text::Unidecode or
> Text::Unidecode compatible transliterations are used in tests.
If in future we allow non-ASCII characters in output HTML file names, we
could also have "node.utf8".
For completeness, there should also be a name for the current default
- maybe something like "node.plain" or "node.expand" (referencing
the "HTML Xref Node Name Expansion" spec).
