[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#18308: 24.4.50; Info viewer cannot follow menu entry for '(texinfo)
bug#18308: 24.4.50; Info viewer cannot follow menu entry for '(texinfo) @- @hyphenation'
Mon, 1 Sep 2014 21:40:37 +0200
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: address@hidden
> To: address@hidden
> CC: address@hidden; address@hidden
> (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?
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.
- bug#18308: 24.4.50; Info viewer cannot follow menu entry for '(texinfo) @- @hyphenation',
Vincent Belaïche <=