Re: [bug-gettext] New Gettext contributor

[Miguel Ángel]

Daiki Ueno <address@hidden> writes: 
> Miguel Ángel <address@hidden> 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 address@hidden) 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