[virt-tools-list] [libosinfo 5/5] Load localized values for entity params

[Zeeshan Ali (Khattak)]

On Fri, Oct 19, 2012 at 11:22 AM, Christophe Fergeau
<cfergeau at redhat.com> wrote:
> On Fri, Oct 19, 2012 at 06:50:00AM +0300, Zeeshan Ali (Khattak) wrote:
>> From: "Zeeshan Ali (Khattak)" <zeeshanak at gnome.org>
>>
>> Attempt to use the localized values of entity params if available before
>> using the non-localized values.
>>
>> This does not yet include custom (ones starting with 'x-') params as I
>> haven't yet figured the right xpath magic to (cleanly) achieve that.
>> Suggestions welcome!
>> ---
>>  osinfo/osinfo_loader.c | 33 +++++++++++++++++++++++++++------
>>  1 file changed, 27 insertions(+), 6 deletions(-)
>>
>> diff --git a/osinfo/osinfo_loader.c b/osinfo/osinfo_loader.c
>> index 934c758..7569262 100644
>> --- a/osinfo/osinfo_loader.c
>> +++ b/osinfo/osinfo_loader.c
>> @@ -219,14 +219,35 @@ static void osinfo_loader_entity(OsinfoLoader *loader,
>>                                   GError **err)
>>  {
>>      int i = 0;
>> +    const gchar * const *langs = g_get_language_names ();
>
> I don't think the format of values returned by g_get_language_names matches
> the format used by xml:lang. The former can be "en_US" while the latter
> apparently follows https://www.ietf.org/rfc/rfc4646.txt which says 'Subtags
> are distinguished and separated from one another by a hyphen ("-")'

As we both found out by looking the intltool's script, intltool does't
follow this RFC and the value of "xml:lang" comes from .po file and
those are follow the same convention as the locale environment
variables.

Since there is no guarantees that intltool will not start complying to
that RFC without the rest of the system doing so, the ideal solution
would have been to also check for locale with "_" replaced by "-".
However that would involve doing one extra string
allocation/duplication for each untranslated node here. I really would
want to avoid doing a lot of redundant computation/allocation for a
something that may never happen.

If the code could be written some other way that doesn't involve
string allocations, I'm all ears.

> From a quick look in glib/gtk+ source, it seems that in gtkbuilder files
> and in gsettings schema files, attributes/tags have a special marker to
> tell they are translatable (trailing '_' or 'translatable = true' attribute
> iirc), and during parsing, the parser code calls into gettext to get the
> translated value (see glib/gio/gsettingsschema.c and
> gtk+/gtk/gtkbuilderparser.c and search for 'gettext'). The advantage of
> this approach is that we don't have to do the lookup ourselves to find the
> best translation. Dunno if there are downsides...

As you saw in the later versions of this patch, I went for this
approach (even got your latest review comments addressed locally) and
spent a lot of time on getting it to work. However, I recalled a few
hour ago that we have the plan to setup a centralized database[1] and
having translations in the xml itself will be very much desirable for
that.

-- 
Regards,

Zeeshan Ali (Khattak)
FSF member#5124

[1] So that apps can grab the latest db over the Internet so users
don't have to wait for next libosinfo release to hit their distro
before e.g latest version of their favorite os is recognised by
libosinfo.