Ki18n mostly ready

[Sebastian Kügler]

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.

KLocalizedString::insertCatalog removal: 

Can't this be made more source-compatible? If 
KLocalizedString::insertCatalog() doesn't make sense anymore, why not leave 
the method in for SIC, and propose to remove it in a non-blocking way, i.e. a 
warning?

-    KLocalizedString::setApplicationCatalog("kio_help4");
+    KLocalizedString::setApplicationDomain("kio_help4");

Is it really necessary to change the API here, could we maybe have convenience 
API? David is completely right that all these "small" porting things are 
adding up, so let's try a bit harder to maintain SC and make everybody's life 
easier. Add warnings, not compile-breakage, then fix those warnings. Don't 
break others code.

Also, a reminder: Please build plasma-framework[master] and kde-
workspace[frameworks-scratch] if you do changes, to make sure that no one else 
has to sift through mailinglist threads just to find out what changes have 
happened. (Unfortunately, that's what I usually spend half of my monday with, 
nowadays.)

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9