Problems with accounts in gnucash/accounts

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Problems with accounts in gnucash/accounts

Didier Vidal
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
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problems with accounts in gnucash/accounts

Andreas Köhler
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Problems with accounts in gnucash/accounts

Christian Stimming
In reply to this post by Didier Vidal
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
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problems with accounts in gnucash/accounts

Didier Vidal
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
> > [hidden email]
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problems with accounts in gnucash/accounts

Derek Atkins
In reply to this post by Andreas Köhler
Andreas Köhler <[hidden email]> writes:

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

Yep..  At least 250 million people use this currency every day. :)

-derek
--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [hidden email]                        PGP key available

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problems with accounts in gnucash/accounts

Andrew Sackville-West


Derek Atkins wrote:
> Andreas Köhler <[hidden email]> writes:
>
>
>>PS: Is this <cmdty:id>USD</cmdty:id> still in active use?
>
>
> Yep..  At least 250 million people use this currency every day. :)

+5 Funny

>
> -derek
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: Problems with accounts in gnucash/accounts

Christian Stimming
In reply to this post by Didier Vidal
Ok, this has been fixed now in SVN.

Note that it is definitely non-trivial to find out the original encoding of
the files. Some were in ISO-8859-1, others in UTF-8, others in yet another
encoding.

Maybe at some day someone might want to change the encoding in these files,
but since it is now correctly specified I don't really care. In any case one
needs to make sure that the strings actually show up in the wizard.

Christian

Am Donnerstag, 10. November 2005 20:43 schrieb Didier Vidal:

> 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.htm
>l
>
> 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.
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel