GNOME Bugzilla – Bug 703569
localization issues in Hebrew (maybe other RTL langs)
Last modified: 2021-06-01 22:44:32 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.
and I can confirm this in 3.8.
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))
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.
Review of attachment 248383 [details] [review]: Makes sense, but I guess it needs a translator comment
...which means https://live.gnome.org/TranslationProject/DevGuidelines/Use%20comments
(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.
Created attachment 248400 [details] screenshot: clock in bottom, right stays for berlin, germany is on correct order. am I right?
yes, you are. if both are hebrew it is ok, the problem is only with mixed RTL and LTR.
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
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
(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.
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
Created attachment 249401 [details] [review] patch proposal
I like this approach, make sure to update the comment too to reflect the reason why we are adding these character before committing
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
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?
Created attachment 249806 [details] [review] patch proposal for time representation
Created attachment 249808 [details] screenshot: gnome-clocks with hebrew locale
(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
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.