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?
Cheers,
Albert
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
