<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div>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.<br></div><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><br><div style="font-family:arial, helvetica, sans-serif;font-size:14pt"><font face="Tahoma" size="2"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> aga <agander93@gmail.com><br><b><span style="font-weight: bold;">To:</span></b>
kmymoney-devel@kde.org<br><b><span style="font-weight: bold;">Sent:</span></b> Thu, August 18, 2011 10:28:17 AM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: [Kmymoney-devel] extragear/office/kmymoney/kmymoney/plugins/csvimport<br></font><br>
On Thu, 18 Aug 2011 14:05:43 +0200<br>Thomas Baumgart <<a ymailto="mailto:thb@net-bembel.de" href="mailto:thb@net-bembel.de">thb@net-bembel.de</a>> wrote:<br><br>> Hi,<br>> <br>> on Thursday 18 August 2011 13:26:26 Allan Anderson wrote:<br>> <br>> > SVN commit 1247935 by allananderson:<br>> > <br>> > BUG: 280295<br>> > <br>> > A number of strings in investprocessing.cpp needed to be<br>> > translated. They are specimen/generic strings a broker/financial<br>> > institution might choose to use to describe an investment activity<br>> > type, such as 'buy' or 'purchase' etc.<br>> > <br>> > <br>> > M +12 -7 investprocessing.cpp<br>> > <br>> > <br>> > ---<br>> > trunk/extragear/office/kmymoney/kmymoney/plugins/csvimport/investprocessin<br>> > g.cpp #1247934:1247935 @@ -138,13 +138,18 @@<br>> >
m_dateFormat = m_dateFormats[m_dateFormatIndex];<br>> > m_csvDialog->button_import->setEnabled(false);<br>> > <br>> > - m_buyList += "buy";// some basic entries<br>> > in case rc file missing - m_sellList += "sell";<br>> > - m_divXList += "dividend";<br>> > - m_reinvdivList += "reinv";<br>> > - m_shrsinList += "add";<br>> > - m_removeList += "remove";<br>> > - m_brokerageList << "check" << "payment";<br>> > + // The following string list strings are descriptions of<br>> > possible investment + // activity types. Each of the lists may<br>> > also contain alternative descriptions, + // added by the user to<br>> > the resource file, to suit his needs.<br>> > +<br>> > +
m_buyList += i18nc("verb", "buy");// some<br>> > basic entries in case rc file missing + m_sellList +=<br>> > i18nc("verb", "sell");<br>> > + m_divXList += i18nc("noun, cash dividend", "dividend");<br>> > + m_reinvdivList += i18nc("verb, to reinvest", "reinvest");<br>> > + m_shrsinList += i18nc("verb", "add");<br>> > + m_removeList += i18nc("verb, to delete", "remove");<br>> > + m_brokerageList << i18nc("noun, cheque, check", "check") <<<br>> > i18nc("noun", "payment"); +<br>> > findCodecs();// returns m_codecs =<br>> > codecMap.values(); }<br>> <br>> <br>> I am not sure, if this is the right way. Aren't these strings ('buy',<br>> 'add', etc.) are
found in a CSV file? Now if you enclose them in<br>> i18n() then you would not be able to import a file with English<br>> headers while using the German translation, as the list would only<br>> contain "kaufen" but the entry in the CSV would be "buy".<br>> <br>> Or am I missing something?<br>> <br><br><br>These aren't actually headers, but are the type field contents for each<br>transaction.<br><br><br>I've seen only a few examples of investment CSV files, but it's pretty<br>obvious that there are numerous variations in activity descriptions.<br>For all its faults, QIF did have standard descriptions. So, I decided<br>to keep a list of descriptions for each activity type. The plugin<br>scans each list, and if it finds a match, then that gives the<br>investment type needed. If no match if found, it examines the fields of<br>the transaction to determine its likely type/s. The transaction is<br>then displayed, with
probable types in a combobox for the user to<br>choose.<br><br>So, the lists are of alternative descriptions. On first startup, the<br>plugin populates each list with a single entry, presently in English<br>only. The lists will need to be expanded in the resource file by the<br>user adding his own broker's actual examples, or he will have to make a<br>decision for each transaction.<br><br>If the initial examples are only in English, the user will be<br>non-the-wiser, but having them translated will give more of a clue<br>about what's needed. A mixture of languages in the lists wouldn't be a<br>problem. I think.<br><br>Hope that helps. If not, let me know.<br><br>A related point that emerged is that Jack and I spent some time on the<br>manual and in the subsequent queries, we both realised that when the<br>manual gets translated, how does one say,'Don't translate this bit as<br>it interacts with the app.', like it's part of
the GUI, but might not<br>be, like in the resource file?<br><br>And, can one comment the source file?<br><br>Allan<br><br><br>_______________________________________________<br>KMyMoney-devel mailing list<br><a ymailto="mailto:KMyMoney-devel@kde.org" href="mailto:KMyMoney-devel@kde.org">KMyMoney-devel@kde.org</a><br><a href="https://mail.kde.org/mailman/listinfo/kmymoney-devel" target="_blank">https://mail.kde.org/mailman/listinfo/kmymoney-devel</a><br></div></div>
</div></body></html>