[PyKDE] Feedback Needed on Possible tr() Changes

[Phil Thompson]

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.

Phil