i18n in Frameworks, the lightweight version

[Dario Freddi]

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".
>>
>
> 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()?

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