Intended organization of KDE Frameworks

[Nicolás Alvarez]

On 6/26/11, Ingo Klöcker <kloecker at kde.org> 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