Re: Strings, Strings and Strings again :-)
Tor Harald Thorland wrote: Hello, Since we are getting closer to the string freeze as Christian said in another mail here, I'll like to highlight a couple of strings here... Some are missing, and the others i'll suspect as not to be translated. I confirm. They are no big deal if they should be translated or not, but it is noce to get rid of them if they are something that is not in use anymore. Also, it's better if we know that we can see each translated String in its GUI context. Which is not the case now. [...] **/Other question\** 1. What is Proximo according to my dictionary it is something like in the next month My understanding is that all bills that happen after a given date will be due the next month. It's about packing bill terms, instead of having to control a sliding window for each bill. In french, I believe that the same term, 'proximo', is used for this condition. [...] Didier. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Question about the trial report
Nobody knows ? Didier. Didier Vidal wrote: Hello, I have a problem for translating the 'merchandising' options of the trial balance report. This option panel enables to select accounts for 'gross adjusting', but I haven't been able to find a definition of 'gross adjusting' (and how it differs from regular adjusting), neither to see the impact of selecting accounts in this option. From the comments, it seems to be related to inventory accounts, but that doesn't help me much for the translation. From the comment, It also seems that adjustments on these accounts should not be displayed (or should be treated differently). But that's not what I observe. Could someone point me to relevant documentation, or explain me the notion of 'gross adjustment' account ? Regards, Didier Vidal. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Question about the trial report
Hello, I have a problem for translating the 'merchandising' options of the trial balance report. This option panel enables to select accounts for 'gross adjusting', but I haven't been able to find a definition of 'gross adjusting' (and how it differs from regular adjusting), neither to see the impact of selecting accounts in this option. From the comments, it seems to be related to inventory accounts, but that doesn't help me much for the translation. From the comment, It also seems that adjustments on these accounts should not be displayed (or should be treated differently). But that's not what I observe. Could someone point me to relevant documentation, or explain me the notion of 'gross adjustment' account ? Regards, Didier Vidal. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: 1.8 - G2 Localization related troubles
Have you tried to add (manually) the encoding of your files in the header of the XML gnucash 1.8 files ? Instead of starting the file with ?xml version=1.0? start with ?xml version=1.0 encoding=(your codeset)? Didier. Покотиленко Костик wrote: В Пнд, 30/01/2006 в 11:04 +0100, Christian Stimming пишет: Some other users (including me) have been using the 1.8 datafile with non-ascii characters without problems in gnucash-SVN, i.e. the non-ascii characters will be displayed and stored correctly in gnucash2. English, German, French (and some others) characters are all located in iso8859-1 - That's why it works for you I think. Russian and Ukrainian characters are in different table - that why it doesn't work for me. Isn't there even a bugreport about this particular file conversion problem in bugzilla? If there isn't, please enter one, maybe with a short test file. http://bugzilla.gnome.org/enter_bug.cgi?product=GnuCash I'll create bug report with test file and some screenshots. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Some utf-8 menu items give Gtk-WARNING **: Invalid input string
That can happen if a bindtextdomain is not associated with a bind_textdomain_codeset Didier. Le sam 19/11/2005 à 13:18, Christian Stimming a écrit : Hi all, as I'm checking the translated SVN-HEAD version, I recently noticed in LANG=de_DE that some menu items are not added correctly into the menus. Namely, two reports with non-ascii characters (German umlauts) in their name will cause a Gtk-WARNING **: Invalid input string and in the menu there will be an empty line instead of the label. To reproduce: LANG=de_DE gnucash ; you will immediatly see the invalid input string on the console; then go into the Reports / Berichte menu, then you see one empty line instead of the Account Summary / Kontenübersicht menu item; the other empty item is in the submenu _Income Expense / _Erträge Aufwendungen and it was supposed to be the Income Piechart / Erträge Tortendiagramm. Now the funny thing is that some other report menu items that contain non-ascii characters are displayed just fine. For example, the submenu _Income Expense / _Erträge Aufwendungen is correct, as are some entries there such as Income vs. Day of Week / Erträge pro Wochentag. The /tmp/gnucash.trace also told me that the correct label looks as follows Debug: gnc_menu_additions_menu_setup_one(): Adding /menubar/Reports/StandardReports/_Income Expense/Ertr_äge pro Wochentag [ErtrgeproWochentagAction] as [menuitem] (where the umlaut is in hex 5f c3 a4), whereas the wrong label looks as follows: Debug: gnc_menu_additions_menu_setup_one(): Adding /menubar/Reports/StandardReports/_Income Expense/Ertr303_244ge Tortendiagramm [ErtrgeTortendiagrammAction] as [menuitem] where the umlaut is in hex c3 5f a4 --- somehow the 0x5f (the underscore) shows up at the wrong place. However, if I add an actual underscore to that string in order to specify a keyboard shortcut, then the manually added underscore suddently shows up in the label as a literal underscore, but the umlaut is now okay... quite weird. David, I hope you already have an idea by now :-))) Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Some problems with the current plugin system in gnucash GUI
Le lun 14/11/2005 à 03:33, David Hampton a écrit : On Sat, 2005-11-12 at 12:49 -0500, Josh Sled wrote: The rule here is that we should create an account-tree page when a main-window is created which doesn't otherwise have an account-tree page. You want to hook in [:)] at a point after the UI is created, but you don't want to create an account-tree page *if* the saved-window-state contains one already, and you end up with two in the window. And there's no HOOK_NEW_MAIN_WINDOW_CREATED_WITHOUT_SAVED_STATE_ALREADY_WITH_AN_OPEN_ACCOUNT_TREE_PAGE. :) I believe I committed this on Friday. The window restoration code first looks for a gnucash-2.0 state file (which should always have an account tree page). If it doesn't find one, it opens an account tree page and looks for a gnucash-1.8 state file. OK. This works. I also saw in this changeset the right way to call actions exported by plugins, in gnucash design, using introspection: action = gnc_main_window_find_action(window, FileNewAccountTreeAction); gtk_action_activate(action); Didier. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Some problems with the current plugin system in gnucash GUI
Hello, When I wrote the Open the account page after creating a new file patch (https://lists.gnucash.org/pipermail/gnucash-patches/2005-November/016979.html), I used the same mechanism than the one that is used to launch the account hierarchy druid (hooks in the engine). It looked to me to be the only solution because the account tree seems to be designed as a plugin. However, I have a few problems with this architecture: - The GUI actions (in this case, open the account hierarchy druid, open a new account tree page) are managed by a class in the engine module. That's odd to me. engine should be about data and data consistency, not about user interactions. - The order of events is not controlled (you don't know in which order the hooks will be called) - The GUI logic is not defined in a central place. To understand what happens, you have to grep the hooks in all the source code. - The GUI logic is also limited. For instance, you can't abort a sequence if one of the actions (the hooks) is canceled by the user. Did I use the right way to implement the feature ? If yes, aren't we a little to extreme with the concept of plugins in Gnucash ? Didier. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Some problems with the current plugin system in gnucash GUI
Hmm. With this patch, the hook is registered at account-tree
plugin-page class-initialization time, and the hook applies to all new
books, regardless of origin. That doesn't seem quite right on either
count...
What's the difference with the following, in src/gnome/druid-hierarchy.c
?
void
gnc_ui_hierarchy_druid_initialize (void)
{
gnc_hook_add_dangler(HOOK_NEW_BOOK,
(GFunc)gnc_ui_hierarchy_druid_hook, NULL);
}
Didier.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Problems with accounts in gnucash/accounts
Thanks Christian, Here are the encodings I could identify on my Fedora core 2 with the following script run in gnucash/accounts: promtp for i in *; do test -d $i echo $i `LANG=$i locale charmap`; done C ANSI_X3.4-1968 locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory da ANSI_X3.4-1968 - This one is not identified de_CH ISO-8859-1 de_DE ISO-8859-1 el_GR ISO-8859-7 es_ES ISO-8859-1 fr_FR ISO-8859-1 hu_HU ISO-8859-2 locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory it ANSI_X3.4-1968 - This one is not identified locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory ja_JP.EUC ANSI_X3.4-1968 - This one is not identified pt_BR ISO-8859-1 pt_PT ISO-8859-1 locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory sk ANSI_X3.4-1968 - This one is not identified tr_TR ISO-8859-9 Didier. Le ven 11/11/2005 à 16:02, Christian Stimming a écrit : Hi Didier, thanks for the reminder about this issue. I thought to follow up in SVN but forgot so far. I definitely agree with your proposal (a), i.e. the encoding needs to be specified and that's that. The question about an additional encoding conversion from the current iso-8859-1 (?) to utf8 is relatively orthogonal to that and can be performed at a later point in time anyway. I don't agree that shipping non-utf8 files were a bad thing; instead, IMHO we only have to make sure that all files can be interpreted correctly by libxml2. Gnucash will only deal with the utf8-encoded strings that are returned from libxml2. Specifying the encoding is a sufficient solution to this problem. Whether the locale itself is in utf8 or not doesn't actually matter at all, as long as the encoding is specified in the xml file. I will add the encoding in SVN this weekend. Christian Didier Vidal schrieb: Hi everybody, This is a follow-up to the problem of default accounts in the druid launched when you create a new gnucash file. Previous threads can be found: Here: (a thread on the devel list) https://lists.gnucash.org/pipermail/gnucash-devel/2005-October/014308.html And here: (a thread on the patch list) https://lists.gnucash.org/pipermail/gnucash-patches/2005-October/016815.html Quick summary: The xea files in share/gnucash/accounts/LANG are not read correctly in most locales because the XML files don't specify their encoding in the header. As a result, the druid is not functional on all locales that have non utf8 chars in their xea files. Two proposals have been made to fix the problem: a) [my preferred proposition] specify the encoding in the XML files. This proposal is not favored by everybody. Some argue that it is better to ship only utf-8 configuration files in the G2 version of gnucash b) convert all the files to utf-8 (using iconv for instance). This proposal has also a problem: it is inconsistent to put an utf-8 file in a directory named fr_FR, where one would expect to have the regular encoding for this locale (ISO-8859-1). Personally, I would not recommend this approach. I made an additional test: rename accounts/fr_FR to accounts/fr_FR.UTF-8 and convert its content to utf8. Without changing anything to the gnucash code. This does not give satisfaction either: * the druid works well with the locale fr_FR.UTF-8 * BUT the druid uses the english accounts with the locale fr_FR A solution that: - works with all locales (utf8 or not) - does not require to ship non utf8 files - does not require to create misleading directories (ie utf8 content in a directory named fr_FR) would probably require to change the algorithm used to find the default account directory for a given locale. Is anybody knowledgeable on this part ? Is there also a consensus to reject proposition a) ? Didier. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Switching from CVS to Subversion: test svn repo available
Le dim 30/10/2005 à 20:15, Josh Sled a écrit : On Sun, 2005-10-30 at 20:01 +0100, Didier Vidal wrote: I've always wondered why the commits are systematically sent to gnucash-patches... This results in noise and an additional chance to forget or loose patches (since no dedicated tool exists to manage them). Why not just sending the patches, the patches acknowledgments and the patches commits to gnucash-patches ? I guess there's an argument for minimizing mailing-list management... but I could certainly see having 3 lists: - gnucash-patches (manual patch submission + ack + discuss) I would like this one, because it makes it easier than the current situation to track a patch, and see if it is accepted / included in the tree etc. , because patches-related mails are separated from -devel and -commit - gnucash-changes (commit notification, w/ diffs) I've always found this one useful. And it makes sense to separate it from the -devel list. Other tools could replace this list and bring better features (for instance fisheye http://www.cenqua.com/fisheye/ ), but this list is OK. - gnucash-commits (commit notification, w/o diffs) I don't see an immediate use of this one... But maybe other developers prefer this light list Or, optionally, only the first 2. ...jsled ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Switching from CVS to Subversion: test svn repo available
Sorry for answering late to this email. I was traveling last week, and was away from my email... My comment is just about the following specific point: [...] I've setup the post-commit hook to mail the changeset diffs to '[EMAIL PROTECTED]'. Note that a seperate gnucash-patches mail of only the commit notice (without diffs) is *not* setup here. I'm not sure that it will be, either. If you have a strong desire to have a non-diff-containing-per-commit email, speak up now. I've always wondered why the commits are systematically sent to gnucash-patches... This results in noise and an additional chance to forget or loose patches (since no dedicated tool exists to manage them). Why not just sending the patches, the patches acknowledgments and the patches commits to gnucash-patches ? Didier. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] Add commented-out workaround for utf8.
This lists all the variables potentially involved in glibc's gettext (in
case we want to check all them in the same order)
http://www.gnu.org/software/libc/manual/html_node/Using-gettextized-software.html#Using-gettextized-software
Didier.
Le mar 18/10/2005 à 22:55, Didier Vidal a écrit :
From this thread on a debian mailing list, the sed on LAGUAGE should
then be sed -e s/.UTF-8$//g ; since LANGAGE can apparently contain a
semi column separated list of languages.
http://lists.debian.org/debian-glibc/2005/05/msg00219.html
However, the patch is meant to be uncommented, so the user will have
open the file and edit it. Maybe the best way would be to explain that
he can replace LANG by LANGUAGE in a comment, and to keep the number of
lines to uncomment small.
Didier.
Le mar 18/10/2005 à 22:25, Derek Atkins a écrit :
I'm wondering if we should use Jon Lapham's suggestion instead
of this one? I think it would work on more distributions, as
some use LANG and some use LANGUAGE...
http://www.gnucash.org/pipermail/gnucash-devel/2003-September/010418.html
Just my $0.02.
-derek
Christian Stimming [EMAIL PROTECTED] writes:
Log Message:
---
Add commented-out workaround for utf8.
2005-10-17 Christian Stimming [EMAIL PROTECTED]
* src/bin/generate-gnc-script: Add a commented-out workaround for
UTF-8 problems, as proposed by Didier Vidal. To use this
workaround, uncomment the designated line in this file before
build.
Tags:
gnucash-1-8-branch
Modified Files:
--
gnucash:
ChangeLog
gnucash/src/bin:
generate-gnc-script
Revision Data
-
Index: ChangeLog
===
RCS file: /home/cvs/cvsroot/gnucash/ChangeLog,v
retrieving revision 1.1461.2.426
retrieving revision 1.1461.2.427
diff -LChangeLog -LChangeLog -u -r1.1461.2.426 -r1.1461.2.427
--- ChangeLog
+++ ChangeLog
@@ -1,3 +1,10 @@
+2005-10-17 Christian Stimming [EMAIL PROTECTED]
+
+ * src/bin/generate-gnc-script: Add a commented-out workaround for
+ UTF-8 problems, as proposed by Didier Vidal. To use this
+ workaround, uncomment the designated line in this file before
+ build.
+
2005-10-16 Christian Stimming [EMAIL PROTECTED]
* po/glossary/pl.po: Added polish glossary by A. Tokarski
Index: generate-gnc-script
===
RCS file: /home/cvs/cvsroot/gnucash/src/bin/generate-gnc-script,v
retrieving revision 1.2
retrieving revision 1.2.2.1
diff -Lsrc/bin/generate-gnc-script -Lsrc/bin/generate-gnc-script -u -r1.2
-r1.2.2.1
--- src/bin/generate-gnc-script
+++ src/bin/generate-gnc-script
@@ -15,6 +15,10 @@
GUILE_WARN_DEPRECATED=no
export GUILE_WARN_DEPRECATED
+## Uncomment the following line if gnucash
+## shows weird characters in utf8-locales:
+#(echo \$LANG | grep UTF-8 /dev/null ) LANG=\`echo \$LANG | sed
s/\.UTF-8//\`
+
exec ${TARGET_SCRIPT} \$@
EOF
___
gnucash-changes mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-changes
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Tired of the usual gnucash look ?
Just try LANG=ar_AE ./gnucash to see how it looks with an RTL layout By the way I'm not sure all of gnucash works as expected in this case... Didier. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Problems with accounts in gnucash/accounts
The accounts used by the gnucash druid are broken in many locales, including fr_FR, fr_FR.UTF-8, de_DE.UTF-8, de_DE... The problem is that gnucash expects them to be in UTF-8. On locale with ISO-8859-1 charset, if you run the following script, the druid works again: for i in *-xea do mv $i $i.iso cat $i.iso | iconv -f ISO-8859-1 -t UTF-8 $i done However, I'm not sure it's a good idea, since the files will not respect the locale indicated by their directories. The problem lies more in the way these files are read. It's probably not by libxml2. Otherwise: libxml2 would certainly have handled the conversion correctly I also tried to specify the codeset in the XML header, but that didnt fix the problem. How should we handle this ? Didier. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Problems with accounts in gnucash/accounts
Le jeu 20/10/2005 à 23:15, Neil Williams a écrit : On Thursday 20 October 2005 9:52 pm, Didier Vidal wrote: The accounts used by the gnucash druid are broken in many locales, including fr_FR, fr_FR.UTF-8, de_DE.UTF-8, de_DE... The problem is that gnucash expects them to be in UTF-8. AFAICT, gnucash still makes no assumptions about the encoding or expects any particular encoding in the file. Lets say that the GNOME GUI expects to receive utf-8 data then. On locale with ISO-8859-1 charset, if you run the following script, the druid works again: for i in *-xea do mv $i $i.iso cat $i.iso | iconv -f ISO-8859-1 -t UTF-8 $i done What about converting to fr_FR or de_DE ? (and putting that in the encoding as fr-fr and de-de respectively). I run the script on the fr_FR directory. I'm not sure to understand your question. However, I'm not sure it's a good idea, since the files will not respect the locale indicated by their directories. Have you tried converting each directory to the intended locale instead of UTF-8? No. I'm not sure it's a good idea... There is no waranty that each locale has its utf8 counterpart. The problem lies more in the way these files are read. It's probably not by libxml2. Otherwise: libxml2 would certainly have handled the conversion correctly Maybe not if the XML doesn't state the encoding itself. libxml2 does handle XML content as UTF-8 internally (which is why we made the assumption above). I also tried to specify the codeset in the XML header, but that didnt fix the problem. Note that XML doesn't have the same syntax for encoding specifiers - the underscore is generally a hyphen and case is not important. I'll check this. Which codeset? How are you testing the files? Did you set the XML encoding attribute to the codeset for the locale directory of that file? To the file header (? xml version=1.0 encoding=ISO-8859-1 ? I'll double check I didn't make a mistake in this test and email back to the list. Didier. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Problems with accounts in gnucash/accounts
Forget my email. Adding the codeset works. I'll send a patch for the fr_FR directory, and the script I used. Didier. Le jeu 20/10/2005 à 23:27, Didier Vidal a écrit : Le jeu 20/10/2005 à 23:15, Neil Williams a écrit : On Thursday 20 October 2005 9:52 pm, Didier Vidal wrote: The accounts used by the gnucash druid are broken in many locales, including fr_FR, fr_FR.UTF-8, de_DE.UTF-8, de_DE... The problem is that gnucash expects them to be in UTF-8. AFAICT, gnucash still makes no assumptions about the encoding or expects any particular encoding in the file. Lets say that the GNOME GUI expects to receive utf-8 data then. On locale with ISO-8859-1 charset, if you run the following script, the druid works again: for i in *-xea do mv $i $i.iso cat $i.iso | iconv -f ISO-8859-1 -t UTF-8 $i done What about converting to fr_FR or de_DE ? (and putting that in the encoding as fr-fr and de-de respectively). I run the script on the fr_FR directory. I'm not sure to understand your question. However, I'm not sure it's a good idea, since the files will not respect the locale indicated by their directories. Have you tried converting each directory to the intended locale instead of UTF-8? No. I'm not sure it's a good idea... There is no waranty that each locale has its utf8 counterpart. The problem lies more in the way these files are read. It's probably not by libxml2. Otherwise: libxml2 would certainly have handled the conversion correctly Maybe not if the XML doesn't state the encoding itself. libxml2 does handle XML content as UTF-8 internally (which is why we made the assumption above). I also tried to specify the codeset in the XML header, but that didnt fix the problem. Note that XML doesn't have the same syntax for encoding specifiers - the underscore is generally a hyphen and case is not important. I'll check this. Which codeset? How are you testing the files? Did you set the XML encoding attribute to the codeset for the locale directory of that file? To the file header (? xml version=1.0 encoding=ISO-8859-1 ? I'll double check I didn't make a mistake in this test and email back to the list. Didier. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] Add commented-out workaround for utf8.
This lists all the variables potentially involved in glibc's gettext (in
case we want to check all them in the same order)
http://www.gnu.org/software/libc/manual/html_node/Using-gettextized-software.html#Using-gettextized-software
Didier.
Le mar 18/10/2005 à 22:55, Didier Vidal a écrit :
From this thread on a debian mailing list, the sed on LAGUAGE should
then be sed -e s/.UTF-8$//g ; since LANGAGE can apparently contain a
semi column separated list of languages.
http://lists.debian.org/debian-glibc/2005/05/msg00219.html
However, the patch is meant to be uncommented, so the user will have
open the file and edit it. Maybe the best way would be to explain that
he can replace LANG by LANGUAGE in a comment, and to keep the number of
lines to uncomment small.
Didier.
Le mar 18/10/2005 à 22:25, Derek Atkins a écrit :
I'm wondering if we should use Jon Lapham's suggestion instead
of this one? I think it would work on more distributions, as
some use LANG and some use LANGUAGE...
http://www.gnucash.org/pipermail/gnucash-devel/2003-September/010418.html
Just my $0.02.
-derek
Christian Stimming [EMAIL PROTECTED] writes:
Log Message:
---
Add commented-out workaround for utf8.
2005-10-17 Christian Stimming [EMAIL PROTECTED]
* src/bin/generate-gnc-script: Add a commented-out workaround for
UTF-8 problems, as proposed by Didier Vidal. To use this
workaround, uncomment the designated line in this file before
build.
Tags:
gnucash-1-8-branch
Modified Files:
--
gnucash:
ChangeLog
gnucash/src/bin:
generate-gnc-script
Revision Data
-
Index: ChangeLog
===
RCS file: /home/cvs/cvsroot/gnucash/ChangeLog,v
retrieving revision 1.1461.2.426
retrieving revision 1.1461.2.427
diff -LChangeLog -LChangeLog -u -r1.1461.2.426 -r1.1461.2.427
--- ChangeLog
+++ ChangeLog
@@ -1,3 +1,10 @@
+2005-10-17 Christian Stimming [EMAIL PROTECTED]
+
+ * src/bin/generate-gnc-script: Add a commented-out workaround for
+ UTF-8 problems, as proposed by Didier Vidal. To use this
+ workaround, uncomment the designated line in this file before
+ build.
+
2005-10-16 Christian Stimming [EMAIL PROTECTED]
* po/glossary/pl.po: Added polish glossary by A. Tokarski
Index: generate-gnc-script
===
RCS file: /home/cvs/cvsroot/gnucash/src/bin/generate-gnc-script,v
retrieving revision 1.2
retrieving revision 1.2.2.1
diff -Lsrc/bin/generate-gnc-script -Lsrc/bin/generate-gnc-script -u -r1.2
-r1.2.2.1
--- src/bin/generate-gnc-script
+++ src/bin/generate-gnc-script
@@ -15,6 +15,10 @@
GUILE_WARN_DEPRECATED=no
export GUILE_WARN_DEPRECATED
+## Uncomment the following line if gnucash
+## shows weird characters in utf8-locales:
+#(echo \$LANG | grep UTF-8 /dev/null ) LANG=\`echo \$LANG | sed
s/\.UTF-8//\`
+
exec ${TARGET_SCRIPT} \$@
EOF
___
gnucash-changes mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-changes
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] Add commented-out workaround for utf8.
From this thread on a debian mailing list, the sed on LAGUAGE should
then be sed -e s/.UTF-8$//g ; since LANGAGE can apparently contain a
semi column separated list of languages.
http://lists.debian.org/debian-glibc/2005/05/msg00219.html
However, the patch is meant to be uncommented, so the user will have
open the file and edit it. Maybe the best way would be to explain that
he can replace LANG by LANGUAGE in a comment, and to keep the number of
lines to uncomment small.
Didier.
Le mar 18/10/2005 à 22:25, Derek Atkins a écrit :
I'm wondering if we should use Jon Lapham's suggestion instead
of this one? I think it would work on more distributions, as
some use LANG and some use LANGUAGE...
http://www.gnucash.org/pipermail/gnucash-devel/2003-September/010418.html
Just my $0.02.
-derek
Christian Stimming [EMAIL PROTECTED] writes:
Log Message:
---
Add commented-out workaround for utf8.
2005-10-17 Christian Stimming [EMAIL PROTECTED]
* src/bin/generate-gnc-script: Add a commented-out workaround for
UTF-8 problems, as proposed by Didier Vidal. To use this
workaround, uncomment the designated line in this file before
build.
Tags:
gnucash-1-8-branch
Modified Files:
--
gnucash:
ChangeLog
gnucash/src/bin:
generate-gnc-script
Revision Data
-
Index: ChangeLog
===
RCS file: /home/cvs/cvsroot/gnucash/ChangeLog,v
retrieving revision 1.1461.2.426
retrieving revision 1.1461.2.427
diff -LChangeLog -LChangeLog -u -r1.1461.2.426 -r1.1461.2.427
--- ChangeLog
+++ ChangeLog
@@ -1,3 +1,10 @@
+2005-10-17 Christian Stimming [EMAIL PROTECTED]
+
+ * src/bin/generate-gnc-script: Add a commented-out workaround for
+ UTF-8 problems, as proposed by Didier Vidal. To use this
+ workaround, uncomment the designated line in this file before
+ build.
+
2005-10-16 Christian Stimming [EMAIL PROTECTED]
* po/glossary/pl.po: Added polish glossary by A. Tokarski
Index: generate-gnc-script
===
RCS file: /home/cvs/cvsroot/gnucash/src/bin/generate-gnc-script,v
retrieving revision 1.2
retrieving revision 1.2.2.1
diff -Lsrc/bin/generate-gnc-script -Lsrc/bin/generate-gnc-script -u -r1.2
-r1.2.2.1
--- src/bin/generate-gnc-script
+++ src/bin/generate-gnc-script
@@ -15,6 +15,10 @@
GUILE_WARN_DEPRECATED=no
export GUILE_WARN_DEPRECATED
+## Uncomment the following line if gnucash
+## shows weird characters in utf8-locales:
+#(echo \$LANG | grep UTF-8 /dev/null ) LANG=\`echo \$LANG | sed
s/\.UTF-8//\`
+
exec ${TARGET_SCRIPT} \$@
EOF
___
gnucash-changes mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-changes
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Protecting gnucash 1.8.x from utf8 locales
Le lun 17/10/2005 à 11:07, Christian Stimming a écrit :
Dear Didier,
this patch is still pending, isn't it? Has there been any discussion
whether this solution is a good one for the gnucash-1-8-branch?
I haven't been aware of such discussion. Actually, until recently, the
idea was that there would be no more release of gnucash 1.8.
In fact I have been implementing this patch manually ever since I
switched to SuSE9.3, which has a UTF-8 locale by default. I.e. I added
export LANG=de_DE to the gnucash script, and I recommended this to all
the other Germany that complained about the utf8 chars. I'm not sure
whether your concerns about the files from the utf-8 locales are really
valid. I think that would only be the case if people started gnucash,
saw the weird characters, but went ahead nevertheless and entered the
new account names.
Actually, this happened to me: I had no problem unless I used reports. I
believed that reports were broken and didn't use them :-).
After I applied the patch, I had to modify some labels in my
transactions.
The worst case scenario is if the user has started to enter data in
utf-8, then adds more entries in ISO-8859-1. When the user will switch
to Gnucash G2, libxml2 will fail to convert a mixed file (it will still
read it, but fail to convert ISO-8859-1 to utf-8)
However, I think that this wouldn't be the case --
people would first want to fix the weird characters, and that
necessarily means they will switch the gnucash context to non-utf8.
Also, if they use the account templates that are shipped with gnucash,
then the account names are in latin1 anyway.
That's probably why I didn't use them :-)
So becasue for gnucash-1.8.x we know for sure that the respective
libgnomeui doesn't support UTF-8, I think this change is a usable
solution and should be committed to the gnucash-1-8-branch.
That's a difficult decision... One could argue that there is no big
problem for the moment (gnucash users don't complain), and there is a
risk to add this patch... On the other hand, non English-speaking people
that used gnucash with an utf8 locale (that's the case on fedora), may
think that gnucash is broken
Didier.
Christian
Didier Vidal schrieb:
[Resent, my first email bounced because I was not member of the list]
Some linux distribs (including Fedora) set UTF 8 locales by default.
With such locales, GnuCash doesn't behave correctly. In particular,
reports are not displayed correctly (utf8 chars are split in two).
This patch transforms UTF_8 locales into their base locale at startup
and displays a warning.
It assumes locale naming schemes as described at
http://www.linux.org/docs/ldp/howto/Unicode-HOWTO-3.html#ss3.4 and
http://www.iana.org/assignments/character-sets
Note:
This patch is not transparent to gnucash users who already created files
with an utf8 locale. Account names or transaction names they entered
that had unicode letters are no longer displayed correctly. I'll try to
work on a different patch that help display the html reports correctly
also with in an utf8 locale, the only problem I've observed with
gnucash/UTF-8 with fedora's package.
By the way I also observed that gnucash does not write the encoding in
the XML file that is saved. That might be the source of some
locale-related problems, and definitely might be a problem for people
that exchange gnucash files.
Didier Vidal.
--- gnucash-1.8.11/src/bin/generate-gnc-script 2003-01-23
07:30:21.0 +0100
+++ gnucash-1.8.11.utf8protect/src/bin/generate-gnc-script 2005-09-05
00:00:00.255954108 +0200
@@ -15,6 +15,8 @@
GUILE_WARN_DEPRECATED=no
export GUILE_WARN_DEPRECATED
+(echo \$LANG | grep UTF-8 /dev/null ) LANG=\`echo \$LANG | sed
s/\.UTF-8//\` echo UTF-8 not supported. Setting LANG to \$LANG
+
exec ${TARGET_SCRIPT} \$@
EOF
___
gnucash-patches mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-patches
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] Fixing UTF-8 support in X sessions
Actually, adding UTF-8 to an arbitrary locale might be dangerous. It should only be a temporary workaround, but should not make its way to a release. For instance, on fedora2, the Japanese locale doesn't have an utf8 counterpart. (By the way, Japanese translations of gnucash exist... so we must have some users running gnucash in Japanese). prompt locale -a | grep jp ja_JP.eucjp Didier. Le lun 17/10/2005 à 19:41, Derek Atkins a écrit : A better solution would be to change the gnucash code to use the g_locale_to_utf8() API in the gnucash locale settings. We should /not/ force gnucash into a utf8 locale. -derek Christian Stimming [EMAIL PROTECTED] writes: Oops, Neil, sorry for that -- my first complaint obviously was wrong. Turns out I didn't read the generate-gnc-script in full so that I didn't realize the commands are part of the here-document. So the dependence on LANG at compile time doesn't exist, and that is obviously a good thing. Nevertheless my second issue still remains, and I still think that this isn't the solution of the problem you're seeing. Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] Fixing UTF-8 support in X sessions
Also, instead of caling bindtextdomain, we should call bind_textdomain_codeset Didier. Le lun 17/10/2005 à 19:41, Derek Atkins a écrit : A better solution would be to change the gnucash code to use the g_locale_to_utf8() API in the gnucash locale settings. We should /not/ force gnucash into a utf8 locale. -derek Christian Stimming [EMAIL PROTECTED] writes: Oops, Neil, sorry for that -- my first complaint obviously was wrong. Turns out I didn't read the generate-gnc-script in full so that I didn't realize the commands are part of the here-document. So the dependence on LANG at compile time doesn't exist, and that is obviously a good thing. Nevertheless my second issue still remains, and I still think that this isn't the solution of the problem you're seeing. Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Problems building GC (gnome 2)
You probably have the GConf2 package if your machine runs gnome2. But you will need to add the development version (GConf2-devel). That will probably the case for a couple of other packages. Didier. Le dim 16/10/2005 à 08:01, Volker Englisch a écrit : Hi, I'd like to help testing the gnome2 branch of GC when it is ready and I'm trying to prepare by building gnucash from CVS but I got stuck when autogen reported the following error: ... checking if unsigned long is at least as big as guint32... yes checking if guile needs our copy of srfi-1... no checking if guile needs our copy of srfi-11... no checking if guile needs our copy of srfi-19... no checking if guile needs our copy of srfi-2... no checking if guile needs our copy of srfi-8... no checking if guile needs our copy of srfi-9... no checking if guile needs our copy of (guile www)... yes checking for pkg-config... (cached) /usr/bin/pkg-config checking for gconf-2.0 = 2.0... Package gconf-2.0 was not found in the pkg-config search path. Perhaps you should add the directory containing `gconf-2.0.pc' to the PKG_CONFIG_PATH environment variable No package 'gconf-2.0' found configure: error: Library requirements (gconf-2.0 = 2.0) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them. [EMAIL PROTECTED] ~]$ I tried to install (with yum) the package gconf-2.0 but such a package doesn't exist. My system is running on FC4. What am I doing wrong? ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Pango and Debian
Le dim 16/10/2005 à 12:40, Neil Williams a écrit : On Thursday 13 October 2005 9:00 pm, Neil Williams wrote: It's now fine. Problem solved. Account summary and reports are fine - no pango warnings, no missing currency symbols or numbers and no funny prefixes. Forget that. It's still broken. 1) If this is what I believe (message database not translated to utf-8 before display in gnome), it must be a standard Gnome2 problem, and there must be an easy solution implemented in all the Gnome apps. 2) Changing the locale looks more like a hack to me. An application should be able to honnor any locale 3) As a wrokaround, you can use the following patch I use (for the reverse problem :-) ) in gnucash 1.8. Instead of removing UTF-8, add it :-) https://lists.gnucash.org/pipermail/gnucash-patches/2005-September/016559.html Despite setting LANG=en_GB.UTF-8 in ~/.bashrc and despite it appearing in the `set` output in every terminal, loading gnucash from a *menu* still IGNORES the setting. (And yes, I have logged out and logged back in - I made the change on the 13th and despite logging in and out 4 times since then, it was not picked up by gnucash.) Seeing as most users will be starting from an icon, this means that the problem is very much alive. Looks to me like gnucash is reading a system environment, not a per-user environment. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Problems building GC (gnome 2)
probably again libofx-devel missing.
Didier.
Le dim 16/10/2005 à 18:21, Volker Englisch a écrit :
You probably have the GConf2 package if your machine runs gnome2. But
you will need to add the development version (GConf2-devel).
Great. Thank you, Didier.
Based on the error message displayed I was searching for gconf instead
of GConf.
Not entirely unexpected, I am now getting stuck a little further down
the road. The process complains now about libofx:
...
checking for glib-genmarshal... /usr/bin/glib-genmarshal
checking for libofx version = 0.7.0... found 0.7.0
checking for libofx/libofx.h... checking for libofx...
configure: error: *** Cannot compile test program for libofx library.
Please check config.log for the exact error.
[EMAIL PROTECTED] ~]$
This is what's I found in the config.log file:
...
configure:27139: result: /usr/bin/glib-genmarshal
configure:27616: checking for libofx version = 0.7.0
configure:27638: result: found 0.7.0
configure:27647: checking for libofx/libofx.h
configure:27669: gcc -E conftest.c
conftest.c:72:27: error: libofx/libofx.h: No such file or directory
configure:27675: $? = 1
configure: failed program was:
| /* confdefs.h. */
...
| /* end confdefs.h. */
| #include libofx/libofx.h
configure:27752: checking for libofx
configure:2: gcc -o conftest -g -O2conftest.c -lm -lofx 5
conftest.c:73:27: error: libofx/libofx.h: No such file or directory
conftest.c: In function 'main':
conftest.c:79: error: 'LibofxContextPtr' undeclared (first use in this
function)
conftest.c:79: error: (Each undeclared identifier is reported only once
conftest.c:79: error: for each function it appears in.)
conftest.c:79: error: syntax error before 'libofx_context'
conftest.c:80: error: 'libofx_context' undeclared (first use in this
function)
configure:27783: $? = 1
configure: failed program was:
| /* confdefs.h. */
...
| /* end confdefs.h. */
|
| #include libofx/libofx.h
|
| int
| main ()
| {
|
| LibofxContextPtr libofx_context = libofx_get_new_context();
| libofx_free_context(libofx_context);
|
| ;
| return 0;
| }
configure:27804: error: *** Cannot compile test program for libofx
library. Please check config.l
og for the exact error.
...
#define STDC_HEADERS 1
#define VERSION 1.99.0
#define WITH_GTK 1
#endif
#ifdef __cplusplus
extern C void std::exit (int) throw (); using std::exit;
configure: exit 1
Thanks
Volker Englisch
mailto:[EMAIL PROTECTED](h)
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Pango and Debian
On Fedora 2, I don't see any of these warnings. Wheter the locale is fr_FR or fr_FR.utf8. No problem either with en_GB. Pango version is 1.4.1. Didier. Le jeu 13/10/2005 à 15:57, Josh Sled a écrit : On Thu, 2005-10-13 at 09:06 +0100, Neil Williams wrote: It's more than just warnings to the console. Now that I've been building updated trees and testing within G2 regularly, I can report that these pango errors are preventing G2 from displaying any *numbers* or *currency symbols* in the acccount summary or any reports in G2 on Debian. I've not noted problems on FC3 and I'm not quite able to run G2 on OSX yet. Here (gentoo, recent) numbers show fine, though currency symbols don't. I get literally thousands of these - a couple of dozen for every window refresh. I notice that changing my LANG from 'en_GB' to 'en_GB.utf8' makes this go away. Is that true for you too? This is libpango1.0-0 version 1.8.2-2 but it's been occurring with earlier versions too. What versions are others using (so that I can get a start point)? 1.8.1(-r1) on gentoo. ...jsled ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Proposals about gnucash-gnome2
The most basic test is under the Reports menu, under Sample Reports: the 'Test Graphs.' report; all 3 graphs should display as http://asynchronous.org/tmp/graphs.png . Works fine on fedora 2. Didier. ...jsled ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Proposals about gnucash-gnome2
Le sam 08/10/2005 à 20:43, Josh Sled a écrit : On Sat, 2005-10-08 at 20:39 +0200, Didier Vidal wrote: The most basic test is under the Reports menu, under Sample Reports: the 'Test Graphs.' report; all 3 graphs should display as http://asynchronous.org/tmp/graphs.png . Works fine on fedora 2. Sweet; What version of gtkhtml-3, btw? 2.6 the rpm is gtkhtml2-2.6.0-1.src.rpm ...jsled ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Proposals about gnucash-gnome2
Le sam 08/10/2005 à 20:43, Josh Sled a écrit : On Sat, 2005-10-08 at 20:39 +0200, Didier Vidal wrote: The most basic test is under the Reports menu, under Sample Reports: the 'Test Graphs.' report; all 3 graphs should display as http://asynchronous.org/tmp/graphs.png . Works fine on fedora 2. Sweet; What version of gtkhtml-3, btw? Sorry 3.0.10 gtkhtml3-3.0.10-1.src.rpm DidierL ...jsled ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Register rewrite [Was: Confusion about use of G2]
[...] I've been meaning to set up a website for my current progress, but it's never been the most urgent thing. If you think you might be interested in helping, it would be more urgent. Well... I'll have a rush in the next weeks in my job, so I'm not sure how much time I will be able (or feel like) to spend for gnucash in the next month. If there is a simple way to test your implementation without asking to much work from you, I'd like to do it. Otherwise, the current register implementation is more than enough for a pre-alpha release that is discussed on this mailing list. Didier. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Proposals about gnucash-gnome2
[...] An interesting side-effect of a 1.8.12 release is that we as a developer team communicate the fact that we're alive and active and caring about the users, all the while such a release is technically quite easy for us. And of course the respective announcement can be used to communicate the active gnome2 progress. This would be more effective if we could communicate on a target date for a gnome2 beta version of gnucash. Preferably less than 3 month after 1.8.12 Didier. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Register rewrite [Was: Confusion about use of G2]
[...] Since then, I've also made substantial progress on a register-rewrite using the GtkTreeModel API. It's been easier than I thought. (Although I've made no progress in the past 2 months - no time.) Chris, I'd be curious to see how this register implementation works. There are still a couple of low-level bugs in the register-gnome implementation I discovered recently: * You can't resize the gnucash window when a register is open * text selection doesn't work well if the text contains accented chars * left-arrow + shift while attempting to select text creates unusual behaviours * probable focus problem when using the account selection combo box * impractical text justification for account names (you see the beginning of the name, not the end that most of the time is the relevant part, if you have nested accounts). * missing tooltips for long strings I your implementation is advanced enough, it might be worth considering if it is not a faster path to a robust implementation of the register. Didier. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash CVS broken again - ? Not on FC3/OSX/Debian.
[...] You also made the same mistakes with exit conditions in the conversion of QOF_BEGIN_EDIT from a macro to a function. In this case you got lucky that there was no code in xaccAccountBeginEdit() following the call to qof_begin_edit() so the code ends up working as expected. If code is ever added to this function after the call to qof_begin_edit() then all bets are off. There is a crash condition that is solved if you replace qof_begin_edit() by the macro in xaccTransBeginEdit () [Transaction.c]. Condition: In the register, edit partially a new transaction (set date, name, target account, but no amount). Then give the focus to an other row. When gnucash asks whether to save the transaction, say no. I'll post a patch for this. Didier. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Testing locale change from gnucash 1.8 to gnucash-g2
So, here is what I understand of the situation with encoding:
* internally, gnucash-g2 data are in utf-8, whatever the locale used
to launch gnucash. What lead me to believe this is a trace I added in
xaccAccountSetName, in src/engine/Account.c
void
xaccAccountSetName (Account *acc, const char *str)
{
char * tmp;
printf(xaccAccountSetName: %s\n, str);
* the encoding conversion when reading a file seems to be handled
correctly by libxml2, even if the file doesn't respect the XML spec and
doesn't specify its encoding.
* gnucash-g2 seems to write the xml files in ISO-8859-1, whatever the
locale used to launch gnucash (at least on my machine). I don't yet
understand why.
* The code pointed by Neil
(fprintf(out, ?xml version=\1.0\?\n); in io-gncxml-v2.c)
is not called when you save a gnucash file. Anyway, it seems dangerous
to me to write an encoding specification in this part if we don't know
the actual encoding that will be used to write the rest of the file. I
agree with David that utf-8 is a good target.
Didier.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Testing locale change from gnucash 1.8 to gnucash-g2
What lead me to believe this is a trace I added in
xaccAccountSetName, in src/engine/Account.c
[...]
void
xaccAccountSetName (Account *acc, const char *str)
{
char * tmp;
printf(xaccAccountSetName: %s\n, str);
? The actual source code doesn't use printf:
The printf is the trace I added (locally).
[..]
* gnucash-g2 seems to write the xml files in ISO-8859-1, whatever the
locale used to launch gnucash (at least on my machine). I don't yet
understand why.
I've just tried that on my system and I can find no char set conversion -
it's
output as UTF-8.
That's strange. Which letter did you use in your test that was not ASCII
? Did it have a different encoding in ISO_8859-1 and UTF-8 ?
* The code pointed by Neil
(fprintf(out, ?xml version=\1.0\?\n); in io-gncxml-v2.c)
is not called when you save a gnucash file.
??? Umm, it is:
I'll dig in this code later. The test I made is to add a printf in the
routine and see if it is executed when I save a file. But maybe I did a
wrong manip there.
Didier.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Testing locale change from gnucash 1.8 to gnucash-g2
Le dim 25/09/2005 à 11:55, Neil Williams a écrit : On Sunday 25 September 2005 9:59 am, Didier Vidal wrote: So, here is what I understand of the situation with encoding: * internally, gnucash-g2 data are in utf-8, whatever the locale used to launch gnucash. True. What lead me to believe this is a trace I added in xaccAccountSetName, in src/engine/Account.c It's the libxml2 documentation that should have told you about UTF-8. Assuming I know and understand what happens between libxml2, gtk, and internal gnucash data. I'm far for this point for the moment. That's why I use an 'experimental' approach Didier. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Testing locale change from gnucash 1.8 to gnucash-g2
Le dim 25/09/2005 à 11:55, Neil Williams a écrit : [...] * The code pointed by Neil (fprintf(out, ?xml version=\1.0\?\n); in io-gncxml-v2.c) is not called when you save a gnucash file. ??? Umm, it is: You are right, Neil. It is called. I did an error in my test. Now, I know where to search from, to find this mysterious encoding conversion (to ISO-8859-1) that takes place on my machine. Didier. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Gnucash and utf-8 : summary
Finally, gnucash looks fine with utf-8. Neil's suggestion to write the encoding in write_v2_header in io-gncxml-v2.c makes a lot of sense. The error I observed (é written with an ISO-8859-1 encoding) was due to a bug in libxml. I had libxml 2.6.16 on my machine. I downloaded libxml 2.6.20 and the bug disappeared. The fix might be related to this email http://mail.gnome.org/archives/xml/2004-November/msg00192.html From my tests, with a correct libxml realease, gnucash writes in utf-8 whatever the current locale is. So, there is no encoding problem. Didier. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash and utf-8 : summary
Le dim 25/09/2005 à 18:03, Derek Atkins a écrit : Quoting David Hampton [EMAIL PROTECTED]: On Sun, 2005-09-25 at 17:40 +0200, Didier Vidal wrote: From my tests, with a correct libxml realease, gnucash writes in utf-8 whatever the current locale is. So, there is no encoding problem. Hallelujah! Except for the fact that FC3 ships 2.6.16... But yes, definitely a good thing. :) Even with 2.6.16 of libxml, there is no *visible* problem as long as you keep opening your file with libxml. Didier. David -derek ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash and utf-8 : summary
First, I apologize for an error I made in parent email. The libxml version I tested that fixed the problem is 2.6.22. It didn't require any change in the gnucash code (ie: still using xmlNodeDump) The actual bug report in libxml is http://bugzilla.gnome.org/show_bug.cgi?id=159547 Daniel Veillard considers the fix 'risky business' that 'may be changed again'. I think his previous behavior was buggy anyway, because he didn't escape utf-8 chars, but ISO-8859-1 chars, at least from what I observed on my fedora. Didier Vidal. Le dim 25/09/2005 à 18:51, Neil Williams a écrit : On Sunday 25 September 2005 4:40 pm, Didier Vidal wrote: gnucash looks fine with utf-8. Neil's suggestion to write the encoding in write_v2_header in io-gncxml-v2.c makes a lot of sense. (I wish my other code problems were so easy to solve!) The error I observed (é written with an ISO-8859-1 encoding) was due to a bug in libxml. I had libxml 2.6.16 on my machine. I'm not so sure that it was confirmed as a bug. The question about whether it should be filed as a bug was not answered in the archive. It was more that the API changed and new calls created to provide the level of control the enquirer wanted over the encoding. That is a risk with all libraries. As I read it, using the new function did solve the problem. It may not have been good to change an existing function behaviour but there was a hint that the problem arose from engaging with the API at too low a level. Except for the fact that FC3 ships 2.6.16... But yes, definitely a good thing. :) Even with 2.6.16 of libxml, there is no *visible* problem as long as you keep opening your file with libxml. With the encoding specified in future XML, even this theoretical problem should disappear, including on FC3. (Which is why the standard exists, after all.) I downloaded libxml 2.6.20 and the bug disappeared. The fix might be related to this email http://mail.gnome.org/archives/xml/2004-November/msg00192.html As I read that, it relates to outputbuffers that GnuCash never used - at least not directly. So, there is no encoding problem. But there is a net benefit. Thanks for highlighting this - it's something I'd missed and now there is a fix on it's way. Good news all round. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash and utf-8 : summary
Le dim 25/09/2005 à 19:08, Didier Vidal a écrit : First, I apologize for an error I made in parent email. The libxml version I tested that fixed the problem is 2.6.22. It didn't require any change in the gnucash code (ie: still using xmlNodeDump) I meant xmlElemDump Didier. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Testing locale change from gnucash 1.8 to gnucash-g2
Hello, GnuCash has a problem with encoding: it doesn't write the encoding system in the XML files it saves. (if encoding is not utf-8 or utf-16, it must be specified: http://www.w3.org/TR/REC-xml/#charencoding) The potential problems are: - If someone switches to a new linux distrib (that uses an other locale) and wants to use files created on the old distrib - If someone switches to gnucash-g2 and wants to use it in utf8 - If someone sends a gnucash file by email to a friend that runs an other locale on the machine Fortunately, libxml2 seems to have a robust behaviour (described at http://www.xmlsoft.org/encoding.html#implemente ). I ran some tests and gnucash-g2 seems to load properly my gnucash 1.8 files (created with charset ISO-8859-1) even if the current locale has an utf-8 charset (my default locale is fr_FR.UTF-8, but I run gnucash 1.8 with fr_FR). From these *limited* tests, the problem seems not to be a big problem for users that will migrate to the gnome 2 version of gnucash. In case of problems, the workaround would be simple anyway: users should edit the xml file and replace ?xml version=1.0? by?xml version=1.0 encoding=(result of 'locale charmap')? However, from my tests, gnucash still doesn't follow the XML standard: - It will save your files in the locale's charset without writing the encoding in the header. - The non-ascii chars seem to be written as entities (eg: #xE9;). They might be read without problem if you are in a wrong locale, but will not be converted to the right character. Because libxml2 is smart, and can guess encoding, I haven't seen any actual problem if you are using your files only with gnucash. It would be better to write the encoding in the XML file. I'll try to see if I can find time to make a patch for it, but I can't promise anything. So, if someone volunteers in the mailing list, let me know :-) Didier. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Testing locale change from gnucash 1.8 to gnucash-g2
Le sam 24/09/2005 à 21:30, Derek Atkins a écrit :
Quoting Neil Williams [EMAIL PROTECTED]:
Not hard - the GnuCash file backend doesn't use libxml2 for this part of the
file so it's a one line change in write_v2_header func in
src/backend/file/io-gncxml-v2.c. I'll put it into my next commit:
-fprintf(out, ?xml version=\1.0\?\n);
+fprintf(out, ?xml version=\1.0\ encoding=UTF-8?\n);
I need to do it in QSF too where it will be done via libxml2.
Shouldn't this only be done IFF the datafile is actually in UTF-8? I mean, if
the datafile is still iso-8859-1 wont this cause problems?
Actually, after sending my first email, I tested how gnucash-g2 saves a
file that contains non ASCII letters (ie: é) with LANG=fr_FR.UTF-8.
I was surprised to see that it looks like the XML file is in ISO-8859-1
('é' is coded #xE9;, while utf-8 code would be c3A9 from what I observe
in emacs in hexl-mode). Now, I'm lost. Looks like ISO-8859-1 is
hardcoded somewhere in gnucash data...
Didier.
-derek
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Testing locale change from gnucash 1.8 to gnucash-g2
The solution is probably in qofquery-serialize.c...
Looks like qof is used by the file backend (sorry, I'm still totally
newbie about gnucash modules).
Didier.
find . -type f -name '*.c' -exec grep 8859 {} \; -print
xmlNodeDumpOutput (xbuf, NULL, topnode, 99, 99, iso-8859-1);
./engine/qofquery-serialize.c
static const gchar* LABEL_FONT_NAME =
-adobe-helvetica-bold-r-normal--*-100-*-*-p-*-iso8859-1;
./gnome-utils/gnc-dense-cal.c
UTF-8, ISO-8859-15,
./import-export/hbci/dialog-hbcitrans.c
Le sam 24/09/2005 à 22:43, Didier Vidal a écrit :
Le sam 24/09/2005 à 21:30, Derek Atkins a écrit :
Quoting Neil Williams [EMAIL PROTECTED]:
Not hard - the GnuCash file backend doesn't use libxml2 for this part of
the
file so it's a one line change in write_v2_header func in
src/backend/file/io-gncxml-v2.c. I'll put it into my next commit:
-fprintf(out, ?xml version=\1.0\?\n);
+fprintf(out, ?xml version=\1.0\ encoding=UTF-8?\n);
I need to do it in QSF too where it will be done via libxml2.
Shouldn't this only be done IFF the datafile is actually in UTF-8? I mean,
if
the datafile is still iso-8859-1 wont this cause problems?
Actually, after sending my first email, I tested how gnucash-g2 saves a
file that contains non ASCII letters (ie: é) with LANG=fr_FR.UTF-8.
I was surprised to see that it looks like the XML file is in ISO-8859-1
('é' is coded #xE9;, while utf-8 code would be c3A9 from what I observe
in emacs in hexl-mode). Now, I'm lost. Looks like ISO-8859-1 is
hardcoded somewhere in gnucash data...
Didier.
-derek
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] Fix function name.
[...] HACK ALERT: the scan and print routines should probably be moved to somewhere else. The engine really isn't involved with things like printing formats. This is needed mostly by the GUI and so on. If a file-io backend needs date handling, it should do it itself, instead of depending on the routines here. If a file-io backend needs date handling, and the UI needs date handling, shouldn't they share a common set of functions? Isn't gnc- date.c the appropriate existing shared file? Book_Merge and QSF already follow this advice by using strftime and QOF_UTC_DATE_FORMAT. http://qof.sourceforge.net/doxy/group__Date.html#ga57 In general, message formats, date formats, number formats are not considered as GUI. I don't know enough the GnuCash module organization yet to comment specifically here. Formatting is definitely user-facing, but pretty independant from a GUI implementation, or any interaction process. It can be used for a Gnome UI, a Web UI, a reporting module, a log system etc... It's closer to an international message database than to a GUI implementation I would say. Didier. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Problem with configure.in, AM_PATH_GWRAP and g-wrap 1.9
autogen.sh when using g-wrap 1.9. Does Fedora Core include some additional compatibility code in g-wrap 1.9 that is not included in Debian? I don't think so The g-wrap version that comes with fedora 4 is 1.3.4. http://download.fedora.redhat.com/pub/fedora/linux/core/4/SRPMS/ ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
