Problems with accounts in gnucash/accounts

Andreas Köhler andi5.py at gmx.net
Thu Nov 10 16:51:42 EST 2005


Hi,

> 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) ?


Well, I have not read the whole discussion, i just wanted to state
three things:

1) XML files without specified encoding are illegal when they
   contain non-ASCII characters, are not they?

2) I have updated the german accounts directory, will send the patch
   soon, in case you want it ;-) See 3) for the format, there was
   even one account missing I had in my debian gnucash 1.8. Maybe it
   was added after some branching? Might be interesting for other
   locales too.

3) I would prefer files in UTF-8 (with specified encoding, of
   course). Would that be somehow problematic for non-utf8ers? If
   you know the used encoding (oldenc) in some directory, you might
   use:

   cat some.gnucash-xea | recode oldenc..u8,html-i18n..u8 | \
   sed '1s/\(?xml version="1.0"\)?>$/\1 encoding="UTF-8"?>/'

   This also converts &#xyz; entities, I like that.

-- andi5


PS: Is this <cmdty:id>USD</cmdty:id> still in active use?


More information about the gnucash-devel mailing list