The long name for DEM is always displayed as "German Mark" even though in a German environment this should rather be displayed in the German words "Deutsche Mark".
... and this of course applies to all long currency names in any locale. DEM is just an example. The infrastructure for currency name translation has to be created from scratch.
Linas may have committed something to HEAD to deal with this.
Good news: We might get the translations of all these currency names for free by using the "iso-codes" project: http://alioth.debian.org/projects/pkg-isocodes Also interesting might be ICU: http://icu.sourceforge.net/ and http://www.ibm.com/software/globalization/icu/
Other sources for translations: http://translation.sourceforge.net/teams/PO/de/ http://dev.icu-project.org/cgi-bin/viewcvs.cgi/icu/source/data/locales
Is that possible let iso-4217-currencies.scm belong to seperate .po file? just like "gnucash-glossary", it's "gnucash-currencies", but it will be used during the runtime. I don't know whether it is possible a program can use 2 po file at same time. If we can treat the iso-4217 currencies' name seperately, we can write a simple script to convert existing iso-4217 po files to gnucash project, and use them, without translators of gnucash involved in. And it will not broke "string freeze". And, actually, iso-4217 currencies is very different from the strings in the existing po file. It's a set of string which belong to a standard, and there is a seperate translators working on it. And translators of gnucash actually can do nothing but merge them. For each time iso-4217 translations updated, all translators have to update there po. It should not let translators do it. It should be done automatically. To do that, make iso-4217 to a seperate po file, will make everything much easier. Just copy existing iso-4217 translations to a specific location, such as po/currencies, And use a script to manipulate those file to gnucash, or maybe there is not even necessary to do the manipulate.
We might just re-use the translations from iso_4217 by using const char* translation = dgettext("iso_4217", currencyname); which means we load those translations from the iso_4217 domain. This would indeed directly work on a Linux system where this package is installed. For windows, we would have to ensure to download and package the iso_4217 translations into our installer, but even that should be possible. In other words, we might indeed not include it in our gnucash.pot template. I'll continue to work on that over the weekend.
Created attachment 160478 [details] 0001-Adjust-in-iso-4217-currencies.scm-fullnames-to-confo.patch Christian, thanks for Changeset 19058. Attached is the adjustment of iso-4217-currencies.scm, so that full names conform to iso-codes-3.3. I am not really happy with this solution, but it is better than nothing. Caveats: In the current version we loose partial information: a) country names; eventually we should add another column derived from the first 2 Letters of the Code, to get them also over iso-codes. b) obsolete status - ok, we can get that better using the new columns; c) there is an update problem e.g. until the end of the last year, the official name of TRY was "New Turkish Lira", but then "New" was dropped. Eventually it would be better, to lookup names used in iso-codes by searching /usr/share/xml/iso-codes/iso_4217.xml insted of again and again adjust the list to a more recent version of iso-codes. d) Errors in iso-codes-3.3: Wrong Naming SDD Pound!=Dinar Wrong Translation BRE (duplicate string) MGF != MY Obious Missing Translations ADF BOV CDF CLF COU CUC MGA TMT UZS SDR (de:SZR) ZWL Missing Code YUM So, could somebody test the patch against a more recent version of iso-codes? BTW: did you add iso-code to the dependencies? P.S. From the german POV, it would be nice, if the drop down list would be ~50% wider.
(In reply to comment #7) > Attached is the adjustment of iso-4217-currencies.scm, so that full names > conform to iso-codes-3.3. I am not really happy with this solution, but it is > better than nothing. Thanks for the patch. Indeed, I thought the same: We loose some of our original information, but at least we gain translations of 80%-90% of the cases for free. > Caveats: > In the current version we loose partial information: > a) country names; eventually we should add another column derived from the > first 2 Letters of the Code, to get them also over iso-codes. Well, there is no one-by-one mapping of currencies and countries. http://www.iso.org/iso/support/currency_codes_list-1.htm It is rather a 1:N mapping - one currency, many countries. Clearly we would need another table to express that relation; IMHO this information cannot be entered in our current structure. But we're free to change the structure. > b) obsolete status - ok, we can get that better using the new columns; Yes. We should copy the data over from /usr/share/xml/iso-codes/iso_4217.xml > c) there is an update problem e.g. until the end of the last year, the official > name of TRY was "New Turkish Lira", but then "New" was dropped. Eventually it > would be better, to lookup names used in iso-codes by searching > /usr/share/xml/iso-codes/iso_4217.xml insted of again and again adjust the list > to a more recent version of iso-codes. I think we should completely revamp the gnucash structure here. We should use iso-codes/iso_4217.xml as basis with the currency mnemonic as key, and then add more tables with additional information if we have it. - One table with iso_4217 currency: mnemonic, number, long name, whether it is historical-only, date_withdrawn. - Next table: currency mnemonic, smallest fraction - Next table: country code, currency mnemonic (where one currency may appear in many countries) > Wrong Translation > BRE (duplicate string) > MGF != MY That's a wrong *German* translation? > BTW: did you add iso-code to the dependencies? It's an optional dependency, but yes, it should be added and more importantly it should be added to the windows installer. > P.S. From the german POV, it would be nice, if the drop down list would be ~50% > wider. Sure. Patch...?
Created attachment 161332 [details] 0001-Resize-currency-dropdown-list.patch My first steps in glade. ;-) I used glade 3, which created the file in a somewhat different way - let me know, if that is a problem.
Comment on attachment 161332 [details] 0001-Resize-currency-dropdown-list.patch Comment on attachment 161332 [details] 0001-Resize-currency-dropdown-list.patch The change is (most probably) fine. Re glade-3: I'd suggest you could file one commit which only contains the conversion glade2 -> glade3, and a second commit with the actual changes. But in this case the single patch is probably fine as well.
gedit bug 150535 a) shows some interesting approaches, e.g. epiphany should have some useful code [see also http://mail.gnome.org/archives/desktop-devel-list/2005-March/msg00149.html ff] b) says iso-code was targeted as dependecy for gnome 2.10 Re Comment 8: If the first letter is != "X", the first 2 letters are the country code / tld. Special less known countries have unique currency names like lek, kwanza ... I assume, it would be helpful, at least in the drop down list, to add the country name, if the string contains no space. iso_4217.xml contains BRE 2x, so the first (=older, wrong) is fetched. It seems to be a typo, but affects all translations. MGF malegassy (creol from Madagascar) != MY Malaysia is a wrong de-translation In both cases we should check newer versions, if it is fixed. > should be added to the windows installer and MacOS, I assume.
There is a from iso-codes drived package isoquery git://git.debian.org/~toddy/isoquery.git . It shows how to query the xml files. BTW git://git.debian.org/git/iso-codes/iso-codes.git most errors mentioned above are fixed.
I saw the localized translation for the 'long currency names' in the currency droplist. It works on my Ubuntu, thank you. But, the I cannot make it work on Windows. I don't know why. I download the 'iso-codes-3.16.tar.bz2', './configure' and 'make install' to a specific location, then moved everything in share/locale to c:\program files\gnucash\share\locale. So, gnucash-bin.exe should be able to find those iso_4217.mo in locale/xx_XX/LC_MESSAGES/. Why it still not work, all long currency names in the droplist is English. Did I missed anything?
Comment on attachment 161332 [details] 0001-Resize-currency-dropdown-list.patch Comment on attachment 161332 [details] 0001-Resize-currency-dropdown-list.patch r19225, thanks a lot!
Could anyone tell me what should I do to make this works under Windows system? I tried copied the iso_4217.mo to locale/zh_CN/LC_MESSAGES/, but it doesn't work. What should I do next? Thanks.
Created attachment 165488 [details] Add isocodes to Windows build This patch add isocodes support for Windows build. It automatically download, build, install and packaging the isocodes. Currently, the patch will not make Windows build show the locale long currencies name. But it make the isocode available on Windows. Since the long currencies names are already shown on Linux, I think it should not far to make it happen on Windows too, especially the isocode will be available after this patch.
Created attachment 170449 [details] 0001-Put-isocodes-in-README.dependencies-to-inform-packet.patch To inform the package maintainers, I reworked the Libraries/Deps section of README.dependencies. 1. Link to more up to date http://wiki.gnucash.org/wiki/Dependencies 2. Introduce Structure: required, alternatives, optional, at runtime suggested 3. Add webkit and isocodes
Is this set up as a dependency in configure?
(In reply to comment #18) > Is this set up as a dependency in configure? No. It is not a compile-time dependency, so configure doesn't need to check it and it should stay this way. It's a pure optional run-time dependency, i.e. if it is installed, gettext will pick up the translations from there, but if it is not installed, gettext just returns the untranslated currency names.
Comment on attachment 170449 [details] 0001-Put-isocodes-in-README.dependencies-to-inform-packet.patch Comment on attachment 170449 [details] 0001-Put-isocodes-in-README.dependencies-to-inform-packet.patch r19597, thanks!
This bug is targeted for milestone 2.3.x and is still open. From reading the bug's history, it's not really clear to me why it is still open. Can you quickly summarize what is still missing to close it ?
Comment #16 said: "Currently, the patch will not make Windows build show the locale long currencies name." In other words, our C code is fine, only on Windows our installer and/or our rest of the installed infrastructure doesn't pick up the isocodes translation domain correctly. Once our Windows installation uses this as well, this bug is fixed on all platforms.
It is now. I just added it to the OSX build and bundle. ;-)
Removing milestone: While it would be nice-to-have, there's no requirement to do this for this milestone, and apparently nobody feels able to debug that part.
There isn't any debugging needed. Somebody who's interested in the Win32 build needs to add the iso-codes package to the distribution. Should be a 5-minute job. (That's what it took me on OSX, including testing.)
(In reply to comment #25) > There isn't any debugging needed. Somebody who's interested in the Win32 build > needs to add the iso-codes package to the distribution. No, that's not the issue. The iso-codes package *has* been added to the win32 installer in r19369 in July. So it is already there. However, Comment #16 said: "Currently, the patch will not make Windows build show the locale long currencies name." In other words, our C code is fine, only on Windows our installer and/or our rest of the installed infrastructure doesn't pick up the isocodes translation domain correctly.
I have just pushed a commit which I hope will fix this problem. It occurred to me gnucash on Windows may not be finding the translation files for the iso_currencies, so I have added a line to explicitly tell gnucash where to look. I'll check tomorrow's nightly build to verify if my theory is right. While the problem was only reported on Windows (and not reproducible on linux), the fix is platform independent. @John, can you test if my change is not messing things up on the OS X build ? Thank you.
Works fine on OSX.
Unfortunately it doesn't work at all on Windows. Worse even it causes the windows binary to crash each time translated currency names are queried. Back to the drawing board...
New build system, new windows support system, now Geert's patch works. This is fixed for 3.1.
Yay!
