Ki18n mostly ready

[Martin Graesslin]

On Monday 05 August 2013 20:57:33 Chusslove Illich wrote:
> My notion of source compatibility was that it builds and works, not only
> that it builds :) Is there really a point of leaving in dummy methods just
> so that the build can proceed, even if they do nothing? As I mentioned, my
> intention was to commit everything necessary for the build to work, but I
> plainly screwed up.
Depends - I'm torn apart between the two possibilities. On the one hand don't 
failing the compile means we get really fast to an application which starts 
again. On the other hand I had one case where a method became noop and I 
didn't notice it because there were just too many warnings. A port with a 
compile failure would have been extremely trivial for me (granted not for 
every user of that specific API).

In the case of loading the language catalogs I think it's better to get fast 
to compiling. It's not the most essential feature from a developer perspective 
during a port. That gets relevant when we get close to release. And it is 
something which doesn't have to be done by the maintainers - I just love to 
have extremely easy tasks around. And telling people "just remove all 
insertCatalog calls" is super, super easy.
> 
> Also, as Martin mentioned in the other message, this particular API was
> already changed once, temporarily, to proceed with splitting kdelibs. Given
> those splitting changes in kdelibs, I don't think it's even possible to put
> back the real original calls (that would do nothing).
Yes in this case it doesn't help to add the KLocalizedString variant back. So 
if at all it needs to be the KLocale variant as that's the one in Qt4 source 
base.

Cheers
Martin