From kde-devel Sat Feb 14 13:34:51 2009 From: Parker Coates Date: Sat, 14 Feb 2009 13:34:51 +0000 To: kde-devel Subject: Re: KComponentData, KCmdLineArgs and i18n Message-Id: <85d347350902140534h6bfe85bj1721e7d5f119ffda () mail ! gmail ! com> X-MARC-Message: https://marc.info/?l=kde-devel&m=123461856707416 On Sat, Feb 14, 2009 at 03:03, Andreas Pakulat wrote: > On 13.02.09 22:25:06, Parker Coates wrote: >> On Fri, Feb 13, 2009 at 22:17, Parker Coates wrote: >> > Hello folks, >> > >> > I recently created a patch for KPat to add a new command line switch. >> > [1] The tricky thing is that in order to make the change i18n >> > friendly, I needed to use some translated strings to created the >> > "--help" text. (KLocalizedString wouldn't cut it in this case.) This >> > lead to trouble, because i18n() can only be called after the >> > KApplication has been created, but KCmdLineArgs must be set up before >> > the KApplication. It seemed I was stuck. >> > >> > After explaining my predicament on #kde-i18n, Chusslove suggested >> > creating a temporary KComponentData, after which I could use i18n(). >> > This resulted in a main.cpp laid our like this: >> >> Sorry, sent prematurely due to an accidental keyboard shortcut. Well, >> that's embarrassing. Continuing on... >> >> This resulted in a main.cpp laid our like this: >> >> - Create KAboutData >> - Create a temporary KComponentData >> - Do the slightly tricky translation stuff >> - Setup KCmdLineArgs >> - Create KApplication >> - Continue on normally >> >> This seems to work perfectly, but it seems a bit like black magic. Is >> there any harm in creating a KComponentData just to get to access i18n >> earlier? > > I don't think so, you can actually create any number of component > data's, as long as you don't set one as the main component it doesn't > really matter (except for translation stuff and kcm's). Okay, that's good to know. It still seems wasteful though, as creating a KComponent data doesn't seem to cheap as it involves parsing configuration files and looking for plugins. Ideally, I was hoping for a KApplication constructor that would accept an existing KComponentData, instead of creating its own and thought I had found one until I noticed is was protected for use by subclasses only. Of course this stuff is way over my head, so if at any point I'm talking foolishly, let me know. >> Is this going to blow up on me in some not yet seen >> situation? Is there a better and cleaner way to do this? > > I wonder though why you can't use ki18n() to translate the game-name or > why you're translating at all. Sorry, I guess the link to ReviewBoard [1] got lost at the bottom of the first, broken email. The short explanation is that I need to compile a list of translated game names to insert into the description of the new command line option. Of course, if anyone can see an alternate means of providing similar functionality, I'm all ears. Parker [1] http://reviewboard.kde.org/r/50/ >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<