[Kmymoney-devel] extragear/office/kmymoney/kmymoney/plugins/csvimport

Jack ostroffjh at sbcglobal.net
Thu Aug 18 15:07:03 UTC 2011


In addition, we were wondering if there might be any point in translating the 
default resource file included - and if so, how?  I think what might be good is 
not to just translate the resource file, but to add to it the most likely terms 
used (transaction type) in the local language.  I can imagine describing this in 
instructions to translators, but I'm not sure how the current translation 
process would allow for it.




________________________________
From: aga <agander93 at gmail.com>
To: kmymoney-devel at kde.org
Sent: Thu, August 18, 2011 10:28:17 AM
Subject: Re: [Kmymoney-devel] 
extragear/office/kmymoney/kmymoney/plugins/csvimport

On Thu, 18 Aug 2011 14:05:43 +0200
Thomas Baumgart <thb at net-bembel.de> wrote:

> Hi,
> 
> on Thursday 18 August 2011 13:26:26 Allan Anderson wrote:
> 
> > SVN commit 1247935 by allananderson:
> > 
> > BUG: 280295
> > 
> > A number of strings in investprocessing.cpp needed to be
> > translated.  They are specimen/generic strings a broker/financial
> > institution might choose to use to describe an investment activity
> > type, such as 'buy' or 'purchase' etc.
> > 
> > 
> >  M  +12 -7     investprocessing.cpp
> > 
> > 
> > ---
> > trunk/extragear/office/kmymoney/kmymoney/plugins/csvimport/investprocessin
> > g.cpp #1247934:1247935 @@ -138,13 +138,18 @@
> >    m_dateFormat = m_dateFormats[m_dateFormatIndex];
> >    m_csvDialog->button_import->setEnabled(false);
> > 
> > -  m_buyList += "buy";//                       some basic entries
> > in case rc file missing -  m_sellList += "sell";
> > -  m_divXList += "dividend";
> > -  m_reinvdivList += "reinv";
> > -  m_shrsinList += "add";
> > -  m_removeList += "remove";
> > -  m_brokerageList << "check" << "payment";
> > +  //  The following string list strings are descriptions of
> > possible investment +  //  activity types.  Each of the lists may
> > also contain alternative descriptions, +  //  added by the user to
> > the resource file, to suit his needs.
> > +
> > +  m_buyList += i18nc("verb", "buy");//                       some
> > basic entries in case rc file missing +  m_sellList +=
> > i18nc("verb", "sell");
> > +  m_divXList += i18nc("noun, cash dividend", "dividend");
> > +  m_reinvdivList += i18nc("verb, to reinvest", "reinvest");
> > +  m_shrsinList += i18nc("verb", "add");
> > +  m_removeList += i18nc("verb, to delete", "remove");
> > +  m_brokerageList << i18nc("noun, cheque, check", "check") <<
> > i18nc("noun", "payment"); +
> >    findCodecs();//                             returns m_codecs =
> > codecMap.values(); }
> 
> 
> I am not sure, if this is the right way. Aren't these strings ('buy',
> 'add', etc.) are found in a CSV file? Now if you enclose them in
> i18n() then you would not be able to import a file with English
> headers while using the German translation, as the list would only
> contain "kaufen" but the entry in the CSV would be "buy".
> 
> Or am I missing something?
> 


These aren't actually headers, but are the type field contents for each
transaction.


I've seen only a few examples of investment CSV files, but it's pretty
obvious that there are numerous variations in activity descriptions.
For all its faults, QIF did have standard descriptions.  So, I decided
to keep a list of descriptions for each activity type.  The plugin
scans each list, and if it finds a match, then that gives the
investment type needed.  If no match if found, it examines the fields of
the transaction to determine its likely type/s.  The transaction is
then displayed, with probable types in a combobox for the user to
choose.

So, the lists are of alternative descriptions.  On first startup, the
plugin populates each list with a single entry, presently in English
only.  The lists will need to be expanded in the resource file by the
user adding his own broker's actual examples, or he will have to make a
decision for each transaction.

If the initial examples are only in English, the user will be
non-the-wiser, but having them translated will give more of a clue
about what's needed.  A mixture of languages in the lists wouldn't be a
problem.  I think.

Hope that helps.  If not, let me know.

A related point that emerged is that Jack and I spent some time on the
manual and in the subsequent queries, we both realised that when the
manual gets translated, how does one say,'Don't translate this bit as
it interacts with the app.', like it's part of the GUI, but might not
be, like in the resource file?

And, can one comment the source file?

Allan


_______________________________________________
KMyMoney-devel mailing list
KMyMoney-devel at kde.org
https://mail.kde.org/mailman/listinfo/kmymoney-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20110818/e74fcaea/attachment.html>


More information about the KMyMoney-devel mailing list