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. > 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. Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by BlueSystems and KDAB to work on KDE Frameworks
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
