Re: KLocale plans (Re: KF5 Unit test results)
> [: Chusslove Illich :] > While splitting out public methods dealing with translation from KLocale > [...] For completeness, also the overview of what I do with other methods (no comment needed except for objections :): All translateRaw*() methods are removed. They were used only by KLocalizedString anyway. setMainCatalog() and setActiveCatalog() are removed. The former is practically either a no-op or equivalent to insertCatalog(), and the latter was used only in about data. insertCatalog() and removeCatalog() go to KLocalizedString. E.g. KLocale::global()->insertCatalog() becomes KLocalizedString::insertCatalog() . This is temporary, later I will remove these two methods too, in favor of Gettext-like catalog resolution (static resolution for i18n calls in libraries, dynamic resolution only using single catalog in applications). So there will be something like KLocalizedString::setApplicationCatalog() equiv. to Gettext textdomain(). copyCatalogsTo() is removed, it was needed only due to entanglement between KLocale, KCatalog and KLocalizedString. removeAcceleratorMarker() goes to KLocalizedString. toString() methods of KLocalizedString currently need a *KLocale argument. This would remain using KLocale inheritor, but in the meantime I will comment them out, and introduce methods taking QStringList &languages instead. This is needed for disentangling, but also makes sense on its own, so they would not be only temporary. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KLocale plans (Re: KF5 Unit test results)
While splitting out public methods dealing with translation from KLocale, I got a doubt about localizedFilePath(). For a given file path, it returns the localized file path, if available, according to the same language list and fallback rules as for strings in PO files. Due to this, initially I thought moving it to ki18n. However, this function was also used internally in KStandardDirs, so that in a usual KDE program, any file resource could be localized without doing anything in the code. Now I see that QStandardDirs is replacing KStandardDirs. It may not seem that this automatic localizability of file resources is that much needed, since it is rarely needed, and translator could ask programmer to wrap whatever path returned by QStandardDirs with localizedFilePath(). Unfortunatelly, sometimes the programmer also does not handle the path directly (e.g. icons). Any idea here? In a perfect world, the text translation library would come earlier in the hierarchy, and QStandardDirs would use it internally, just as it was with KStandardDirs. Adding this functionality to Qt would make sense, but we will then have a mismatch in the language resolution and fallback rules, which are quite specific with Gettext. On the other hand, we will have this mismatch for text anyway... -- Chusslove Illich (Часлав Илић) ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KLocale plans (Re: KF5 Unit test results)
> [: David Faure :] > Hi Chusslove, > > any progress? :-) No progress, but I'm going to do it right now. -- Chusslove Illich (Часлав Илић) signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KLocale plans (Re: KF5 Unit test results)
On Sunday 16 September 2012 19:22:26 Chusslove Illich wrote: > > [: David Faure :] > > Anyhow, I recommend splitting "in place" (in kdecore), first, to have > > commits that do the splitting, separated from the commits that do the > > moving. I can even do the moving once you've done the API splitting :-) > > Well that's totally great. I was thinking of asking about doing it this way > exactly, but thought it would be disrespective of your time :) Hi Chusslove, any progress? :-) I solved the kservice issue temporarily (with a few big nasty ifdefs), but I'm very soon going to hit the same issue with KIO, which I'd like to split out, because KIO has a strong dependency on i18n -- I'm not porting that to tr(), there's a lot of plural forms in kio/global.cpp for instance. I think the plan was "tr() for frameworks with very few and simple translations, i18n for heavy i18n usage", and KIO fits into the second category, it seems. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KLocale plans (Re: KF5 Unit test results)
> [: David Faure :] > Anyhow, I recommend splitting "in place" (in kdecore), first, to have > commits that do the splitting, separated from the commits that do the > moving. I can even do the moving once you've done the API splitting :-) Well that's totally great. I was thinking of asking about doing it this way exactly, but thought it would be disrespective of your time :) -- Chusslove Illich (Часлав Илић) signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KLocale plans (Re: KF5 Unit test results)
On Saturday 15 September 2012 13:36:42 Chusslove Illich wrote: > > [: David Faure :] > > So either i18n is ported away from KLocale, or all that calendar stuff has > > to move into the ki18n framework, at least in the short term. > > Since including calendar stuff into ki18n would be a temporary measure that > would later have to be undone, I think it's best that I split out ki18n and > remove KLocale dependencies from it as soon as possible. Yes. > The proper location would be staging/ki18n, right? Yes. Make sure to follow the standard directory structure under that dir (src, autotests, tests), see http://community.kde.org/Frameworks/Policies#Framework_directory_structure Anyhow, I recommend splitting "in place" (in kdecore), first, to have commits that do the splitting, separated from the commits that do the moving. I can even do the moving once you've done the API splitting :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KLocale plans (Re: KF5 Unit test results)
> [: David Faure :] > So either i18n is ported away from KLocale, or all that calendar stuff has > to move into the ki18n framework, at least in the short term. Since including calendar stuff into ki18n would be a temporary measure that would later have to be undone, I think it's best that I split out ki18n and remove KLocale dependencies from it as soon as possible. The proper location would be staging/ki18n, right? -- Chusslove Illich (Часлав Илић) ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KLocale plans (Re: KF5 Unit test results)
On Tuesday 11 September 2012 13:15:37 Chusslove Illich wrote: > > [: David Faure :] > > Is it also part of your plans to remove i18n()'s dependency on KLocale? > > I consider it rather an orthogonal matter. I will anyway remove all Gettext- > related stuff from KLocale, before doing anything about replacing > *gettext() calls themselves. > > > This is what's blocking me now, for extracting a ki18n framework (which I > > then need for the kservice+plugins framework). > > > > I think I'll let you move ahead on this topic and I'll find another area > > to work on meanwhile, there are plenty :-) > > On the other hand, not to stall unnecessarily, maybe it would be better if I > "real soon" factored out i18n as it is into staging/ki18n (possibly > temporarily breaking some internal details, which is no big issue)? And > only then go into what I mentioned before, proposing updated > klocalizedstring.h with new doc, etc. This shouldn't lead to any wasted > work, only slightly changed order of doing it. The reason I'm asking about KLocale, is that it currently depends on KCalendarSystem, KDateTime and KDayPeriod, all of which are not related to ki18n. (and that's basically all of kdecore/date except for the timezone stuff). So either i18n is ported away from KLocale, or all that calendar stuff has to move into the ki18n framework, at least in the short term. Apparently the calendar stuff itself has no additional dependencies (apart from a few kdefakes.h that Nicolas is currently fixing and a KToolInvocation that I'll fix), so the second solution is workable technically. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KLocale plans (Re: KF5 Unit test results)
> [: David Faure :] > Is it also part of your plans to remove i18n()'s dependency on KLocale? I consider it rather an orthogonal matter. I will anyway remove all Gettext- related stuff from KLocale, before doing anything about replacing *gettext() calls themselves. > This is what's blocking me now, for extracting a ki18n framework (which I > then need for the kservice+plugins framework). > > I think I'll let you move ahead on this topic and I'll find another area > to work on meanwhile, there are plenty :-) On the other hand, not to stall unnecessarily, maybe it would be better if I "real soon" factored out i18n as it is into staging/ki18n (possibly temporarily breaking some internal details, which is no big issue)? And only then go into what I mentioned before, proposing updated klocalizedstring.h with new doc, etc. This shouldn't lead to any wasted work, only slightly changed order of doing it. -- Chusslove Illich (Часлав Илић) ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KLocale plans (Re: KF5 Unit test results)
On Wednesday 05 September 2012 10:48:54 Chusslove Illich wrote: > Next I plan to rewrite > klocalizedstring.h, such that it reflects the planned changes, but most > importantly to have more comprehensive doc appropriate for a standalone > component. After we review it, I go adapting the code. Waterfall supreme. Is it also part of your plans to remove i18n()'s dependency on KLocale? This is what's blocking me now, for extracting a ki18n framework (which I then need for the kservice+plugins framework). I think I'll let you move ahead on this topic and I'll find another area to work on meanwhile, there are plenty :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
