Ki18n mostly ready

[Martin Graesslin]

On Monday 05 August 2013 16:19:07 Sebastian Kügler wrote:
> Hi Chusslove,
> 
> On Friday, August 02, 2013 12:00:50 Chusslove Illich wrote:
> > > [: David Faure :]
> > > There's no way to keep the [insertCatalog] method for source
> > > compatibility
> > > and implement it somehow on top of the new solution?
> > 
> > The problem is that insertCatalog no longer has a meaning. Its purpose was
> > to add more translation catalogs into the current process, and all of them
> > would be searched for translation on a given i18n call. While in the new
> > system, all i18n calls are bound to a particular catalog (either through
> > TRANSLATION_DOMAIN define or setApplicationCatalog).
> > 
> > > I'm afraid of the porting effort created by all these source
> > > incompatible
> > > changes. If we can minimize that, it's all for the better.
> > 
> > For porting, my focus was on the case where for each library/application
> > there exists a different maintainer who will perform the update. In this
> > case, it is not much effort: throw out any insertCatalog methods, replace
> > with one TRANSLATION_DOMAIN define in private header (for libraries and
> > applications) or one setApplicationCatalog call (easier alternative for
> > applications).
> > 
> > Of course, in reality there is sometimes no maintainer, or an "incidental"
> > maintainer with piles of other things in the queue, and then porting
> > becomes some effort. I'll help :)
> 
> I'm not really happy about this patch, since it introduces build breakage.
> (kde-workspace[frameworks-scratch] at least doesn't build with these changes
> in.) This SIC change is also not mentioned in KDE5PORTING.html, making it a
> lot worse, since the canonical place to look up such things doesn't know
> about it.
As I was the one who fixed kde-workspace this morning I have to agree that it 
was quite painful. What I found really sad was that it affected code which had 
already been ported from KLocale::insertCatalog to 
KLocalizedString::insertCatalog. Breaking the build with one change is bad 
enough, breaking it twice is even worse.

I "fixed" the build by just removing all insertCatalog calls, but I have no 
idea whether that is correct or what would be the correct way. A warning with 
some instructions on how to fix it, would really help. And also move it from "I 
have to do this now!!!!" to "I can have the community do it, because it's an 
extremely easy task". Broken build unfortunately is blocking.

So please add the convenient methods back as deprecated just putting out a 
warning. Each API change is painful. All errors I had with porting KWin so far 
were in areas where I had to get it to compile again and I couldn't test 
whether my compile fix is correct - and I'm not talking about the XLib to XCB 
port here.

Cheers
Martin