[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gettext] GtkBuilder support

From: Miguel Ángel Arruga Vivas
Subject: Re: [bug-gettext] GtkBuilder support
Date: Fri, 15 Mar 2013 13:59:22 +0100


Daiki Ueno <address@hidden> 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

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"

Happy hacking! :)

[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
[4] Any new class implementing GtkBuildable is able to do it, from
[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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]