GNOME Bugzilla – Bug 342446
evolution should use localized digits in calendar
Last modified: 2013-09-10 13:50:10 UTC
The evolution calendar widget uses English digits. It should use Persian digits when the session is in Persian.
Created attachment 65917 [details] [review] patch for version 2.2.3
Adding srini to CC list.
srini: ping
srini: PING.
Behnam, I haven't reviewed the patch yet, but does that work for 2.10.0 also?
behnam: ping
Well, what should I do right now? I'm ready to test it with a clean jhbuild build. What module should I use for test? GNOME 2.20?
You can use GNOME-2.22 for svn HEAD atm.
The patch looks good. Tested with english and persian (fa_IR) locales and it works fine. It can be committed to both stable and trunk.
Thanks chenthill for the review. Just, now that I look again at the patch I think we can clean up the code by removing "if (week_num >= 10)" and "if (day_num >= 10)", and call pango_layout_get_pixel_size on the buffer directly, instead of caching the character width. IMHO pango must have an internal cache for this job. Behdad?
Not sure what the question is. Just do it however is simpler. Think about caching and optimizing only if you can measure that it's too slow for the job.
Patch committed to stable (gnome-2-24) branch as r37190 http://svn.gnome.org/viewvc/evolution?view=revision&revision=37190 Patch committed to SVN trunk as r37186 http://svn.gnome.org/viewvc/evolution?view=revision&revision=37186
This change hurts portability because the "%Id" format is Linux-only.
so as the patch is in... why is this still open? OK, maybe because of the last comment. Matthias, which platform do you refer to? Any potential solution/workaround?
> which platform do you refer to? I'm running NetBSD, but I haven't seen any mention of that format in *BSD, Solaris nor OSF/1 manpages. > Any potential solution/workaround? Sorry, I don't have an idea. It seems there is no portable way to get the preferred decimal number font out of localeconv(3) or nl_langinfo(3). This would suggest a user selectable option which is a bigger change. I'd be fine with some "#ifdef __GLIBC__" for now.
I think its better to add the #ifdef _GLIBC__2.2.3 to check if the glibc version is abover 2.2.3. This %I flag has been added from 2.2.3. Behnam, please provide a patch incorporating the above mentioned changes.
Thanks Matthias and chenthill. (In reply to comment #16) > Behnam, please provide a patch incorporating the above mentioned changes. Unfortunately I won't be able to work on this in the next few weeks. As it's a blocker right now, would someone fix it please? Thanks again.
Ok np I will do it.
Proposed patch for the portability regression in bug #574045.
I provided the patch for bug #574045. The patch uses _("%Id") to replace "%Id". This is because on Solaris, we have a script to handle such GNU extensions in .po files. This script can turn %Id in *.po into %d. I am not sure how BSD or other platform handle this situation.
I am thinking of using gnu_get_libc_version to identify whether the version of glibc is >= 2.2.3 to use %Id. If gnu_get_libc_version (added from libc 2.1) is not defined or if the version is less that 2.2.3 use the %d format. Would that be the right fix? Wang, I will commit your patch along with the one which am making now.
Thanks, Chenthill.
Created attachment 130284 [details] [review] Use %Id only if the libc version is >= 2.2.3. Mathias, please confirm if this fixes the bug for you. I have committed the fix as its a hard code freeze tomorrow.
this broke the string freeze. please act.
_('%Id') - what should be translated here? Am I missing something?
In my original patch, I add _() to "%Id" because we use a script to manipulate .po files to translate "%Id" to "%d". In the new patch, "%d" is used on platform which does not support "%Id". So _() is not necessary, I think.
Oh ok. I was just having solaris build in mind and completely missed the string freeze. Sorry. Will remove the string marked for translation immediately.
Removed the string marked for translation, http://svn.gnome.org/viewvc/evolution?view=revision&revision=37390 .
> Mathias, please confirm if this fixes the bug for you. Sorry, I'm on travel, but from code inspection this looks OK. (I'd have used some static vars in the glibc case so that the string manipulation is done only once.)