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

[Gareth Owen <gowen72 yahoo com>]

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.

This would actually simplify the parsing code considerably.

> 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?

I know Carlos Marin was looking at iso-codes for his localisation
caplet, but I don't know how far he has got with it.  There are
certainly other modules in gnome that could use the iso-codes package
and I'm sure the translators would approve of its introduced as it would
reduce their workload.

> I can see more benefits to this approach.  Instead of fast-growing
> Locations.xml (imagine 2500 strings times 40 languages, and having to 
> parse this from XML file when displaying gweather configuration
> dialog), we'd have pretty static Locations.xml with ~2500 entries,
> and only one single gettext catalog would be loaded at runtime (so,
> it would go to maximum of 2 times 2500 in parsing time, not counting
> the fact that .mo's are much faster to parse than XML).

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.

> 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.


Gareth