KStandardDirs and locale path
Chusslove Illich
caslav.ilic at gmx.net
Fri Jul 19 14:27:39 UTC 2013
> [: 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.
More information about the Kde-frameworks-devel
mailing list