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

[allan]

On 05/01/11 08:14, Thomas Baumgart wrote:
> 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.
My thought was, as the first step, remove any KLocale (or custom) 
thousand separators.  So what 100,000 would become, would depend on that 
separator setting.  So, I wouldn't really be faced with that decision, 
(I think).

Allan