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

[Joachim Werner]

Hi!

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

Why that? Translations match to labels, so they don't have to be
retranslated when the layout of the management screen changes. Only if you
need new strings (i.e. new texts) you have to retranslate ...

Of course it would be good to make sure that translation strings do not
contain HTML tags (apart from maybe <strong></strong> etc.)

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

Isn't that the case already? In most cases at least? I mean, you can use the
API to add a user (and also do that via XML-RPC etc.) or you can use the
ZMI. Everything in the ZMI is just DTML (i.e. mostly HTML), and it would
have to look rather different for other management interfaces. How should
another abstraction layer look like? If you need another management
interface (e.g. for WML or wxPython) why not just call the API functions?

There are some (not so rare) cases like the "Add" menu in the ZMI where the
back-end methods are rather HTML-form-specific. But those parts are not
really relevant for internationalization as far as I can see ...

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

O.k., but that's life. ;-)

> > I think both Localizer and ZBabel do a good job here already ...

> I'm afraid they dont.

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

Good idea ;-)

That's some very important stuff for the future. It could be part of the
Zope component architecture (ZServer doing the content negotiation and
relaying to the appropriate server component). But again I think it would
slow down the i18n efforts considerably if we wanted to do all that right
now.

The pragmatic way of handling the content issue is still writing HTML that
works on most browsers, not using too much Javascript, and in our case maybe
using the language settings to provide language-specific content.

I have yet to see a framework, be it with Zope or with any other system,
that really manages to serve client-optimized code to different clients and
keeps that simple. I mean if I have to maintain 15 versions of my site
layout and rendering methods, I'll say "Thank you very much!" and keep my
simple approach ...

Cheers

Joachim