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

["Vincent Belaïche" <vincent.b.1@hotmail.fr>]

Answers inserted below...

----------------------------------------
> Date: Sun, 31 Aug 2014 23:37:06 +0100
> Subject: Re: bug#18308: 24.4.50; Info viewer cannot follow menu entry for '(texinfo) @- @hyphenation'
> From: gavinsmith0123@gmail.com
> To: Vincent.b.1@hotmail.fr
> CC: 18308@debbugs.gnu.org; bug-texinfo@gnu.org
>
> (adding bug-texinfo)
>
> On Fri, Aug 22, 2014 at 11:04 PM, Vincent Belaïche
> <Vincent.b.1@hotmail.fr> 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?
>

Currently the usual practice is that a translated document is just another document with some -xx ending in the base name (where xx refers to the language, e.g. fr for French). 

In my opinion an alternative method would be that translated document should rather bare exactly the same name but just be in a language specific directory named xx, with some fall backs to another language (meaning ../oo, where oo refers to the other language) when manual does not exists.

I think that the alternative method is closer to what people usually do for Web sites, in which each language is its own tree replica (file/directory names are same, but only file contents differ).

>> 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.

Menus are precisely the only place where you don't need any change in Texinfo, as you can do:

* Translated node name: true node name. Some description

@node true node name

and the viewer is supposed to show only "Translated node name".

What I was meaning is that the viewer should be configurable to show either the "node path" with translated names or true names.

In the case of nodes that are not referred by any menu, like the top node, or node accessed only by cross reference, there aren't currently any provision in Texinfo to povide a node name translation. That could be some command @localenodename to give that translation inside the node.

  Vincent.