Re: [bug-gettext] Glade msgctxt patch

[Daiki Ueno]

Miguel Ángel Arruga Vivas <address@hidden> writes:

> I actually prefer arglist_parser functions family, because It eases a
> little bit GtkBuilder implementation, but there is no real problem,

I'm looking at:
https://github.com/644rosen/gettext_gtkbuilder_support/commit/d4fe1932b0a835e7e8816b8fb740c0f520f92cf0

Right.  It might help for the case where context is passed differently.

However, it looks a bit hacky to me that arglist_parser functions are
used without other callshape API functions, unlike other parsers.

Maybe you can get some inspiration from Bruno's original commit which
introduced the API:
http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=011e7649509f3f0ae7671612e68fd069afd7e0c3

So, if I were you, I would try:

1. register keywords using split_keywordspec, like:

  x_glade2_keyword ("property:1g");
  x_gtkbuilder_keyword ("property:1c,2");
  etc.

2. allocate arglist_parser in start_element callback
3. call arglist_parser_remember in start_element and end_element if we
   find something to remember in attributes and contents
4. call arglist_parser_done in end_element 

though it might not fit well with the SAX-style parser.

> My local repo already has every patch I have done, feel free to ask
> for old (and probably buggy) versions.

Thanks.

> Also, for the tests patch, should I split msgctxt extraction test
> (xgettext-glade-5) and atkproperty test case (xgettext-glade-4) in two
> commits?

Yes, please.  The atkproperty test case is not related to the context
support, right?  Also perhaps it might be good to add a wrong element to
the xgettext-glade-5 to test the failure case.

I'm looking at:
https://github.com/644rosen/gettext_gtkbuilder_support/commit/91dfcd209b153f61c02a0c8db188c8cb9cf8f7c1

Regards,
-- 
Daiki Ueno