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

[Joachim Werner]

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

I think the separation of HTML display and the underlying Zope logic is very
important. But it might not be in the focus of the internationalization
project.
O.k., some of the very bad stuff (e.g. HTML hardcoded in Python, like the
authorization errors) should go, but a complete clean-up of the core can be
done later. If the internationalization problem gets too complicated, it
won't be solved soon.

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

That's a very good point indeed. I'd also like to see mechanisms that
trigger the necessary workflows in a content management system, e.g. if a
text is changed, the translators of the old version should get an e-mail
notification that requests them to add the changes to the translation.

BTW: This problem will not occur with the string-based translation (e.g.
ZBabel's babel tag). As soon as the original string is changed, the key will
not fit any more, and there will be no translation until somebody adds the
new translations. On the other hand, currently there is no automatic
detection of missing translations, so that a translator could see and add
them.

> 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 think both Localizer and ZBabel do a good job here already ...

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

What is so special about content negotiation? I mean, the accepted languages
string from the browser is in the REQUEST namespace. What else should Zope
do?

Cheers

Joachim