GNOME Bugzilla – Bug 116727
Error message not correctly displayed with ISO-8859-2 locale
Last modified: 2004-12-22 21:47:04 UTC
Bug message in ISO-8859-2, in polish should be like other strings in UI - but it looks strange. It's probably caused by incorrect font used in gcalctool entry field. How to repeat this situation: - set locale to pl_PL - copy the newest message strings pl.po for this program (from cvs) - change mode onto financial (widok/tryb finansowy) - press Ow button - see nicely looking "error" :) (like in attached file)
Created attachment 18048 [details] Error message incorrectly displayed
I asked one of the GNOME I18N experts on this (Toshi, who I've cc:'ed to the bug), and his reply was: "Isn't set_display() supposed to take UTF8 encoded string? Since _("Error") is passed to doerror() and then set_display(), the str is already UTF-8. If we're sure that set_display() is always called with UTF-8 encoded strings in other places too, then I'd suggest to remove the to-utf8 conversion code from the set_display() function." Arkadiusz, I'll generate a patch to this affect, and attach it to the bug for you to try. Thanks.
Created attachment 18110 [details] Proposed dfix for this bug.
I ended up adding in a second parameter to each call of set_display, that indicated whether this was an error condition or not. If it was, then the first parameter being passed in was already localized (had to do it this was so that the strings turned up in the message files), and wouldn't be run through g_locale_to_utf8(). Arkadiusz, could you give this a try and let me know if it fixes the problem for you please? Thanks.
Yes - it helps. Thanks for your nice job. I really like to request bugs (if I find one) :))
Created attachment 18114 [details] Gcalctool widow after program patching
Rich: Is it possible that v->display would contain non-ASCII string? If they are always in 0x20-0x7f range, we might assume the str in set_display(char *str) is always UTF-8, since UTF-8 is a superset of ASCII.
Changes checked in. Toshi, to answer your question. v->display will contain either an error message: "Error" "Numeric stack error" "Operand stack error" or a numeric value. Note that the numeric value can also be in Eng/Sci format, i.e. something like: 45.678888888e+3 Knowing this, can/should the code be changed?
These error messages are surrounded by _(" and ), so they are UTF-8 strings, and numeric values, which are made from make_*() functions, should consist only '0'-'9', 'e' 'A'-'F', '+', '-', '.',.... There might be some more, but they should be in ASCII code range, right? Then, having the True/False 2nd argument looks unnecessary to me.
Hi Toshi, They say that "if it ain't broke, don't fix it" ;-) but I want to try to understand this better. Am I correct in understanding that if gcalctool is displaying a number (which consists of: '0'-'9', 'e', 'A'-'F', '+', '-', '.') then you don't need to call g_locale_to_utf8() on that particular numeric string? If that is indeed the case, then yes, we can (or perhaps I should say, "could") remove it. I say "could" because leaving it this way makes it more flexible for any possible future changes. Thanks.
You don't need to call g_locale_to_utf() onto these numeric string. g_locale_to_utf8() onto ASCII string does no good or harm but consuming CPU by invoking loads of code converion functions It's up to you whether to change the code again, but I was afraid if I had pointed you to that (a bit wrong) direction:-)
I thought about this some more last night. I'm all for simplicity, and putting it back the way it was (and remove the need for g_locale_to_utf8() simplifies set_display() nicely, so I've readjusted. I've checked my changes in. Hopefully finally fixed in v4.2.97. Arkadiusz, would you mind checking gcalctool out from CVS HEAD and checking that the new way of fixing things works correctly for you please? Thanks again Toshi!
The newest version from CVS works ok. I checked this everywhere I could.