Re: Automatic Menu Substitution In Gnome Help Documentation



Hi Matt,

Today at 17:58, Matt Keenan wrote:

> Translations were not ignored on purpose, just forgot to mention them. I agree
> that usage of available features should be used absolutely, I am just trying to
> devise a mechanism where all can be achieved.

We're currently using PO files for translating most of the docs (using 
gnome-doc-utils/xml2po).  This has some limits (like what to do with
entities) while providing many benefits for translators.

[snip]
> then later on in the document refer to these as in :
>
>      <guimenu>&Menu1</guimenu>
>      Choose <menuchoice><guisubmenu>&SubMenu1</guisubmenu>
>                         <guimenuitem>&MenuItem1</guimenuitem>
>             </menuchice>

Yeah, I understood your idea, but, speaking from the perspective of a
Serbian speaker (and translator ;), this won't work.  The problem is
that a single entity in English would have to be translated
differently depending on the context ("From &Menu1;" would use different
translation for &Menu1; in Serbian from the one in "Open &Menu1;"—"Iz
Programa" vs "Otvori Programe", compare "Program(a|e)").

> These could be generated into the gedit.xml file at build time, taking
> the menu choices from a predefined data file, or simply the .desktop file
> that is also being built/installed with gedit, each distro will have to
> patch the .desktop file either way if they want applications to appear
> differently on menus so using it would possibly make sense ?
>
> Would the above make sense ?

It's becoming too complex if you ask me ;)

I think it's simpler to add some special XML inside for thing like
that we might need now and in the future:

  <gnome:topapplicationsmenu>
  Choose <gnome:menupath for="Calculator">...

producing (in some sort of pre-processing step in g-d-u XSLT)
  
  <guimenu>Programs</guimenu>
  Choose <menuchoice>
           <guisubmenu>Tools</guisubmenu>
           <guimenuitem>Calculator</guimenuitem></menuchoice>

if that's where Gnome Calculator is (using current locale, of course).
This has the added benefit that even if desktop is fully localised,
and documentation isn't, you'll still be able to find the menu you
need (i.e. you'll get localised menu pointers in English docs).[1]

Now, what I find very interesting is maybe making use of AT (atk,
at-spi) libs to do the same for application menus, buttons, etc (thus 
explaining the choice of "gnome" namespace :).[2]


I think this would be even easier to implement, and much better (of
course, it would require use of g-d-u XSLTs or any derivative thereof
for displaying our documents, but a "pre-processing" stylesheet could
be separate for those wishing to generate "static DocBook").


Note that this assumes having a dynamic mapping (ugh, now I just wish
for GNU/Hurd "translators" stuff ;) of .desktop entries to menu
entries in XSLT (I doubt you can call command-line stuff from within
XSL ;) to be used in processing <gnome:*> tags (imagine user moving
apps around in menus, and documents magically having all menu pointers
correct ;).


Cheers,
Danilo


[1] Now watch Shaun slap me with a giant stick named "that will
SLOW-down Yelp": hey, sorry Shaun, but don't you think it would be
great to have dynamic menu pointers :)

[2] Damn, now I am in love with this idea: does anyone see this as
impractical and/or impossible? ;)



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]