[GRASS-dev] wxgui_items.xml: outdated

[Vaclav Petras]

On Sat, Oct 31, 2015 at 11:40 AM, Markus Neteler <neteler at osgeo.org> wrote:
>
> On Sat, Oct 31, 2015 at 3:39 PM, Vaclav Petras <wenzeslaus at gmail.com>
wrote:
> > On Sat, Oct 31, 2015 at 9:41 AM, Markus Neteler <neteler at osgeo.org>
wrote:
> >>
> >> Hi,
> >>
> >> I have realized that gui/wxpython/xml/wxgui_items.xml is not properly
> >> updated with the current module descriptions.
> >
> > Do you mean description elements in wxgui_items.xml? Or do you mean
other
> > XMLs as well?
>
> For now I mean wxgui_items.xml. Since I am not familiar with the
> mechanism I didn't check the rest.

Thinking more about it I don't think the main issue is related to
wxgui_items.xml, please see below.

> > In general, the label element in both wxgui_items.xml and toolboxes.xml
is a
> > menu-specific string which is supposed to be very short (1-3 words) and
> > mostly in a form of command, possibly ending with three dots. There is
> > nothing like this in modules, although it would be a good idea to have
it
> > there. (Note that label and description elements in the menus are
something
> > else than label and description in modules; this should be fixed as
well.)
>
> Yeah, it is a bit confusing.
>
> > The description element in toolboxes.xml is taken from label and
> > description. In wxgui_items.xml, content element and description
element is
> > unique to this file, although there might be some overlaps. Is this
what you
> > mean? Do you have some examples?
>
> For an example, see
> https://trac.osgeo.org/grass/changeset/66687
>
> This subtle "tuning" of strings is not a good idea.
>
> grep "label\|description" wxgui_items.xml | wc -l
> 116
>
> of almost identical strings. Almost means not identical which means
> that all of them have to be translated again. Rather a PITA for the
> translators.


I don't think there is 116 duplicated strings in wxgui_items.xml. The label
element text is unique for XML files (see the "bit confusing" part). This
cuts the number to half. Than there are wxGUI-only items such as New
(OnWorkspaceNew) which have the string only here (approx 10 items). Than
there are items with command element which is an actual command, so
executable and parameters. These, in theory, have different description
than the module itself, e.g. "g.manual -i" and "g.manual entry=wxGUI".

Finally, there are items with related-module element where there is some
module for it, but the GUI starts a specialized wrapper instead or it is a
g.gui module and the GUI starts integrated into the main one as opposed to
starting a separate process. CommonFormatsImport (r.in.gdal) is an example
of the former and GraphicalModeler (g.gui.gmodeler) of the latter.

All (or most) of these entries have keywords which are definitively
duplicated and description which may or may not overlap with description
from the module. For example, the g.gui.gmodeler labels says "Graphical
Modeler" and description "Allows interactively creating, editing and
managing models" while GraphicalModeler description says "Launch Graphical
modeler". For CommonFormatsImport and r.in.gdal the overlap is there.

Even if all items with command element and all items with releated-module
element had description element which content overlaps with module's
description and/or label, it would be only 29 strings. The actual current
number of string which are/should be the same is probably under 20. It
would be ideal if it would be 0, but do you think this is what translators
complain about?

> > Here is some documentation:
> >
> >
https://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/docs/wxgui_sphinx/src/wxgui_toolboxes.rst#L200
> >
https://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/xml/toolboxes.dtd
> >
https://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/xml/wxgui_items.dtd
>
> I started to read the README but it is rather short :-)

wxgui_toolboxes.rst should be exhaustive documentation of the toolbox
mechanism but regarding the translations, it is just using whatever was
there before.

> >> This is an issue since we get duplication of almost identical strings
> >> which then drive mad our translators.
> >>
> >> It is really a job for
> >> gui/wxpython/tools/update_menudata.py
> >> but this scripts seems to be also outdated while looking to be the
> >> perfect solution.
> >
> > I looks like there is no use for this script now. What I know is in the
doc
> > which says that "Historically, menudata.xml file was in the source
codes and
> > was partially maintained by the script
> > ``gui/wxpython/tools/update_menudata.py`` which updated the description
and
> > keywords (based on module's label or description, and keywords)."
> >
> > I'm not sure if I was ever able to run the original workflow
successfully
> > (before introducing the toolboxes) which is partially the reason why the
> > README still mentions update_metadata.py.
>
> OK, it would be good to clean that up.
>
> >
https://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/docs/wxgui_sphinx/src/wxgui_toolboxes.rst#L230
> > https://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/README#L64
> >
> > The main point is that all updates now happen automatically,
>
> Indeed not completely since xml/wxgui_items.xml appears to be manually
> written (or outdated and based on older description lines?)

This is how it was designed. When it is something which is a module, it is
in toolboxes.xml which are combined with generated module_item.xml. If it
is some GUI thing (i.e. not the automatically generated GUI dialog), it is
specified fully manually in wxgui_item.xml. The 29 cases mentioned above
might be something in between which in the current design fall back to the
GUI items category, thus manually managed. Design can be changed. Question
is how.

> > so there is no
> > need for manual patching of menudata.xml or any other file as it was in
the
> > past.
>
> ... yes, which is good.
>
> > The issue which the new system inherited from the old one is that the
> > description element in GUI XMLs is a combination of label and
description
> > from a module's interface description as the documentation linked above
> > says.

Comparing to the max 29 strings above, this happen for every module with
both label and description. Not all modules have it but if yes, it would be
approx 530 strings in case my guess about how translation works* is right.
It seemed to me so significant that I though I'm wrong about how it works
because somebody would complain about that.

(*) What I think is that label+description are combined and put to the XML,
then this string is extracted later from one of the generated XMLs and put
to some file and extracted to po files. On runtime, somehow the strings
from XML are linked to the translated ones.

> > I always wondered why this doesn't bother translators,
>
> It does.

There is apparently a lot of people bothered with many other things but
they are silent, but this is a discussion for some other time.

> > but since I don't understand the translation process,
>
> In which sense? You take a po file and translate... a very lengthy
> job. And almost identical strings have to be translated several times
> which does not encourage anyone.

This I understand. The part I don't understand is how strings from XML and
other parts appear in the po files (it is in the Makefiles and Python
scrips, I don't know if there is some doc for that).

> It would be great to have a script which autoextracts the strings for
> gui/wxpython/xml/wxgui_items.xml as "dry" run (similar to how the old
> tools/update_menudata.py worked) in order to decide on a case by case
> base when to abbreviate or when not. Again, r66687 is an example where
> I reinstated the actual wording, a perfect computer job.

As the old system, this would depend on people running it. We must have
something

> Hope you see now what I mean,

Yes, but now I want to know if the normal module entries in menu (for
modules with both label and description) are the issue or not since if they
are, it is far more significant.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20151031/4f929bfa/attachment-0001.html>