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

[Tino Wildenhain]

Hi,

--On Samstag, 21. Juli 2001 08:53 +0200 Joachim Werner <joe@iuveno-net.de> 
wrote:

> 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.

Will do :-)

> 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.

Part of them. If its application centric, I would agree. But there are
many design centric sites out there. I think localisation of them
needs a slightly different approach.

> 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.

I agree here fully. May be there is a remark to this matter from me already
somewhere in the zope-list.

> 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.

Sounds logical at firtst. But I would mind of some things to consider:

1.) management tasks are mostly simple provide value - give value, choice
    value - tasks. No matter how they are currently wrapped and hard-codet
    in html (dtml) they need to be simplified and organized at first.
    If the application (ZMI) can express its wishes to the user, it can then
    be rendered for her in HTML or WML, XML or even provided to a different
    interface (may be a GUI using wxWindows or such) which is not possible
    with almost meaningless HTML pages. The translation code of zope should
    only generate default HTML interfaces, which can then be translated and
    extended by the way of deriving them.

2.) There might be a developement of the content in the original language.
    This causes a mismatch to already translated versions. We need a 
mechanism
    to watch versions to be able to defer the translated version until it
    matches the developed original.

3.) According to the needs of the community, we should have different ways
    to select the given language (not even speaking of the more general
    variant). In my opinion the first thing should be language negatioation,
    because it provides a stable way of selecting and expression to all 
current
    useragents and downstream proxies. Next can be selecting by cookie or
    request parameter. This should be kind of plugin and not hardcoded.
    The provider for the given language-variant can then be any given 
product
    on this matter, either zbabel, zzlocale or whatever.




> 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 ...

Not localisation but all the neccesary helper extensions should be in the
core. This includes support for zcatalog, content-negotiation and much more.

Regards
Tino