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

[Tino Wildenhain]

Hi,

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

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

On the other hand, you might not get the power of the community twice,
if you do the quick and somewhat dirty way first, then clean up and
then again have them all do the work of translation again.

I think at least one point might be simplyfying the whole ZMI down to
its funtional core and then provide a translation layer on it. Next
layer can be design then.


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

This "the string is key for translation" has other problems, either the 
string
is quite large, so the performance might suffer or it is too short, so
matches are where they dont fit.

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

I'm afraid they dont.

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

You should have a look on Apaches mod_negotiation as well as rfc2616 (HTTP).
Content negotiation provides a general framework to determine the needs of
different user-agents and their users. This does include, but is not 
limited to
content-language and content-type. Imagine you have a site in two languages
and eiher in HTML and WML. Content-Negotiation would do the job in selecting
the appropriate variant for a given user. There are things like "wight" and
"size" of a resource to consider. This is not simply "grep the two letter
language code from request". It involves some math and determining correct
HTTP status and response headers to help downstream proxies and caches.

I've done some work on this matter and would provide it to the community.

Regards
Tino
>
> Cheers
>
> Joachim
>