El dilluns, 10 d’octubre de 2016, a les 0:38:23 CEST, Friedrich W. H. Kossebau va escriure: > Am Sonntag, 9. Oktober 2016, 22:21:56 CEST schrieb Albert Astals Cid: > > El diumenge, 9 d’octubre de 2016, a les 18:05:29 CEST, Friedrich W. H. > > Kossebau va escriure: > > > Am Sonntag, 9. Oktober 2016, 17:44:02 CEST schrieb Albert Astals Cid: > > > > El diumenge, 9 d’octubre de 2016, a les 11:44:16 CEST, David > > > > > > > > Faure va escriure: > > > > > AFAIK KLocalizedString::setApplicationDomain isn't > > > > > > > > necessary, you should > > > > > > > > > instead define the domain as a -D flag during compilation, but > > > > > > > > I'm no expert > > > > > > > > > on that, check the wiki. > > > > > > > > Don't recomend the domain flag for anything that is not a > > > > library, it is a bad idea, several things in applications break if > > > > you do that. > > > > > > What breaks exactly? > > > > Anything using KLocalizedString::applicationDomain() > > > > https://lxr.kde.org/search?_filestring=&_string=KL.*%3AapplicationDoma > > The XMLGUI ones though only fallback to that if the rc file has no domain > tag set, so there one would be safe (unless missing the tag, but that is > also needed with libs). > > But kcheckaccelerators testing and KTipDialog seems to indeed rely on that > property, was not on my radar, thanks for the info. Guess I simply never > used them, so did not affect me.
You're also missing the "Translators" tab in the application about dialog if you don't set your application domain properly. Cheers, Albert
