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 703569 - localization issues in Hebrew (maybe other RTL langs)
localization issues in Hebrew (maybe other RTL langs)
Status: RESOLVED OBSOLETE
Product: gnome-clocks
Classification: Applications
Component: general
3.8.x
Other Linux
: Normal normal
: ---
Assigned To: Clocks maintainer(s)
Clocks maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2013-07-03 18:20 UTC by matanya
Modified: 2021-06-01 22:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
world: Fix location order issue in RTL lang (942 bytes, patch)
2013-07-04 13:31 UTC, Jiro Matsuzawa
needs-work Details | Review
screenshot: clock in bottom, right stays for berlin, germany is on correct order. am I right? (314.87 KB, image/png)
2013-07-04 16:16 UTC, Evgeny Bobkin
  Details
patch proposal (1.05 KB, patch)
2013-07-17 13:05 UTC, Evgeny Bobkin
none Details | Review
patch proposal for time representation (1.28 KB, patch)
2013-07-22 14:10 UTC, Evgeny Bobkin
committed Details | Review
screenshot: gnome-clocks with hebrew locale (163.32 KB, image/png)
2013-07-22 14:12 UTC, Evgeny Bobkin
  Details

Description matanya 2013-07-03 18:20:09 UTC
Hello, 

I have installed gnome-clocks and got this: 

https://commons.wikimedia.org/wiki/File:RTL_bug_in_gnome.png

How to reproduce:

1) choose a hebrew locale in the gnome lang setting
2) install gnome-clocks
3) create a new world clock
4) see if it looks like: https://commons.wikimedia.org/wiki/File:RTL_bug_in_gnome.png

and a bonus: 

order of cityname and country are also wrong.
Comment 1 André Klapper 2013-07-03 18:45:43 UTC
and I can confirm this in 3.8.
Comment 2 Evgeny Bobkin 2013-07-04 08:08:59 UTC
Thank you for reporting it, however this issue is well known already, in other words, this bug is a duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=699681

moreover the bug report I am referring to is a duplicate of another one, see https://bugzilla.gnome.org/show_bug.cgi?id=699681#c2 for more details))

the bonus you mentioned however should be fixed by us))
Comment 3 Jiro Matsuzawa 2013-07-04 13:31:35 UTC
Created attachment 248383 [details] [review]
world: Fix location order issue in RTL lang

I wrapped the string of location info with the gettext funciton. Now translators can change the order of a city name and a nation name.
Comment 4 Paolo Borelli 2013-07-04 13:52:54 UTC
Review of attachment 248383 [details] [review]:

Makes sense, but I guess it needs a translator comment
Comment 5 André Klapper 2013-07-04 13:56:29 UTC
...which means https://live.gnome.org/TranslationProject/DevGuidelines/Use%20comments
Comment 6 Evgeny Bobkin 2013-07-04 16:09:32 UTC
(In reply to comment #2)
> Thank you for reporting it, however this issue is well known already, in other
> words, this bug is a duplicate of
> https://bugzilla.gnome.org/show_bug.cgi?id=699681
> 
> moreover the bug report I am referring to is a duplicate of another one, see
> https://bugzilla.gnome.org/show_bug.cgi?id=699681#c2 for more details))
> 
> the bonus you mentioned however should be fixed by us))
 I changed my mind)) I have tried this patches, like "%s, %s" and "%1$s, %2%s" 
and even tried to translate the string. And I must say, I do not see any visible change. If both city and country names are localized the displayed order is correct, other wise it looks like it looks. The only solution I see, is to translate the remaining city names into Hebrew.
Comment 7 Evgeny Bobkin 2013-07-04 16:16:04 UTC
Created attachment 248400 [details]
screenshot: clock in bottom, right stays for berlin, germany is on correct order. am I right?
Comment 8 matanya 2013-07-04 16:57:38 UTC
yes, you are. if both are hebrew it is ok, the problem is only with mixed RTL and LTR.
Comment 9 Jiro Matsuzawa 2013-07-05 17:09:13 UTC
Hi Evgeny and matanya,

I might have misunderstood you. Reading Evgeny's mail [1], I understood that you were concerned about the order of a city and a nation. But I want to make it more clear what is the main point of this report. Is it the order of TIME, not that of a city and a nation? If you say both of them have a problem, you can file each problem as different bugs.

[1] https://mail.gnome.org/archives/gnome-i18n/2013-July/msg00001.html
Comment 10 Paolo Borelli 2013-07-05 17:20:13 UTC
As far as I can tell the problem with time is tracked in 699681

The problem with the city name is not a bug, it is a problem when the translation of libgweather is incomplete. I do not think we can fix it
Comment 11 Evgeny Bobkin 2013-07-17 10:55:04 UTC
(In reply to comment #10)
> As far as I can tell the problem with time is tracked in 699681
> 
> The problem with the city name is not a bug, it is a problem when the
> translation of libgweather is incomplete. I do not think we can fix it

I thought the same all the time, but I have investigated a little bit and have discovered, that the city names are actually very well translated, and it turned out to be a real bug 704021 in libgweather, it is due to serialization and inability of the libgweather to output the name of the location properly ((

I mean it only respects the locale settings once at runtime, and all other changes via  GLib.Intl.setlocale  are ignored.
Comment 12 Evgeny Bobkin 2013-07-17 12:13:11 UTC
To solve the time issue, I suggest just to use the left-to-right mark!

well, inserting a left-to-right mark seems to fix the issue in general, so no
localization procedure(marking string for translation) is needed at all. In LTR languages it is just ignored. For the RTL languages is fixes the issue.

one of the possible solutions is: "%H\xE2\x88\xB6\xE2\x80\x8E%M"

where

left-to-right mark: \xE2\x80\x8E
ratio character: \xE2\x88\xB6
Comment 13 Evgeny Bobkin 2013-07-17 13:05:24 UTC
Created attachment 249401 [details] [review]
patch proposal
Comment 14 Paolo Borelli 2013-07-18 21:13:20 UTC
I like this approach, make sure to update the comment too to reflect the reason why we are adding these character before committing
Comment 15 Jiro Matsuzawa 2013-07-19 09:38:39 UTC
Thank you for the patch. But as you know, gnome-desktop has replaced "∶" (U+2236 RATIO) with ":" (U+003A COLON) [1][2], and that approach will fix the time format problem for gnome-clock, too. I think it would be better because of 1. consistency with the desktop environment, 2.clearness for translators. What do you think?

[1]https://git.gnome.org/browse/gnome-desktop/commit/?id=a14c4fd24c30b5eb38fa3f93bb0938dc187941e9
[2]https://bugzilla.gnome.org/show_bug.cgi?id=696497
Comment 16 Evgeny Bobkin 2013-07-19 10:31:31 UTC
I think this change made in gnome-desktop by Bastien Nocera was not authorized by the design-team, so we would ask them, and probably fix it in gnome-desktop as well. Therefore, I think this was a temporary solution. As you can see the bug report you have mentioned here, which is also mentioned in comment 2 is still opened and the final decision was not taken.

As far as I know the U+2236 RATIO character should be used, because it just looks better. on my android smartphone the centralized colon is used as well.

Allan, what do you say?
Comment 17 Evgeny Bobkin 2013-07-22 14:10:55 UTC
Created attachment 249806 [details] [review]
patch proposal for time representation
Comment 18 Evgeny Bobkin 2013-07-22 14:12:41 UTC
Created attachment 249808 [details]
screenshot: gnome-clocks with hebrew locale
Comment 19 Evgeny Bobkin 2013-07-22 14:46:00 UTC
(In reply to comment #15)
> Thank you for the patch. But as you know, gnome-desktop has replaced "∶"
> (U+2236 RATIO) with ":" (U+003A COLON) [1][2], and that approach will fix the
> time format problem for gnome-clock, too. I think it would be better because of
> 1. consistency with the desktop environment, 
I have talked with Bastien, and the idea in the gnome-desktop is to use ":" colon for the strings marked for translations there, so the translators simply do not need to deal with ratio and can use %R format. and afterwards in the code it will be replaced by the ratio character pretended by the LTR mark. It is still used as  you can observe https://git.gnome.org/browse/gnome-desktop/tree/po/en.po#n40

2.clearness for translators.
gnome-desktop will probably follow the above mentioned approach. and in the case of gnome-clocks this string is not markd at all for transtation.
> What
> do you think?
> 
> [1]https://git.gnome.org/browse/gnome-desktop/commit/?id=a14c4fd24c30b5eb38fa3f93bb0938dc187941e9
> [2]https://bugzilla.gnome.org/show_bug.cgi?id=696497
Comment 20 André Klapper 2021-06-01 22:44:32 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new enhancement request ticket at
  https://gitlab.gnome.org/GNOME/gnome-clocks/-/issues/

Thank you for your understanding and your help.