GNOME Bugzilla – Bug 403815
win32: Problem with display of currency symbol
Last modified: 2018-06-29 21:25:15 UTC
Please describe the problem: The pound (GBP) symbol is not displayed correctly within accounts. Environment: Windows XP SP2 English, with default UK English standards and formats but the location is set as Japan and the language for non-unicode programs is set to Japanese. Steps to reproduce: 1. Set up a Windows machine with the environment described above 2. Create an account with the currency set to pounds sterling 3. Actual results: The pound sign displays as a right bracket bottom Expected results: To see the stylized L which is the pound symbol (unicode 00A3) Does this happen every time? Yes Other information: Clearly gnucash is picking up encoding information from the "language for non-unicode programs" setting as changing this to English solves the problem. However, this is not an option for me as it makes a number of legacy applications I have unusable. The language of the interface also changes between Japanese and English with this setting. Are there any plans to convert the application to utf-8? Is the Japanese yen symbol set as "JPY" because of the problem the other way round? ie The yen sign based on shift JIS (cp932) displaying as a backslash on an English system?
I had missed one thing in the documentation when I wrote my comments. I see this is supposed to be a utf-8 version, although Windows clearly does not run it as a unicode application. Alan (In reply to comment #0) > Please describe the problem: > The pound (GBP) symbol is not displayed correctly within accounts. > Environment: Windows XP SP2 English, with default UK English standards and > formats but the location is set as Japan and the language for non-unicode > programs is set to Japanese. > Steps to reproduce: > 1. Set up a Windows machine with the environment described above > 2. Create an account with the currency set to pounds sterling > 3. > Actual results: > The pound sign displays as a right bracket bottom > Expected results: > To see the stylized L which is the pound symbol (unicode 00A3) > Does this happen every time? > Yes > Other information: > Clearly gnucash is picking up encoding information from the "language for > non-unicode programs" setting as changing this to English solves the problem. > However, this is not an option for me as it makes a number of legacy > applications I have unusable. The language of the interface also changes > between Japanese and English with this setting. > Are there any plans to convert the application to utf-8? > Is the Japanese yen symbol set as "JPY" because of the problem the other way > round? ie The yen sign based on shift JIS (cp932) displaying as a backslash on > an English system?
As you've already guessed, GnuCash takes the currency symbol from the system's locale information. GnuCash assumes that this character is given in UTF-8 encoding (Unicode is something else). If the system's locale information returns a non-UTF-8 non-ascii character, GnuCash can't do anything about this, I'm afraid. On Linux, we would tell you to file a bug with your distribution in order to get the "locale" fixed. Here, I'm not sure what we can do. We'll keep this bug, and if it concerns other locales as well, we might have to add a windows exception in handling the currency character by expecting a different encoding than UTF-8. Note that the error itself might just as well be caused by the glib library or by one of the mingw libraries. (For the record: If you're filing bugs on the still experimental win32 port, please include the string "windows" or "win32" in the bug title. Thanks.)
Fixed in r15512. Thanks for the great report! It would be nice if you could verify this bug later.
Thanks for doing this so quickly. It has taken me longer to get around to verifying it as I have had some trouble with builds. I now have a working version again (r15574) and the work around seems to be working fine (ie rather than a pound sign displaying incorrectly "GBP" is displayed - I assume this is the change made in r15512) There is a difference which may be an effect of the fix or with the way I built it. I have not managed to successfully build on the machine I am running GnuCash on but built it on another Win XP machine (Japanese OS) and transferred the whole file structure onto this machine. The problem is that it is no longer running in Japanese. It seems to have picked up on the en_GB locale on and therefore all the menus etc are in English. This is not a real problem but I would like to understand if this is deliberate. If so it might be nice at some point to have an option to change the locale manually so I may raise a feature request. Thanks Alan
Hm, it should show you a correct pound sign. I thought you used the binary package. What does "not managed to successfully build" mean, maybe that is another bug. The menu language depends on the locale which you typically set in your control panel, regional and language settings. But I think you can override it by the environment variables LC_MESSAGES, LC_ALL, LANG and LANGUAGE. I suppose you copied all files in lib/locale? Do you start gnucash or gnucash.bat from a c:\soft clone or did you use dist.sh?
(In reply to comment #5) > Hm, it should show you a correct pound sign. Having checked further I have found it displays "GBP" if the locale is Japanese and a pound sign if the locale is English regardless of the language of the GUI > I thought you used the binary package. I did the first time. When I looked at sourceforge I was only looking at the date next to "2.0.99" and as this did not change and I did not look at the exact revision number I did not realise the package had been built. Sorry my mistake. I will check later (today if I have time) to see if the binary package gives the same results. > What does "not managed to successfully build" mean, maybe that is > another bug. Not compiling at all. Since this was the first time I had built gnucash there were a lot of tools and libraries to download and whilst there were no obvious errors I was not confident that there no been failures there rather than problems in the gnucash code or the build script. Since I was eventually able to build it I assume this is not a bug. Having diffed the downloaded files from the 2 machines (about 3 days apart) I noticed there were many differences, significantly in aqbanking but also in some of the gnome libraries. For reference I am attaching the errors but I think they can probably be safely ignored now. > The menu language depends on the locale which you typically set in your > control panel, regional and language settings. The locale on this machine has not changed. It is set to English but with Japanese as the option for non-unicode programs. Previously this gave a Japanese GUI but now I get an English GUI. > But I think you can override it by the environment variables LC_MESSAGES, > LC_ALL, LANG and LANGUAGE. I have never attempted to set this manually on Windows. I will test it later. Of course it could potentially affect other programs I am using if I just add a new user environment variable. I do not know if this can be done at the command line so something could be put in gnucash.bat >I suppose you copied all files in lib/locale? Yes. If I set the locale to Japanese the Japanese LC_MESSAGES file is used. If I replace the file gnucash.mo in gnucash\inst\lib\locale\en_GB\LC_MESSAGES with the file of the same name from gnucash\inst\lib\locale\ja\LC_MESSAGES I do get a Japanese GUI (and in this case, in the Japanese GUI the pound sign displays correctly. > Do you start gnucash or gnucash.bat from a c:\soft clone or did you use > dist.sh? I am using gnucash.bat
Created attachment 82775 [details] compile time error for reference only. this is no longer a problem
I have downloaded and installed the binary package. All the observations in comment #6 are still valid.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=403815. Please update any external references or bookmarks.