Ki18n mostly ready

[Sebastian Kügler]

Hi Chusslove,

On Monday, August 05, 2013 20:57:33 Chusslove Illich wrote:
> > [: 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).

Ow, I never assumed you broke it on purpose. I know that these things happen, 
my email was more about reminding people to also build plasma-framework, kde-
workspace, which also have KF5-based code. Sorry if I came over as blaming you 
personally, I know we all intend well, and doing a project the size of KF5 
makes it almost inevitable that we step on each others toes once in a while. 
The trick is to just move on, and discuss issues when necessary. (Which this 
thread is for.)

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

Yep, that would totally help, although I don't think the API should be removed 
just now.

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

But if it doesn't build, it won't build *and* it won't work. It blocks people 
who are working on something else. That's why I'd leave the calls in until 
there's a proper solution. Then, the API can be removed, and the correct 
solution applied everywhere where there's a build error. 
Having someone fix the build (by removing the insertCatalog call, for example) 
will hide this porting task once there's a proper solution, and I'm sure it 
will lead to a large amount of insertCatalog calls simply not being ported. 
Not good. That's why leaving the dummy API in is to be preferred.

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

Putting KLocalizedString::insertCatalog in is good enough, mark it DEPRECATED 
so we get warned that porting work is coming up.

Cheers,
-- 
sebas

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