[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'
Tue, 2 Sep 2014 23:44:08 +0200
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
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.
> Date: Mon, 1 Sep 2014 21:53:55 +0000
> From: address@hidden
> To: address@hidden; address@hidden; address@hidden
> 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).
> 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:
> * 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.