On Sat, Oct 31, 2015 at 11:40 AM, Markus Neteler <neteler@osgeo.org> wrote:
On Sat, Oct 31, 2015 at 3:39 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On Sat, Oct 31, 2015 at 9:41 AM, Markus Neteler <neteler@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.