Ki18n mostly ready

[Albert Astals Cid]

El Divendres, 2 d'agost de 2013, a les 20:49:02, Kevin Ottens va escriure:
> On Friday 02 August 2013 19:15:50 Albert Astals Cid wrote:
> > El Divendres, 2 d'agost de 2013, a les 07:55:52, Kevin Ottens va escriure:
> > > 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?
> 
> Apps which use both ki18n and kconfig shouldn't use the default but ask for
> i18n explicitely. It's really just about changing the default behavior to be
> ready for third parties who just pick one, but we still need to be able to
> override that for our own needs of course.

Are you suggesting we cater for the unknown number of people that may decide 
to use KConfig without ki18n while forcing the hundreds of KDE-software that 
uses KConfig+ki18n to use a non default option with the danger they'll forget 
and we'll end up with un-translatable stuff?

If I can't convice you so that we write software that primarily works for 
ourselves can I at least convince you to make so that kconfig_compiler forces 
you to pass a command line parameter saying which i18n model you follow and 
fails otherwise so people have to conciously decide if they are writing a tr() 
or a ki18n() based software?

Cheers,
  Albert

> 
> Regards.