From kde-core-devel Sun Jul 03 02:31:07 2011 From: =?UTF-8?Q?Nicol=C3=A1s_Alvarez?= Date: Sun, 03 Jul 2011 02:31:07 +0000 To: kde-core-devel Subject: Re: Intended organization of KDE Frameworks Message-Id: X-MARC-Message: https://marc.info/?l=kde-core-devel&m=130966031723829 On 6/26/11, Ingo Klöcker wrote: > On Tuesday 07 June 2011, Albert Astals Cid wrote: >> A Tuesday, June 07, 2011, Kevin Ottens va escriure: >> > On Tuesday 7 June 2011 01:26:17 Albert Astals Cid wrote: >> > > A Tuesday, June 07, 2011, Kevin Ottens va escriure: >> > > > Well, obviously a Tier 1 framework would have to use tr() >> > > > instead of i18n() for its translation needs. >> > > >> > > Are we still going to use .po or you plan on us moving to Qt >> > > translation files? >> > >> > Well, I honestly don't know what awesome magic you used for >> > libsolid, so for me it's "the same recipe". Note that it'll happen >> > mostly for Tier 1 frameworks though. >> >> Unfortunately that is not possible. Right now Solid is translated >> using .po but that only works in KDE applications because you have a >> KGlobal+KLocale around that loads .mo files (compiled .po), hijacks >> Qt calls and maps them to the .mo contents. Without a >> KGlobal+KLocale around that will not work. >> >> This means that if you want Tier 1 frameworks to be translatable you >> need either to teach Qt to understand gettext files natively or to >> make Tier 1 frameworks use pure based Qt/Linguist solutions which >> does not fit either in what scripty is able to do neither in what >> our translators are used to. > > AFAICS, Tier 1 frameworks don't provide any UI. IMHO they shouldn't > provide any user visible texts either. Just like UI this should be > outsourced to Tier 2 or 3 if necessary at all. Many classes that one may reasonably think that use no translations, like KPluginLoader, contain many user-visible strings. The class reports errors via an "errorString" that the host app may then display to the user. -- Nicolas