Miguel Ángel Arruga Vivas <[email protected]> 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
