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

[allan]

I'd meant to copy to list as well.

Allan

-------- Original Message --------
Message-ID: <4D24751D.7060405 at gmail.com>
Date: Wed, 05 Jan 2011 13:41:49 +0000
From: allan <agander93 at gmail.com>
Reply-To: agander93 at gmail.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.2.13) 
Gecko/20101206 SUSE/3.1.7 Thunderbird/3.1.7
MIME-Version: 1.0
To: Thomas Baumgart <thb at net-bembel.de>
Subject: Re: [Kmymoney-devel] Re: Review Request: Updates to CSV Plugin
References: <20110104123832.2618.91100 at vidsolbach.de> 
<201101050914.49805.thb at net-bembel.de> <4D245394.90507 at gmail.com> 
<201101051341.49518.thb at net-bembel.de>
In-Reply-To: <201101051341.49518.thb at net-bembel.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 05/01/11 12:41, Thomas Baumgart wrote:
> Hi,
>
> on Wednesday 05 January 2011 12:18:44 allan wrote:
>
> [...]
>
>>> 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).
> As mentioned before (also in this thread) I would not rely on the fact that
> the CSV file uses the same locale as the user. This could be due to one of the
> following cases:
>
> * a user country A lives in country B with a different locale but still uses
> the one of country A and receives a statements from a bank in country B using
> locale B
>
> * a user in country A using locale A receives a statement from a foreign bank
> in locale B
>
> * a user in country A using locale A receives a statement from a bank in
> country A which happens to write the data in a different locale.
>
> And believe me, I have seen these scenarios while working on the QIF importer
> ;)
>

Yes, I've realised the issue exists.  From the files I had earlier received
in non-UK locale, I'd switched to the appropriate locale to ensure all went
well.  Then, I received Cristian's file, which, straight off, imported
correctly.
Sadly. it turned out to be un-typical of his requirement.

To cope with this eventuality, at the moment what I'm assuming will work
is that
the user wants his file to finish up in the locale of the machine he's
using.  So,
if the user specifies he wants to replace the decimal separator values
in his file,
and what they are, then I'll replace/remove them and substitute the
current locale
equivalent.  If his file is in 'A', his current locale is 'B', but what
he really wants is
output in 'C', then that is going to get too messy for words.
Hopefully, that is not
what Cristian requires at the moment.

Allan