atom feed24 messages in org.kde.kde-core-develRe: Intended organization of KDE Fram...
FromSent OnAttachments
Kevin OttensJun 6, 2011 3:04 pm 
Albert Astals CidJun 6, 2011 3:17 pm 
Kevin OttensJun 6, 2011 4:14 pm 
Albert Astals CidJun 6, 2011 4:26 pm 
Kevin OttensJun 6, 2011 4:38 pm 
Inge WallinJun 6, 2011 11:39 pm 
Albert Astals CidJun 7, 2011 12:46 am 
Aaron J. SeigoJun 7, 2011 1:21 am 
Manuel "Sput" NickschasJun 7, 2011 2:51 am 
Andreas PakulatJun 7, 2011 3:39 am 
John LaytJun 7, 2011 3:41 am 
John LaytJun 7, 2011 4:20 am 
Albert Astals CidJun 7, 2011 10:57 am 
MarkJun 8, 2011 11:48 am 
John LaytJun 8, 2011 12:27 pm 
John LaytJun 8, 2011 12:27 pm 
Albert Astals CidJun 8, 2011 1:29 pm 
Ingo KlöckerJun 26, 2011 12:45 pm 
Albert Astals CidJun 26, 2011 1:12 pm 
Ingo KlöckerJun 27, 2011 1:18 pm 
Aaron J. SeigoJun 28, 2011 9:27 am 
John LaytJun 28, 2011 2:57 pm 
Nicolás AlvarezJul 2, 2011 7:31 pm 
David JarvieJul 5, 2011 4:18 am 
Subject:Re: Intended organization of KDE Frameworks
From:Ingo Klöcker (kloe@kde.org)
Date:Jun 27, 2011 1:18:08 pm
List:org.kde.kde-core-devel

On Sunday 26 June 2011, Albert Astals Cid wrote:

A Sunday, June 26, 2011, Ingo Klöcker va escriure:

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.

Localization is not only about user visible texts, It is also about kconfig having per language keys, it is about kstandarddirs::locate being able to find localized icons, etc.

I hear you, but by the definition of Tier 1 none of this can be used in Tier 1 frameworks because "Tier 1 frameworks depend only on Qt itself and no other Qt based framework".

Of course, this means that Tier 1 frameworks will be very low-level and not offer some of the features we are used to in KDE libraries. But that's exactly the point of Tier 1.

Regards, Ingo