Daiki Ueno <[email protected]> writes: > Miguel Ángel <[email protected]> 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
