On Saturday 20 July 2013 00:23:30 Albert Astals Cid wrote:
> El Divendres, 19 de juliol de 2013, a les 16:27:39, Chusslove Illich va
>
> escriure:
> > > [: David Faure :]
> > > I.e. the question is whether the search path should apply to all
> > > catalogs
> > > in the current process (loaded after the call), or should apply to an
> > > individual catalog. In your example code above, I presume the latter
> > > would
> > > be better.
> >
> > If the search path would apply to all catalogs in the current process, the
> > application would then mangle the search path of underlying libraries,
> > which should not happen (library's i18n should work as built no matter
> > what a client application does). So this would not be a good solution.
> >
> > Then, since insertCatalog is going away (in favor of static catalog
> >
> > resolution), the best solution should be a combination of the two, say:
> > static void setDomainLocaleDir (const char *domain, const QString
> >
> > &searchPath);
> >
> > (where "domain" is the new-old terminology for "catalog name"). This is in
> > fact exactly what one does with raw Gettext (bindtextdomain function). I
> > put single locale directory as argument, as I'm not sure why it should be
> > multiple paths.
> >
> > Another thing is that in raw Gettext-using code, bindtextdomain is
> > normally
> > used simply to point to ${dataprefix}/locale, as there is no other
> > mechanism for that. But this is automatic with current ki18n, so I wonder
> > where is this code that needs special translations directory (i.e. why it
> > needs it)?
> >
> > As for porting, I'd rather that the problematic code is right now just
> > commented out, until I commit the overhauled ki18n. After that I will go
> > over and resolve all insertCatalog contexts, including this particular
> > bit.
>
> Chusslove, now that we're discussing this, the current kde4 code allows .mo
> files to be under ~/.kde/ (thanks to the multiple possible paths of
> kstandarddirs) while the new one only finds them on
> QStandardPaths::GenericDataLocation, I know some teams (and even lokalize i
> think) use this feature of installing in ~/.kde/ so that you don't need to
> have root to "install" the translation.
>
> Are we fine with losing that feature?
Wrong. QStandardPaths also allows "multiple possible paths" (just no setters),
and by default QStandardPaths::GenericDataLocation includes ~/.local/share.
So the feature is still there, just with a more standard local path.
--
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
