[Kmymoney-devel] Re: Review Request: Updates to CSV Plugin

[Thomas Baumgart]

Hi,

on Wednesday 05 January 2011 01:43:44 Allan Anderson wrote:

> > On 2011-01-04 12:38:35, Cristian Onet wrote:
> > > I don't know if this ever worked but now that I can import my bank
> > > statement with this patch I have a problem with the amounts. My bank
> > > has '.' as a decimal separator and ',' as thousands separator it seems
> > > that the plugin can't handle that. The text delimiter option seems to
> > > work fine.
> >
> > Allan Anderson wrote:
> >     That's strange - those are my settings too.  Also, in the file you
> > sent, there is an item with a thousand separator and decimal point and
> > that imports for me OK.
> >
> >     My first thought was your locale settings, but obviously that's daft
> > as you'd have noticed that many moons ago.
> >
> >     What exactly happens?  Can you import the file you sent to me?  When
> > I import it, all I have to do is set the field separator to ";" and it
> > displays and imports perfectly.
> >
> >     If you are able to anonimize your file in question, I'd better have a
> > look.
> >
> >
> > Allan Anderson wrote:
> >     An after-thought.  It looks like your bank and your locale aren't on
> > speaking terms.  If you haven't already tried this, could you temporarily
> > switch to UK locale and try again, please?
> >
> > Cristian Onet wrote:
> >     Setting the decimal separator in locale to '.' fixes this problem but
> > it leaves my system with a strange locale. AFAIK the MyMoneyMoney object
> > takes the decimal/thousand separator decision based on which one is first
> > (if they are both present) in the string.
> >
> > Cristian Onet wrote:
> >     Locale should matter when displaying data not when importing it.
> >
> > Allan Anderson wrote:
> >     < Locale should matter when displaying data not when importing it.
> >
> >     But, how can it display correctly if it hasn't been imported
> > correctly?
> >
> >     I've imported several files in 'EU' locale, by setting my locale
> > appropriately, so to my naive thinking, it looks like the locale is
> > involved.
> >
> >     What do you suggest?  I would think that in the majority of cases, a
> > user's file will be in his native locale, but obviously that can't now be
> > taken for granted.  The present UI already is pretty busy, and copes with
> > most cases.  What about, in the exceptional circumstance, allowing
> > specification of the decimal separator in the resource file, so it's
> > invisible in normal use?
> >
> >
> > Cristian Onet wrote:
> >     I would prefer autodetection but leave it as it is for now. Please
> > submit the patch.
> 
> Now that the patches are out of the way, I've had a quick and dirty first
>  hack at this.  With a file having 'EU' type ',' decimal separator, I've
>  inserted a replace(',', 'locale version'), which does the trick.  Needs
>  more thought because the decimal separator has now become a thousand
>  separator, and I don't want to convert it back!  How fussy are we about
>  thousand separators?  Could I just remove them?  Or, use my brain a bit
>  more?

This is a general problem I already tried to tackle in 
MyMoneyQifProfile::scanNumeric(). The QIF importer drops the thousands 
separator so we can simply ignore it. The only important part is the decimal 
symbol. There is one ambiguity though:

What does "100,000" mean? Is it 100 with three decimals or is it 100 thousand 
w/o decimals? The QIF importer takes it as 100 with three decimals.


-- 

Regards

Thomas Baumgart

GPG-FP: E55E D592 F45F 116B 8429   4F99 9C59 DB40 B75D D3BA
-------------------------------------------------------------
Flying is absolutely safe as long as you land as often
as you take off. -- Klaus Klages
-------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 225 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kmymoney-devel/attachments/20110105/c533644c/attachment.sig