Re: Translation problems with default location in Weather applet

[Theppitak Karoonboonyanan <thep linux thai net>]

On 1/3/06, Simos Xenitellis <simos74 gmx net> wrote:
> Theppitak Karoonboonyanan wrote:
> >That is, a change like this:
> >
> >--- 8< ---
> >Index: libgweather/gweather-gconf.c
> >===================================================================
> >RCS file: /cvs/gnome/gnome-applets/libgweather/gweather-gconf.c,v
> >retrieving revision 1.4
> >diff -u -r1.4 gweather-gconf.c
> >--- libgweather/gweather-gconf.c        31 Dec 2005 10:00:44 -0000      1.4
> >+++ libgweather/gweather-gconf.c        2 Jan 2006 16:23:20 -0000
> >@@ -162,7 +162,7 @@
> >         if (strcmp ("DEFAULT_LOCATION", _("DEFAULT_LOCATION")))
> >
> >
> If   the translator has translated the DEFAULT_LOCATION message (that
> is, she did not just type "DEFAULT_LOCATION" in the translation box),
>
> >             name = g_strdup (_("DEFAULT_LOCATION"));
> >
> then  use the translated text the translator has provided.
>
> >         else
> >-            name = g_strdup ("Pittsburgh");
> >+            name = g_strdup (_("Pittsburgh"));
> >
> else  just put the city of Pittsburgh. The choice of Pittsburgh probably
> comes from the original author of gweather, Spyros. This section is
> executed when the translator has not provided any default location and
> we would like the applet to work anyway. The end-user would have to
> change the location to something more sensible. Making that instance of
> Pittsburgh localisable is an option, however I would feel more
> confortable if translators would provided a sensible default location.
> In any case, if a translator went into the trouble to translate US
> cities like Pittsburgh, she surely has localised all the locations in
> her coutry anyway.

But that doesn't mean she is guaranteed to provide the translation for
DEFAULT_LOCATION as well. In case she has not, that would cause
inconsistency in the program. For example, the treeview for locations
might assume the selection by translated string, not the English
"Pittsburgh" (just the same inconsistency caused by the bug you has
pointed out).

> >To my common sense during maintaining the translation, however,
> >defining DEFAULT_LOCATION in English just made perfect sense,
> >since it's the language for internal communication between program
> >modules. And the mentioned code just confirmed that. So, I didn't
> >change the previous translator's string. But I appeared to be wrong.
> >
> >I'll fix the bug soon for Thai translation.
> >
> Many thanks.
>
> It might look strange, however, having the default location in the
> weather applet appear by default in the local script, and containing the
> most common location is a good tool when you present to new users.

It's about program logic that matters. For example, if the schema were
defined to require English name, it could replace location->name with
_(location->name) wherever translated version is expected, while the
reverse direction is far from being possible. That's what my common
sense told me. :-)

But if it is for a special purpose, where translation is short-circuited,
like in this case, it's just fine, as long as logic consistency is still
maintained.

Regards,
--
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/