After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 559039 - Untranslatable timezone messages marked for translation
Untranslatable timezone messages marked for translation
Status: RESOLVED DUPLICATE of bug 551705
Product: evolution
Classification: Applications
Component: Calendar
2.24.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
evolution[timezone]
: 582922 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-11-03 03:37 UTC by Leonardo Ferreira Fontenelle
Modified: 2015-08-26 08:13 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Leonardo Ferreira Fontenelle 2008-11-03 03:37:13 UTC
The file calendar/zones.h is full of timezones code, like "America/Sao_Paulo". That may look like English, but it's the code for a timezone, and I can copy and past it after "/usr/share/zoneinfo/" to find the corresponding file in my operational system. But this messages are marked for translation.

Should I translate it as "Américas, São Paulo"? If so, why aren't the original messages written in common English, like "São Paulo city"?

(This is a good time to look for reusable strings somewhere.)
Comment 1 Leonardo Ferreira Fontenelle 2009-01-03 20:28:20 UTC
Ping
Comment 2 André Klapper 2009-01-07 13:48:43 UTC
PING.
Comment 3 Leonardo Ferreira Fontenelle 2009-01-14 19:23:15 UTC
See also #551705.
Comment 4 Leonardo Ferreira Fontenelle 2009-03-27 14:19:25 UTC
Hello? It's been almost 5 months.
Comment 5 Matthew Barnes 2009-03-28 01:56:33 UTC
I'm not sure what to do with this.

I wonder if we still need that calendar/zones.h file at all now, since we're using libgweather for the weather calendar and dropped our libical fork.  If we do still need timezone translations, can we not get them from libgweather?

Chen?
Comment 6 Chenthill P 2009-07-17 09:22:38 UTC
Just commented on the same in, http://bugzilla.gnome.org/show_bug.cgi?id=582922#c8
Comment 7 Leonardo Ferreira Fontenelle 2009-09-27 05:13:30 UTC
The funny part is, the messages aren't user-friendly in English. America/Sao_Paulo looks like "America, Sao Paulo" but it's not the same. If the "C locale" user sees something which is not really English, then I'm not sure if I should really translate it to Portuguese. Can I remove the slash if it doesn't make sense in my language? Can I change the order of the words? Can I change the underscores for white space?
Comment 8 Leonardo Ferreira Fontenelle 2009-10-18 22:11:09 UTC
What abou t fixing this efore GNOME 3.0? It's been almost an year.
Comment 9 Matthew Barnes 2009-10-19 12:57:43 UTC
Copied from https://bugzilla.gnome.org/show_bug.cgi?id=582922#c8
> The same file exists in libical/zoneinfo/. Since libical does not have any
> translation in it, we would need this to be present. This is used for
> evolution on windows. system timezone info is not used in case of windows.

How about just dropping these translations on Windows?  It's not worth the overhead it imposes on platforms we actively support.
Comment 10 Milan Crha 2010-04-06 12:59:46 UTC
(In reply to comment #6)
> Just commented on the same in,
> http://bugzilla.gnome.org/show_bug.cgi?id=582922#c8

so it's a duplicate of this, isn't it?
Comment 11 Tobias Mueller 2010-05-22 19:20:42 UTC
*** Bug 582922 has been marked as a duplicate of this bug. ***
Comment 12 André Klapper 2012-02-02 16:17:05 UTC
I don't think that they are still translatable in 3.2.
Comment 13 Gil Forcada 2012-02-02 19:10:15 UTC
(In reply to comment #12)
> I don't think that they are still translatable in 3.2.

I do think so, check [1]. If Damned-Lies is not wrong, they are still translatable.

Adding a line on POTFILES.skip will do the trick though.

Are they still shown on the interface or just looked up on the common /usr/share/zoneinfo ?


[1] http://l10n.gnome.org/POT/evolution.master/evolution.master.pot
Comment 14 Milan Crha 2012-02-03 11:18:41 UTC
You've right, it's still there in git master as of today, and it's translated only in the timezone dialog (the one where you choose which timezone you reside in or which to use on an event), but no where else. You can translate them to provide timezone name in a language the evolution is run at, but the name is only shown in the combobox, the label when you hover mouse above the map shows different string (it shows display name as returned by libical).
Comment 15 Gil Forcada 2012-02-04 12:37:51 UTC
(In reply to comment #14)
> You've right, it's still there in git master as of today, and it's translated
> only in the timezone dialog (the one where you choose which timezone you reside
> in or which to use on an event), but no where else. You can translate them to
> provide timezone name in a language the evolution is run at, but the name is
> only shown in the combobox, the label when you hover mouse above the map shows
> different string (it shows display name as returned by libical).

Then there's nothing to do with this bug, the timezones are already translatable.

It would be nice to split the timezones info into a separate module so that they could be reused (even better if moved to libical directly so that upstream has already all the data needed).

Has anyone approached the libical developers to ask about it?
Comment 16 Milan Crha 2012-02-06 11:05:30 UTC
(In reply to comment #15)
> Has anyone approached the libical developers to ask about it?

I'm not aware of any such initiative, and I'm afraid it'll not be accepted, libical doesn't depend-on/use gettext, which might be a reason for evolution doing the translation, and even evolution itself uses it only in the timezone pick dialog.
Comment 17 Milan Crha 2015-08-26 08:13:58 UTC
Thanks for taking the time to report this.
This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 551705 ***