Ki18n mostly ready
Albert Astals Cid
aacid at kde.org
Fri Aug 2 17:15:50 UTC 2013
El Divendres, 2 d'agost de 2013, a les 07:55:52, Kevin Ottens va escriure:
> On Thursday 01 August 2013 22:03:36 Albert Astals Cid wrote:
> > El Dijous, 1 d'agost de 2013, a les 12:54:07, Kevin Ottens va escriure:
> > > Hello,
> > >
> > > On Thursday 01 August 2013 11:58:44 Chusslove Illich wrote:
> > > > > [: Kevin Ottens :]
> > > > > What's needed for kconfig_compiler? Because currently kconfig isn't
> > > > > supposed to depend on ki18n at all.
> > > >
> > > > It does generate translation calls as necessary, and currently it
> > > > accepts
> > > > an option (from .kcfgc file) whether to generate tr or i18n calls. So
> > > > another option to specify the translation domain would be added.
> > >
> > > OK, sounds good. We should make tr the default if that's not already the
> > > case though.
> >
> > Disagree. ki18n is our i18n framework. If something else that depends on
> > kconfig_compiler wants to use the poor man's solution, it's up to them,
> > but
> > i don't see why we should force it by default to everyone.
>
> Well, the default has to make sense to someone who just makes a Qt
> application and use KConfig as an extra. If kconfig_compiler generates by
> default something which doesn't build for them we're doing something wrong.
But as far as I remember we agreed we won't do the tr()->gettext(.mo) bridge
either (since tr() code will just use .qm and i18n() code will just use .po)
so if you default to tr() you break all the i18n() apps, no?
Cheers,
Albert
>
> Regards.
More information about the Kde-frameworks-devel
mailing list