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. _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
