Problems with accounts in gnucash/accounts

Didier Vidal didier-devel at 9online.fr
Fri Nov 11 12:17:25 EST 2005


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 at gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> > 



More information about the gnucash-devel mailing list