After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 672080 - Check tags dynamically with gtxml
Check tags dynamically with gtxml
Status: RESOLVED OBSOLETE
Product: gtranslator
Classification: Other
Component: Parse engine
HEAD
Other Linux
: Normal enhancement
: ---
Assigned To: gtranslator-maint
gtranslator-maint
Depends on:
Blocks:
 
 
Reported: 2012-03-14 15:51 UTC by Daniel Mustieles
Modified: 2019-02-27 15:15 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
checker v1 (7.21 KB, patch)
2012-04-17 11:43 UTC, Ignacio Casal Quinteiro (nacho)
none Details | Review

Description Daniel Mustieles 2012-03-14 15:51:19 UTC
There is a tool called gtxml (it cames with pyg3t, https://launchpad.net/pyg3t) that allows you to check tags from the console.

Since typos and errors in tags are so common, and the can cause some compilation errors, it would be very interesting if gTranslator could check tags syntax using this tool, like it checks variables or line breaks.

Thanks :)
Comment 1 Daniel Mustieles 2012-03-19 20:07:27 UTC
Here there is an example of how this tools works (note that the «media» ending tag in the translated string is wrong):

$ gtxml gnome-help.master.es.po 

At line 93: mismatched tag
--------------------------
#: C/index.page:15(page/title)
msgid ""
"<media type=\"image\" src=\"figures/yelp-icon-big.png\">Yelp logo</media> "
"Desktop Help"
msgstr ""
"<media type=\"image\" src=\"figures/yelp-icon-big.png\">Logo de Yelp<media> "
"Ayuda de escritorio"
Comment 2 TLE 2012-04-17 11:39:41 UTC
Hallo

I'm one of developers of PyG3T so I thoght I would share a few thoughts. First off this sounds awesome, it would be great to have some more checks integrated into gtranslator.

Right now, there isn't much of a general purpose API for PyG3T because we usually  only add stuff when we need it. So far we have only had use for the script, so therefore that has been the focus. However, we are very willing, and eager, to develop more on the project as need arises, so if you guys would like to have a general purpose API for gtxml, instead of using it as a script, then please just let us know.

Regards Kenneth
Comment 3 Ignacio Casal Quinteiro (nacho) 2012-04-17 11:43:00 UTC
Created attachment 212196 [details] [review]
checker v1

here is the unfinished plugin which part of the code is based on gtxml. The plugin is working but we are missing a way to present the errors to the user.
Comment 4 Ignacio Casal Quinteiro (nacho) 2012-04-21 13:06:33 UTC
From a discussion with pbor:

<nacho> pbor, got a minute to give me some advise API wise?
<pbor> nacho: sure!
<nacho> pbor, so I've got the next problem in gtranslator
<nacho> when an user translates a message and tries to change the message to the next one, gettext provides a way to check that the message is correct. The check from gettext is 100% reliable
<nacho> so a show a info bar with the error color and I show the error message that I get from the gettext library for that message
<nacho> and I block the user the movement to the next message until the current one is fixed
<nacho> I wanted to extend this now
<nacho> for example to check the messages to check that the xml tags are correct
<nacho> i.e the problem you were having the other day when you were making the distcheck
<pbor> ok
<nacho> the issue is that the heuristic to check for xml tags it not reliable
<nacho> so I wanted to be able to add a message which can be a warning 
<nacho> which will block the movement and give the warning
<nacho> but if it closes the info bar with the close button will unblock the movement
<pbor> ok, so it sounds a bit like in gedit when you save a file
<nacho> yes
<pbor> you can get an "are you sure you want to overwrite"
<pbor> or you can get "no way I'll save in /root"
<nacho> but with the specific point that an error is blocking and a warning would be blocking while the user does not provide feedback or it fixes the message
* carandraug has quit (Ex-Chat)
<nacho> so I wanted a way to provide this in a good way for plugin writers
<pbor> ok, but in the infp bar you would have a "Use anyway" button, right?
<nacho> the issue is that I will probably need to manage priorities etc
<nacho> pbor, if it is a warning yes
<nacho> warnings would be non reliable checks
<pbor> how does a plugin interact with this api?
<nacho> errors would be blocking and would not have a way to move until it is fixed
<nacho> that what I don't know yet
* pbor is not totally sure what do plugin do in gtranslator...
<nacho> I wanted something like:
<nacho> tab.add_message(Warning, "Some message")
<nacho> pbor, i.e http://bugzilla-attachments.gnome.org/attachment.cgi?id=212196
<pbor> wait, I am not sure I understood which part of the api are we talking about
<nacho> but more abstracted to the user
* pbor looks
<pbor> ok, so the plugin would be the one doing the xml checking
<nacho> yes
<nacho> pbor, it would be the plugin and also the core
<nacho> the core for 100% reliable checks
<nacho> the ones that come from gettext
<pbor> what happens if more than a plugin reports a failed check?
<pbor> are they displayed all at the same time
<nacho> I wanted to provide some way of priorities
<pbor> or one by one?
<nacho> no, I want just one by one
<pbor> that can get annoying though
<nacho> yes
<pbor> maybe it would be better to display all the reported errors
* madewokherd (~urk@c-66-41-76-26.hsd1.mn.comcast.net) has joined #gedit
<nacho> pbor, but we can have the error one and the warning ones...
<pbor> and have two buttons "check again" and "force"
<nacho> check is done when you actually try to move to the next message
<pbor> ok
<nacho> pbor, right now it would look like this: http://imgur.com/t1BRn
<pbor> how do you call the plugins? calling a vfunc of a "checker" interface?
<pbor> (or emitting a signal, which is more or less the same)
<nacho> pbor, the plugins implement the tab activatable and then they connect to the message-edition-finished signal
<nacho> which is emitted when the user tries to change from one message to another
<nacho> maybe would be better to have an extension point just for checks...
<pbor> ah, so they manually set the info bar in each plugin?
<pbor> yes, I would centralize that part
<nacho> that would be the idea...
<pbor> I would say to emit a msg check signal
<pbor> and make a plugins call either "set_error" or "set_warn"
<pbor> then in the core you collect the problems
<pbor> and you show them
<nacho> looks like a plan
<pbor> and maybe keep a map bwteen an "id" and the message
<nacho> what about priorities?
<pbor> I'd show all of them in one go
<pbor> it is less annoying imho
<pbor> maybe if you have errors just show the errors
<pbor> and then you show the warnings
<nacho> yeah makes sense
<pbor> when you show the warnings you also have an ignore button in the info bar
<nacho> yeah
Comment 5 Daniel Mustieles 2012-05-27 17:30:28 UTC
Hey Nacho, what happened with this plugin?

If I can help you somehow, tell me! ;-)
Comment 6 André Klapper 2019-02-27 15:15:13 UTC
We are mass-closing old gtranslator issues as the latest versions of gtranslator (3.30 or later) should fix most of the reported problems and as there is unfortunately no capacity to retest all of them separately.
https://mail.gnome.org/archives/desktop-devel-list/2019-February/msg00059.html

If the issue described in this report still happens in gtranslator version 3.30 or later, please file a new ticket under https://gitlab.gnome.org/GNOME/gtranslator/issues/ - thanks for your understanding!

We are sorry that your report was not handled / fixed after you reported it - many free and open source software projects receive more bug reports and feature requests than they have developers who have free time to work on them.
If you would like to get involved and contribute on gtranslator code, please check https://wiki.gnome.org/Git/Developers