Porting KLocale::formatMoney()/readMoney() to Qt5/KF5, best practise?

[Friedrich W. H. Kossebau]

Hi Tomas,

Am Mittwoch, 6. Januar 2016, 12:09:05 schrieb Tomas Mecir:
> Hey Friedrich and others!
> 
> I've hit the very same issue in Sheets earlier that you did, and ended up
> postponing that part of the porting (though I do have a local branch with
> partial results).

Yes, I saw your commenting commits. IIRC Mek also already had a look at it in 
October or so, and postponed as well. Like I also did before, I had a proof-
of-concept libkolocale as fork/import of the used parts of KLocale, but that 
seemed wrong to do, so I dumped it and hoped someone else would have a better 
idea. But with everyone incl. you having postponed now, there was noone left 
to hope for :)

> Not really sure what the best solution would be - the
> problem with KLocale is that it seems to be out of sync with QLocale, so
> for me at least they both report different locales/languages. Weird, that.

You mean when requesting the system QLocale and system KLocale, right? That is 
possibly because both use different env vars and config settings to decide on 
the system's locale (LC_* vs. other stuff, incl. klocale config, latter no 
longer exposed in plasma5 systemsettings app and thus unreliable).
>From what I tried this can be worked around by using the system QLocale id 
strings when creating the "system" KLocale:
    QLocale locale;
    klocale = new KLocale( QLocale::languageToString(locale.language()),
                           QLocale::countryToString(locale.country()) );
But not studied in detail, so maybe something is still 

> Anyway. I've looked at QLocale's code, and adding precision to the
> formatting routines would be trivial technically - the routine called by
> formatMoney supports it, so it's just a matter of adding an optional
> argument to formatMoney - should even be BIC, as I understand it. Not sure
> how easy/hard it'd be to get the change into Qt.

That bit sounds promising for the long term solution, good, thanks for having 
peeked into the code :)

For BIC though this might need some overloads of the method, changing the 
signature of existing methods, even if only appending an argument to the list 
of arguments, does not work, or?
Given there are already 8 overloads for the different numeric types, well, 
that needs possibly more thinking still.

> The main problem with QLocale seems to be that it essentially is a black
> box - it has all the locale info we need, but we can't pull it out of it.
> So if functions to return the format string, precisions, etc for the
> current locale could be added, so that wrapper classes can be built, that'd
> probably be all we really need.

Yes, QLocale being readonly is a third issue in the list of blockers. And not 
only for the currency related methods. So our issues are:
- no currency string parsing method
- string formatting method toCurrencyString() does not allow
  to control precision
- no option to extend/overwrite/customize locale data

Cheers
Friedrich