i18n in Frameworks, the lightweight version

[Stephen Kelly]

Dario Freddi wrote:

> 2011/12/6 George Kiagiadakis <kiagiadakis.george at gmail.com>:
>> On Tue, Dec 6, 2011 at 10:54 AM, Aaron J. Seigo <aseigo at kde.org> wrote:
>>> On Monday, December 5, 2011 12:23:30 Chusslove Illich wrote:
>>>> Regarding yesterday's chat, to shortly (really!) sum up my stance on
>>>> i18n.
>>>>
>>>> 1) I see no point at striving for single translation system for apps
>>>> based on Qt and Qt plus KDE Frameworks. Qt should keep the
>>>> tr()/Linguist system, and Frameworks should continue to offer the
>>>> i18n()/PO system.
>>>>
>>>> 2) The application developer would choose which translation system to
>>>> use based on whatever criteria, like choosing between any other two
>>>> libraries covering the same need. We could put up an article describing
>>>> the relative advantages of the two systems.
>>>
>>> that is precisely the problem. nobody wants to choose between two
>>> translation systems. nobody wants to have to figure out what libraryFoo
>>> uses for translation (that one uses tr, this one use i18n, this other
>>> one also uses i18n, that one uses tr ..) and try to align their app with
>>> that.
>>>
>>> on the device side, i certainly do not want the overhead of two
>>> translation systems.
>>>
>>> there is simply no way to justify the current state of affairs, other
>>> than "it's how it's always been done, it's already implemented".

That may not be a bad reason at all. There's a porting cost to changing it 
as well as possibly a rescripting cost, probably a re-education cost (for 
both developers and translators) etc.

>>>
>>
>> I agree with Aaron here. I probably have missed previous discussions
>> on this topic, but seeing this email now I'm full of questions. Why
>> should we keep both systems? Considering that we go for your plan, who
>> is going to use i18n()? It will probably just die... From my point of
>> view they do the same job, so why should I depend on an extra library
>> when I can just use tr()?

It depends on your needs. If frameworks don't need the features provided by 
i18n(), maybe they don't need to depend on it. For applications, the 
situation might be different. Another thing to consider would be whether KDE 
applications and KF5 frameworks need to make the same choice between tr() 
and i18n(). If frameworks are closer to Qt (in terms of dependencies, target 
audience and contributor pool), maybe it's ok for them not to use i18n(). 
Then anything that really does need it uses it.

> 
> There is more: some of the tier1 libraries might even become Qt Addons
> at some stages and move to qt-project. 

Given that that would require all contributors to sign a CLA and adapt to Qt 
contribution rules, that is not very likely and even maybe not something to 
aim for.

Thanks,

Steve.

> In that case we would probably
> have to switch the translation system (buildsystem seems not to be a
> concern from last Contributors day). In general, one of the efforts of
> frameworks is getting closer to Qt, and I think i18n is still a major
> issue in this regard.
> 
>> _______________________________________________
>> Kde-frameworks-devel mailing list
>> Kde-frameworks-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel