[kde-community] Cervisia?

Albert Astals Cid aacid at kde.org
Mon Jun 6 00:53:04 BST 2016


El diumenge, 5 de juny de 2016, a les 21:39:57 CEST, Martin Koller va 
escriure:
> On Sunday 05 June 2016 19:49:08 Friedrich W. H. Kossebau wrote:
> > Am Sonntag, 5. Juni 2016, 14:22:45 CEST schrieb Nicolás Alvarez:
> > > > El 5 jun 2016, a las 09:08, Martin Koller <kollix at aon.at> escribió:
> > > >> On Sunday 05 June 2016 09:14:42 Burkhard Lück wrote:
> > > >> 
> > > >> Some i18n issues:
> > > >> 
> > > >> It is a QApplication so you have to add the translators tab manually
> > > >> with
> > > >> aboutData.setTranslator
> > > > 
> > > > ok. what shall I write there (names, emails ?)
> > > > 
> > > > Isn't that a limited approach to name the translators in the
> > > > sourcecode,
> > > > since every new translation added will need a source change ?
> > > 
> > > No; you use something like i18n("TRANSLATOR NAME") (I don't remember the
> > > exact string), so that the name comes from the translation itself.
> > 
> > It would be
> > setTranslator(i18nc("NAME OF TRANSLATORS", "Your names"),
> > 
> >               i18nc("EMAIL OF TRANSLATORS", "Your emails"));
> > 
> > And it needs to be these very strings, as they are here, both comment and
> > content, because for those by definition there will be in the catalog
> > translation strings which then contain the names of the people who did the
> > translations for the given language. Which means, the i18nc call will then
> > return the names (and emails) of the translators for the current language,
> > as stored in the currently used translation catalog. (So not the names of
> > all the translators who translated to any languages, just for the
> > current). And there will be always such strings with their translation in
> > the translation catalog, they do not need to be present in the actual
> > code which makes uses of them, and thus do not need to be present in the
> > catalog template (pot file).
> > 
> > And as Albert already said in his email, it might not need to be done when
> > using KMainWindow (or derived classes like KXmlGuiWindow), as by tradition
> > the KMainWindow constructor ensures those strings are set on the global
> > KAboutData::applicationData object.
> 
> Thanks for clarification.
> 
> So cervisia is not using KMainWindow and also not KXmlGuiWindow.
> It uses KParts::MainWindow.
> Is that ok ?

It is a KXmlGuiWindow, so yes.

Cheers,
  Albert



More information about the kde-community mailing list