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

[Vincent Belaïche]

Just to clarify that I was suggesting three completely different things:

One first thing was better support of internationalization for *Manuals*, in 
that context I was speaking about node name translation for presentation to 
user (there should remain a node true name that should remain the same whatever 
the translation. Ok, sorry if I misunderstood the rationale for the menu 
entries.

One second thing was internationalisation for *DocStrings*, in that context I 
was suggesting that docstring could contain some link to some manual variable 
or function description, so switching the Help language based on configured 
locale would just mean switching to the correct manual translation. 

BTW, replacing docstring by jump to manual is basically what calc already does, 
with its "h f" and "h k" commands. However it does it in a language dependent 
way because it does not use the "position within the node" (call it PWTN) in 
the command/variable index --- maybe the reason for such an implementation is 
that when this feature was made available in calc,, info  was not supporting so 
well PWTN --- but instead uses only the node pointer, and then seaches some 
string in the node to find the position.

One third thing is that even plain docstring format itself is language 
dependant. Only for that third item I was suggesting that a better format for 
docstrings would be some sort of texinfo-light (I think that texinfmt.el 
already support some lighter texinfo and could be some starting point for 
adding such a feature).

So in a nutshell the evolved docstring would contain some header indicating
- is that legacy format
- is that texinfo-light format
- do we have a pointer to some manual to be used instead when available and 
sought for at the configured locale location --- note that the pointer needs 
only to indentify the manual itself, the variable or function name is already 
known what you do C-h f or C-h k.

   Vincent.

----------------------------------------
> Date: Mon, 1 Sep 2014 21:53:55 +0000
> From: karl@freefriends.org
> To: vincent.b.1@hotmail.fr; 18308@debbugs.gnu.org; bug-texinfo@gnu.org
> Subject: RE: bug#18308: 24.4.50; Info viewer cannot follow menu entry for 
> '(texinfo) @- @hyphenation'
>
>> 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
>
> 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).
>
> True.
>
> 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
>
> No question that that is a well-known alternative approach.
>
> * Translated node name: true node name. Some description
> @node true node name
> and the viewer is supposed to show only "Translated node name".
>
> As Gavin says, that is not correct. Both parts of the node name are
> intended to be shown. The existing use of this feature is to make short
> menu item abbreviations, e.g., for the sake of completion or just ease
> of reading. For example, in the Texinfo manual, the HTML Cross
> References section has a @menu like this:
>
> @menu
> * Link Basics: HTML Xref Link Basics.
> * Node Expansion: HTML Xref Node Name Expansion.
> ..
>
>
> Whatever such a hypothetical texinfo-light needs to do, fine. We should
> think about that separately. It need not affect what Texinfo does.
> Seems like two very different cases to me. Let's not try to shoehorn
> existing Texinfo features into things that are far outside their intent
> and practice.
>
> A discussion of such a texinfo-light (not a name I would advocate,
> either) should presumably take place on emacs-devel, not in a debian bug
> for Texinfo.
>
> k