Ki18n mostly ready

[Albert Astals Cid]

El Dilluns, 5 d'agost de 2013, a les 07:18:29, Kevin Ottens va escriure:
> On Saturday 03 August 2013 16:29:27 Albert Astals Cid wrote:
> > 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?
> 
> Yes.

Sad :-/

> 
> > 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?
> 
> That's fine with me too.

Chusslove, you reading this? What's your opinion?

Cheers,
  Albert

> 
> Regards.