[PyKDE] Feedback Needed on Possible tr() Changes

[Jan L. Nauta]

> On Monday 26 May 2003 2:55 pm, Jan L. Nauta wrote:
> > > This still doesn't reproduce the C++ behaviour. If somebody
> ships a class
> > > library, implemented in Python and including translation files,
> > > then there is the possibility that an application translation will be
> > > used instead of the
> > > intended class library one.
> >
> > Well, it _almost_ reproduces the C++ behaviour. But also doesn't require
> > any changes to existing (generated) Python code. And it even has the
> > benefit that you can 'override' translations, which depending on your
> > viewpoint can also be a disadvantage.
> >
> > I also don't agree with your counter example. If somebody ships
> translation
> > files they will be searched _before_ the application translation. The
> > application translation is only used as a fall-back. In more complicated
> > situations, you could use a list of translators. This allows
> you to control
> > the sequence used to search the translators.
>
> # Assume translations exist for LibClass context.
> class LibClass(QObject):
> 	def hello(self):
> 		return self.tr("Hello")
>
> # Assume translation don't exist for AppClass context.
> class AppClass(LibClass):
> 	def welcome(self):
> 		return self.tr("Hello")
>
> a = AppClass
> a.hello()
> a.welcome()
>
> With the current implementation a.hello() will wrongly fail to be
> translated.
> With your scheme a.welcome() will be wrongly translated (using
> the LibClass
> context). I think.

You're correct ofcourse, that is what I called the 'override' translations.
Although it's not the C++ way, I think it shouldn't be a problem in
practice. If it happens you could always use
qApp.translate("AppClass_Workaround", "Hello") as a workaround, in your own
class. But normally, and I know it's just my perception, the translations
should match. Because although the contexts don't match they are in the same
hierarchy path, and therefor are related. So I think the method I proposed
works better than the existing one, and doesn't require many changes to
Sip/PyQt/PYUIC or existing code.

Regards, jln.