Re: [bug-gettext] Glade/GtkBuilder related bugs

[Miguel Ángel]

Daiki Ueno <address@hidden> writes: 
> Miguel Ángel <address@hidden> writes:
> 
> >> Do we really need to extract "context" attribute from every element?
> >> Otherwise, I guess it can be folded in the while-loop below to extract
> >> the translator comments.
> >> 
> > My second patch points this, but that is not the issue. Actually there
> > is a problem, I pointed it out at the next mail of my pile in
> > bug-gettext archive ;-).
> 
> Could you link to the mails (also bugs)?  That would be helpful to
> understand the context which we are talking about.  There is a web
> archive: https://lists.gnu.org/archive/html/bug-gettext/
> 

Sorry, I mean I was wrong in that mail/patch you reviewed, sorry again.
The mail is this
https://lists.gnu.org/archive/html/bug-gettext/2013-01/msg00022.html and
its patch duplicates the code for glib syntax string splitting from
'arglist_parser_done', but without the leak that has in both places of
'arglist_parser_done'.

> 
> > Glade2 and GtkBuilder are not compatible. The
> > first one have in the context attribute "yes" or "no" and the string
> > have the Glib syntax "msgctxt|msgid". The second one has msgctxt in the
> > context attribute.
> 
> Ah, ok.  Thanks for the explanation.
> 
> > I have already a functional xgettext with GtkBuilder support and Glade
> > fixed, but the implementation is not a simple patch. The new tests are
> > almost copied from existing xgettext-* tests, but filled with new data,
> > and I have extended xgettext-glade-4 also. You can see it at
> > https://github.com/644rosen/gettext_gtkbuilder_support.git
> 
> I've briefly looked at the "glade_bugs" branch and it looks basically
> good.  One thing is, isn't it possible for x-glade.c to utilize arglist
> parser instead of adding a new function 'split_glib_syntax_string'?
> 

The problem with 'arglist_parser_done' is that always call
'remember_a_message' with NULL at parameter 'extracted_comment'.
Parameter 'comment', which contains the real xml comment around the
translatable string, is only added at POT file when --add-comments, but
now the attribute "comment" in a glade2 file is always added when the
string is translatable. If this is not the desired functionality, It is
a bug and 'xgettext-glade-4' is a buggy test because it does not pass
'--add-comments' to xgettext, but expects comments. Implement it would
be easy and we could use 'arglist_parser_done' assuming the overhead,
but a workaround would be needed if we use 'arglist_parser_done' and we
also want to preserve the Glade2 comment attribute extraction like in
'xgettext-glade-4' test. I will send the required patch as soon as I
read your opinion about this issue.

Also I have had a deeper look at 'arglist_parser_*' and It has known
leaks in msg{id{,_plural},ctxt} strings, that could be solved with some
logic changes, but It needs a lot of testing before sending anything,
because It is used at many places. It will be a separated patch if we
choose use 'arglist_parser_done', or it can be mixed with
'split_glib_syntax_string' even if it is static, because
'arglist_parser_done' is a big function and the content of this function
is at two places, it could be "inline" for optimization, but this way
there is no code (and bug) duplication.

> 
> Also please separate out unrelated changes, like:
> https://github.com/644rosen/gettext_gtkbuilder_support/commit/f766f238
> I think this commit can be merged regardless of glade/gtkbuilder
> support.  Thanks for triaging the bugs anyway!
> 

Done. You can see it here
https://lists.gnu.org/archive/html/bug-gettext/2013-01/msg00028.html and
here https://savannah.gnu.org/bugs/download.php?file_id=27357 too.

> 
> Regards,
> 

Best regards
Miguel