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 > > This sounds like a bigger topic than just supporting GSettings schema > files, since intltool allows any element whose name starts with "_" to > be translated.
IMHO, this is the worst concept of intltool. An xml file must have a defined structure. Some tags must be translated, because its content would be shown, and other tags don't need to be translated because they are internal to the application. I do not see the point of translating some elements and not others with the same tag name, as soon as there is an standard xml attribute "lang" that could be used to mark this kind of things without breaking XML structure. Also, the xml support (with --keywords different from "default") can be achieved right now in the extractor of GSettings, because xgettext only recognizes the last dot part and GSettings files end with ".gschema.xml" (it is a bug in my current patch). > Also there were some requests to support the file formats used in GNOME: > > <https://lists.gnu.org/archive/html/bug-gettext/2011-05/msg00006.html> I have been thinking in .desktop files too, but thank you for pointing me that I am not the first one. Those are the hardest format, because it also needs a writer. This also, again IMHO, is a design flaw, because It mixes i18n in the same file, so any change of any language domain affects to the file, and there is no easy way to patch it when it is installed (unlike a new language domain .mo file, which only have to be copied to the correct location without modifying any common file). But this "defect" may be needed because the gettext domain of the program (where the string is translated) is not the domain of the desktop environment, so translation would not be achieved with a simple "gettext(string_from_desktop_file)". > I think we should ask GNOME people what they want these days. A > discussion on their lists (possibly [email protected]?) would > be a good start. I promise I will do it during this week, because right now I am a little bit busy with college stuff. Maybe also I should point on changing GSettings ending to ".gschema" to achieve generic xml (with --keywords and/or with xml:lang attribute) and GSettings separated parsers. > > I do not think that we want to depend on intltool in our examples. ;-) > > The current hello-c-gnome and hello-c++-gnome examples do not use any > settings. How about starting from a minimal example, which does not > depend on your gsettings patch? Then it can be easily merged. I meant GtkBuilder, sorry, because I used the same .ui file at gtk3 examples. It could be independent, but source file is almost trivial with GtkBuilder, you do not have to create the label. I also could add a GSettings example, but It will be more than a simple "Hello, World!" window. > > I did a couple of minor changes since I have posted them, but GtkBuilder > > patches has not changed since 2013-02-06 and Glade and xgettext ones > > since 2013-01-31. They are tested with make check and with each package > > with NLS I build at my main machine. > > Okay, so those "core" patches can be reviewed. Should I send the squashed patch (implementation, tests and doc of each topic) in the same mail? > > I was going to send them (arglist_parser, Glade2, GtkBuilder and > > libasprintf) but I have to do a question before, do I have to update > > ChangeLog date? I mean, which date (patch date or the commit one) must > > be there? > > I'm not sure :-) But it could be tweaked later. Ok, so I do not worry about ChangeLog date details. > > And about libgettextpo trailing backslash: It could be a documented > > feature and not a bug, comments are welcome. > > I agree. I suppose you agree It is not a bug. I have changed its status at Savannah, waiting for your confirmation to close it. Best regards, Miguel
