i18n in Frameworks, the lightweight version

[George Kiagiadakis]

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