[me, trying to figure out what's causing a traceback in Localizer]
So who's at fault here? Have I failed to initialize things properly,
ie. should LocDefaultDublinCoreImpl (which is the object at fault here,
I think) be doing something to ensure that either or both of
_default_language or _languages is set? Or is LocalPropertyManager
failing to account for the "brand-new object" case?
[Juan David Ibáñez Palomar replies]
Sorry for the delay.
Good question. Well, I have changed it in the branch-1-0,
now it will return None, I think this won't break anything
else, but I would appreciate if you test it.
Unfortunately, my priority right now is to Get Things Working, elegance
be damned. If I get a few minutes, I'll try to checkout the Localizer
code from CVS (that's what you're asking, right?) and give it a try, but
no promises.
Anyways, I kludged around the problem in the class that's closest to
Localizer but still under my control:
class LocDublinCoreImpl(LocalPropertyManager, DefaultDublinCoreImpl):
[...]
def __init__(self, ...):
[...]
self._languages = ("en", "fr",) # XXX should come from Localizer
self._default_language = "fr" # XXX this too
Needless to say: blecchhh! Presumably these values should come from the
Localizer instance in my Zope tree -- but they don't. Is there
something I have to do to ensure my LocalPropertyManager subclass gets
those values from the Localizer instance?