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 <[email protected] writes: > On 4 March 2013 11:47, Miguel Ángel <[email protected]> wrote: > > Daiki Ueno <[email protected]> writes: > >> Miguel Ángel <[email protected]> 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
