[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Need help with how translation files are handled
From:       Dag Andersen <danders () get2net ! dk>
Date:       2007-11-26 12:25:26
Message-ID: 200711261325.26759.danders () get2net ! dk
[Download RAW message or body]

Torsdag 22 november 2007 16:05 skrev David Faure:
> On Tuesday 20 November 2007, Dag Andersen wrote:
> > Hi,
> > seems I got into a mess when I put parts of kplato into separate
> > libraries. I didn't think about translation so now I have dug into how
> > this is handled and *think* I have found a way to handle it, but I would
> > like a comment on this from somebody who knows more, please.
> >
> > It seems to me that to keep things simple, one should have one
> > translation file pr app, and it should be named the same as the app.
> > If the translation for an app is split into several translation files as
> > we do for all koffice apps (as we have a separate translation file for
> > koffice libs), things starts to get complicated.
>
> Yes.
>
> > To fix this for koffice, KoApplication is introduced that can load the
> > koffice translation file.
> > However, when koffice apps are embedded into kparts apps
> > (like konqueror) KoApplication is not used, so a KoViewWrapperWidget is
> > introduced to do the job in singleviewmode.
>
> Yes, but well, all this is simply because those are the entry points into
> the komain library (you first create a KoApp or you use the document into a
> view wrapper; but we could have also just put the insertCatalog in the
> KoDocument constructor for the 2nd case).
>
> > I could possibly do the same: subclass KoApplication to add my new
> > tranlation files and do some magic in singleviewmode. (Hmmm, I would
> > probably need special treatment when I'm embedded in a koffice app also.)
>
> No no no please do not subclass KoApplication. This goes into a very
> unflexible road. All you need is to find the entry point(s) into the kplato
> code.
> For instance if one needs to create a KPlatoDocument first before doing
> anything else, then call insertCatalog in the KPlatoDocument constructor.
Ok, that's the way to go, I think.
>
> Note that the plugin magic takes care of loading the translation catalog
> too, so when embedding everything should work fine - if you have a single
> kplato.po of course.
>
> > However, it seems to me that when the KComponentData is created in
> > Factory::global(), I could add my tranlation files to KLocale as I think
> > that there is always a KGlobal::locale() at that point and it is the
> > correct one. Is this true, or am I just on walkabout?
>
> Shouldn't be necessary.
> * If all that code is compiled into a module (like most koffice apps are)
> then the catalog is inserted when loading the module (and removed when
> unloading it, which hacks like the above wouldn't do) * If your code is
> used as a real shared library by some plugin/app then you don't end up in
> Factory::global, right? In that case see above about finding the entry
> points -- and no unloading possible so no removeCatalog.
No, true, my thought process took a very short cut there.
>
> About that auto-loading of catalogs:
> kdelibs/kdecore/util/kpluginfactory.cpp:200:   
> KGlobal::locale()->insertCatalog(d->componentData.catalogName());
>
> Ah, you have to call KAboutData::setCatalogName or pass the catalogName to
> the KComponentData constructor, if the catalog name doesn't match the
> "appName" given to KAboutData.

Ok, thanks for straiting me out.

-- 
Mvh
Dag Andersen
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]