New GNU Gettext features (was: [bug-gettext] New Gettext contributor)

[Miguel Ángel Arruga Vivas <rosen644835 gmail com>]

Hi Javier and everyone,

I also send this message to desktop-devel-list, because from my point of
view this mailing list is where this conversation belongs. If this is
not the place for this topic I would thank any pointing. I should have
notify this to GNOME people some time ago, although never is too
late. :)

Javier Jardón <jjardon gnome org writes: 
> On 4 March 2013 11:47, Miguel Ángel <rosen644835 gmail com> wrote:
> > Daiki Ueno <ueno gnu org> writes:
> > > Miguel Ángel <rosen644835 gmail com> writes:
> > > > GSettings and update gnome are not dependant, but the first needs expat
> > > > compatibility extraction from x-glade.c (or adding an unlikely related
> > > > file type to x-glade.c to parse also GSettings) and the second needs
> > > > GtkBuilder extraction and
>
> Sorry for the intromision in the conversation,

Don't worry, any comment is welcome. This is the foundation of a public
mailing list.

> Does all this changes mean we can use gettext instead intltool for
> GtkBuilder/gsettings schemas and .desktop files?
> Currently we have to use this 'ugly' hack in autogen.sh to use
> upstream gettext in GNOME projects:

The short answer is: not yet. Currently I have implemented GtkBuilder
support and it will be uploaded to upstream soon. It is already on
<https://github.com/644rosen/gettext_gtkbuilder_support> and any comment
is welcome.

Also I am working on GSettings schemas support, but actually It needs
more work. The main problem is file ending because xgettext currently
looks at the string after the last dot of the filename for language
selection. In those schemas this is xml, because file ending convention
is '.gschema.xml'. This makes harder implement generic xml support, or
will need a change in the language extractor selection algorithm if we
want to parse generic xml files (see next paragraph). I would propose
changing the name ending convention to .gschema because it will be
easier at my side but this is a lazy suggestion of a slothful person, so
It could be rejected as fast as the speed of light. ;-)

OTOH, and in my very humble opinion, I think that generic XML parsing in
intltool is not the right way. Internationalize an xml file must not
modify its structure:
1- There is an standard attribute 'xml:lang' that could be used to mark
strings that could be translated, or
2- Internationalization could be part of the XML definition, like in
GSettings or GtkBuilder and Glade, or
3- It could be a mix of both, with xml:lang and specific attributes and
tags. I do not endorse it, but somebody may have good reasons to do it.

But I do not see the point of modify each tag that you want to be
translated because adding a _ to its names makes it an invalid xml file.
In a generic xgettext xml extractor you always could pass tag names
(with --keyword option) you want to be translated. Even more, the
mark-i18n-text system is error-prone because you could miss some wanted
text, but It is already in xml standard (see
<http://www.w3.org/TR/REC-xml/#sec-lang-tag>). You have to modify your
source code to achieve internationalization, because you actually have
to do something to translate an string: call gettext(). But data should
not be modified, at most internationalization should be implicit in tag
name (already known by xgettext or not with --keyword parameter) and/or
explicit by an attribute.

If there is a strong reason to stay with this markup I can implement a
parser for it, but the reason has to be a real good one that I can not
see right now.

.desktop files are the last format parser I am going to code because
they also need a writer. A possibility(?) would be calling n times an
updated msgmerge with this loop:
---------------------------------
for i in po/*.po; do
  msgmerge -o file.desktop file.desktop $i
done
---------------------------------
Personally I would choose a new executable name instead of adding it to
msgmerge, but comments are welcome.

And last but not least, my kudos to GNOME project for its accessibility
focus. This feature makes easier computing for lots of people. Thank
you.

Happy hacking!
Miguel