Ki18n mostly ready

Chusslove Illich caslav.ilic at gmx.net
Mon Aug 5 18:57:33 UTC 2013


> [: Sebastian Kügler :]
> I'm not really happy about this patch, since it introduces build breakage.
> [...] 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 [...]

It was my intention to commit stuff such that there is no build breakage,
but in the moment it slipped my mind that there is stuff other than kdelibs
that needs updating. I'm really sorry about that. I've fixed
plasma-framework as soon as I saw the Jenkins report, and Martin was faster
for kde-workspace (and the fix is fine, to answer Martin in the other
message).

> This SIC change is also not mentioned in KDE5PORTING.html

I didn't put anything in KDE5PORTING.html right now, because essentially it
would be a pointer to a related section of new ki18n documentation. But I
could add something terse, like "to simply go on with the build, just remove
or comment out all insertCatalog calls; to actually make i18n work, read the
section blah, blah".

Which reminds me: can one put frameworks' Doxygen generated documentation
somewhere "official"? Can something automatically generate it? So that one
can actually link to it.

> 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?

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.

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).

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130805/18bdf8b1/attachment.sig>


More information about the Kde-frameworks-devel mailing list