[Zip] Comments on whether to use the Wiki or the List

[Joachim Werner]

Hi!

I've just read the last couple of postings, mainly the discussion between
Stephan and JDavid. The discussion becomes very "sequential" on the list.
Now that the Wiki is up, I think we should start moving most of the ideas
you discussed here to the Wiki. I already tried to make a start and define
some goals etc. This was done BEFORE reading all the news, so feel free to
add stuff.

I'll quickly (and rather lengthily) comment on some of the theses you
discussed (and I promise to wrap that stuff up on the Wiki later):

David, I think that in Zope there is actually NO difference between the ZMI
and a Zope application. And there isn't even too much difference between a
Zope application and content objects in Zope. But sometimes even the people
at DC don't seem to be too aware of this.

All the management screens are pure DTML. And as Stephan mentioned, it
doesn't make too much sense to have them in the filesystem. They could also
be distributed using a pre-loaded data.fs. I agree that there are issues
like being able to edit stuff using a text editor or using CVS, but they
apply to over-the-web objects like ZClasses or PythonScripts, too. My
personal opinion is that in the long run Zope should give up the random
separation between filesystem-based and web-based products/content. It just
doesn't make any sense.

Concerning the i18n of  the ZMI with ZBabel: If I got all the technical
details right, one could start right now and convert all Zope management
screens to ZBabel. One just would have to replace all hard-coded strings by
ZBabel fish or babel tags. Currently this would break compatibility with a
plain Zope install of course. But as soon as one has ZBabel installed
(without even having a bable tower installed, right? -- question for
Stephan) you can use the system again. If there is no Babel tower or it
doesn't have a translation handy, you'll just see the label instead, which
is the English text version in most cases.

I don't see a problem with the translation packages for the ZMI lying in the
ZODB. Of course there needs to be a mechanism for importing/exporting stuff
to and from the Babel tower. But that mechanism exists.What is missing right
now is something like labeled sub-sets of the Babel database that can be
imported/exported separately. Stephan pointed that out already. It should be
possible to import a new Language Package for the ZMI but keep the old one
for the custom application I am running.

I think you already have kind of agreed on the fact that message
catalogs/Babel towers are not for everything. They are very handy for short
strings like button labels, but longer texts should be kept with their
original versions. I think that the ZBabel objects do this quite well
already. And the good thing is that you don't need to have localized
versions of PropertySheets and DTML documents. Those are very hard to
maintain because whenever their "parents" are updated by DC they have to be
re-released, too (at least if inheritance doesn't do the job for you).

The ZBabel object concept also works for help documents and the like. They
would just have to be in the ZODB (and that's what I am proposing anyway).

BTW: ZBabel is not a "new religion" Zope component yet. But it works as
something like a service. It does not modify the original documents (apart
from the fact that you need tags to mark what should be translated).
Concerning the tag mark-up: I'd personally like to see a tag syntax that is
compatible with a non-internationalized Zope. But that seems to be almost
impossible. It seems there is no alternative to putting compatibility with
Localizer gettext or ZBabel fish/babel tags into the standard Zope
distribution.

Stephan, could you maybe explain in some detail how ZBabel can be used in
Zope Page Templates or from Python code? I am not quite sure about the
syntax to use, but it should be possible, right? ...

About cataloging internationalized content: With ZBabel objects, every
catalog-aware content object is cataloged automatically, regardless whether
it is the English, German, or Spanish version. So cataloging itself works
fine already. The other problem is getting stuff back from the catalog. But
this seems to be a mere front-end problem. E.g., if you search for "Welt" or
"mundo" or "mondo", do you really want to get results for "World", even if
you don't speak English? If yes, shouldn't that be handled by the search
engine? I'm not sure about that one yet.

Regarding the question whether DC has to be part of this project or not: I
think their only two obligations are fixing the Zope core so that it is
internationalizable (which seems to have been done to some extent already,
like Unicode support or cleaning up some of the very bad parts in the ZMI)
and providing CVS access. All the rest can be accomplished by a EuroZope
team.

"Should i18n be in the core?". No, I think it should be a Product (or
Component) that can be switched on and off. After all, on-the-fly
translation comes at a price. Where it is not necessary, it should be
optional. There is only one problem with that: If on-the-fly translation of
the management interface is optional, is there a way of providing
pre-translated versions for the different languages (That's what zzLocale
did)? Maybe we'll have to check whether this is really necessary. After all,
caching could handle most of the speed issues ...

Cheers

Joachim