Porting away from KLocale

[John Layt]

On 23 October 2013 12:56, Aleix Pol <aleixpol at kde.org> wrote:
> On Tue, Oct 22, 2013 at 2:03 PM, David Faure <faure at kde.org> wrote:
>>
>> On Thursday 17 October 2013 23:47:40 Aleix Pol wrote:
>> > Well maybe I could help with this, but I'd need to know what do you
>> > think
>> > it would be the most appropriate solution.
>>
>> I'd say, split it out into a separate function for KF5, and later on, if
>> you
>> feel like it, contribute it to Qt for 5.3.
>
> I created a task for it on the kdelibs cleanups [1] so anybody can pick it
> up.
>
> Aleix
>
> [1] http://community.kde.org/Frameworks/Epics/kdelibs_cleanups

OK, here's a high-level suggested plan:
* The obviously place to move it is k18n, as either part of
KLocalizedString or in a new KByteFormatter class?
* Move KLocale::BinarySizeUnits, KLocale::BinaryUnitDialect, and
KLocale::formatByteSize()
* Do we make it a pure static method?  Or require an instance to be created?
* If static-only then don't need setBinaryUnitDialect(), and
binaryUnitDialect() will become a static defaultBinaryUnitDialect()
* No locale file overrides the default BinaryUnitDialect, so we only
have to worry about reading any user override from kglobals
* Default to using QLocale() for number formatting, but need to be
able to set a different locale to use.  If static-only then just add
an extra parameter to override the locale, otherwise will need a
setLocale()
* Don't forget the tests :-)

The only other thing we may also want to keep from KLocale is
formatDuration() / prettyFormatDuration().  It's on my todo list for
Qt 5.3 and not used many places, but we may want to keep our version
for now.

Cheers!

John.