Re: gnome-applets/po-locations isn't very smart

[Danilo Segan <danilo gnome org>]

Hi Gareth,

ÐÐÐÐÑ Ñ 3:25, Gareth Owen ÐÐÐÐÑÐ:

> On Sat, 2004-06-26 at 16:36, Danilo Åegan wrote:
>
>> Basically, we'll need to use a different setup altogether.  First
>> off, there would be no post-processing of Locations.xml (no need on
>> using intltool-merge to merge translations back in).  One would also
>> need to use gettext() calls on read-in English strings, instead of
>> using XML parser to get the translations.
>
> This would be a really simple change to implement.  All that would be
> needed it to write a script (unless it can be done with intltool) to
> extract the translatable strings from the XML to a header/C file that
> marked up for translation.  Then in the code just add one call to
> gettext when displaying the location.

Yes, I suppose it's very simple, though there're some "smudgy" points.
One can use intltool-extract to extract strings from XML for the sake
of translators into a C header file, but that's not very nice (since
some maintainer would have to keep up-to-date two copies of the
file).  The catch is that you cannot simply keep Locations.xml as-is,
because intltool-extract requires tags to begin with "_".

The other idea is to extract strings from Locations.xml.in just like
now, and (not) merge them back into Locations.xml with empty po
directory (eg. run it with "src" instead of "po-locations").

> This would actually simplify the parsing code considerably.

Agreed, and you'll avoid depending on libgnomeui locale "selector"
function :)

>> With this done, it would be trivial to adjust gnome-applets to use
>> external translation domain.
>
> One external translation domain I'd like to use is iso-codes.  This
> contains translations for both official country names and regions (eg US
> states).
>
> However, this would add iso-codes as a dependency of gnome-applets. 
> Would this be acceptable?  How does one even go about adding new
> dependencies to a core gnome module?

Basically, I'd call these "soft" dependencies: they're not required
for proper operation, but if they're available, they will be used.

So, it's simply a thing of trying both in sequence:
  translation = g_strcpy(dcgettext("iso3660", message_from_xml_file));
  if (!strcmp(translation, message_from_xml_file)) {
     g_free(translation);
     translation = g_strcpy(dcgettext("locations", message_from_xml_file));
  }

Or something similar (I may be mistaken about some g_* function
names, so don't take this to be correct ;).

> I've got my fingers crossed at the moment that speed isn't going to be a
> problem, but only time will tell.  I'll keep an eye on this as more
> translations are completed.

Nice to hear that.  For the record, Locations.xml with around 10
translations now takes 1.7mb.

>> PS. Also, it even sounds more reasonable to name this "airports"
>> rather than "locations" ;)
>
> Not really.
>
> Although the weather information does come from METAR reports from
> airports, the locations don't necessarily reflect the airport names. 
> This is certainly the case for most of the locations in the US (eg it is
> Boston not Logan Airport) and I think is becoming more the case for
> other locations.  Which I think improves the usability of the applet.

My idea was to more easily determine a policy of what goes in
"locations".  You surely aren't going to consider my including names
of all Serbian towns in here, are you? ;)

Cheers,
Danilo