Hi, Daiki Ueno <[email protected]> writes: > Before starting the review, I would like to ask a very basic question. > > Are there any other differences between Glade 2 and GtkBuilder files, > except the following? > > 1. the msgctxt can be specified through context="ctxt" attribute > 2. <col> and <attribute> elements may have translatable content
No, there isn't. The big point is actually context, because It is handled in an incompatible way. > I think it would be better to simply add those features in > an upper compatible way, instead of rewriting x-glade.c parser to handle > Glade 1, Glade 2, and GtkBuilder file types separately (and strictly). I would like to parse them strictly but It does not mean separately. Checking Glade1 tags in a GtkBuilder[1] file is error-prone from my point of view. You can check a temporal commit here[2], circa 400 lines changed, but a lot of code is moved with few changes, although it needs more work to shine. > For 2, just allow those new elements as well as <property> and > <atkproperty>. I really dislike current <property> and <atkproperty> checking because adding them to keywords makes that context and comments are not extracted: actually, Glade2 support is an undocumented feature[3]. This "feature" forces to add hacky ||-clauses all around to parse GtkBuilder[1] files with implicit or explicit --language=Glade option. Adding a new translatable tag[4] will not extract attributes when it is used as --keyword with old code path, instead of that you have to add it to x-glade.c code. With those changes[2] the developer will be able to test the extraction of a new tag from a new widget with --keyword=tag_name to extract the whole content, including "standard" attributes, without recompiling xgettext. Just the same as using a function in your source files of any language that calls internally gettext. At least a paragraph have to be added to the manual to explain internal voodoo, or to clarify that file type is detected at root tag when 'Glade' language is used. > I'd expect the minimal patch in this direction will be less than ~100 > lines. I am pretty sure that [2], [5] and [6] must be splitted in several patches, i.e. maint -> add Glade1/Glade2 file checking -> -> document Glade2 support and keywords -> -> add GtkBuilder support -> add GtkBuilder tests -> -> document GtkBuilder support keywords. This way adding GtkBuilder support will be under 100 lines and maybe all patches too: file checking part moves many lines, but few lines are really added. I could send the first one for public review this weekend if there is no problem. > By the way, by grepping the GTK+ source, it seems <item> and <mark> > elements are also translatable. You are right, It seems (also grepping, googling didn't help) that at least <item> is used this way by GtkComboBoxText xml definition[7] and <mark> by GtkScale xml definition[8], so they have to be added. Also an open RFC unrelated to xgettext's internals: Could we remove tag checking and just look attributes for GtkBuilder files? I have not read any restriction about attributes, so It may be a convention, but attributes "translatable", "context" and "comments" are called 'regular translation attributes'[7] and also 'usual "translatable" and "context" attributes'[8]. Happy hacking! :) Miguel [1] GtkBuilder files can be expanded with any tag name, see 'ANY' at the xml definition: <https://developer.gnome.org/gtk3/3.6/GtkBuilder.html> [2] https://github.com/644rosen/gettext_gtkbuilder_support/commit/19f6a2c6 [3] http://www.gnu.org/software/gettext/manual/html_node/xgettext-Invocation.html#xgettext-Invocation [4] Any new class implementing GtkBuildable is able to do it, from <https://developer.gnome.org/gtk3/3.6/GtkBuildable.html> [5] https://github.com/644rosen/gettext_gtkbuilder_support/commit/95e51fd5 [6] https://github.com/644rosen/gettext_gtkbuilder_support/commit/6ddb3ca1 [7] https://developer.gnome.org/gtk3/3.6/GtkComboBoxText.html [8] https://developer.gnome.org/gtk3/3.6/GtkScale.html
