Re: bug#18308: 24.4.50; Info viewer cannot follow menu entry for '(texinfo) @- @hyphenation'

[Gavin Smith]

(adding bug-texinfo)

On Fri, Aug 22, 2014 at 11:04 PM, Vincent Belaïche
<address@hidden> wrote:
> Finally, as an EMACS user, it would be more important to me
>
> * if docstring could be written in a sort of texinfo-light format (when
>   you create a package or anything you first do docstring, and then you
>   port this to a manual (so having some texinfo-light format from the
>   beginning would reduce the effort)
>

It might be worth asking on emacs-devel about this to see if anyone
wants to implement it or has ideas about how it could work.

> Concerning the info format, what sort of problem I also see --- still in
> relation to i18n --- is that one should be able to use exactly the same
> node names whatever the language, so that the same link can be used, and
> when the manual is compiled to multifile HTML, you have the same file
> tree whatever the language.

Seems like a good idea to me. Would help for links between manuals and
for finding pages in other languages. Are there any guidelines about
how to translate Texinfo documents?

> What I am meaning is that using the same node names
> should not imply that when the final user is reading a manual written in
> non-English he/she has to see the real node names unless he/she copy to
> clipboard the node address, one should be able to specify along with the
> node name a node local name to be presented by the viewer

Having translated node names isn't as important because there would be
translated headers in the contents of files/nodes saying what section
we're in. The main use would be the status bar in a browser giving the
current node, and pointers or references to other nodes. I understand
it is not ideal to read a cross-reference in another language. Maybe
anchors with translated node names could be used instead? That would
work for everything (cross-references, pointers) apart from the node
name that is displayed in a status bar. Maybe makeinfo would have to
be modified to recognize that a menu in a node using anchor names is
referring to the child nodes properly.