On Friday, October 07, 2011, Tom Breton (Tehom) wrote: > Thanks for the advice. But Qt wants all "tr" calls anchored in some > Qt-derived class. There is no bare "tr" call. So having moved them into > new classes, any direction I go has an impact.
Qt says it wants, or your code refuses to compile with plain tr() calls? That's a level of subtlety I missed the first time through. If you've got to flat do something different just to get it to compile, and your class isn't really doing anything widgety, then that's a case when it's probably going to wind up having to use QObject::tr(). I wish I could offer a good explanation why that is, and I could be wrong, but I think that's what ends up happening in those cases in order to get the translations to work. You can end up in the situation where the tools pull your strings out into the .ts file, your translator offers translations for them, but they don't actually function at runtime due to context issues. Our catchall for those situations is the QObject translation context, which is farking gigantic, and won't mind a few new strings. I'm afraid I haven't really had to do much about this kind of thing in more than a year, so I have much more gut intuition than rational explanation at this point. Either way, just get the code to compile, and I'll work it out from there. -- D. Michael McIntyre ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Rosegarden-devel mailing list [email protected] - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
