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

[Tino Wildenhain]

Hi again ;)

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

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

The management interface is much more HTML driven then it might look first.
Over a year ago I translated some parts of the ZMI for our departement and
found the next release of zope breaking all of my translated pages since
they contain code. Ok, with string replacement you can a bit drive around
that particular problem.

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

In my opinion not even that.

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

Unfortunately its not the case already. I'm speaking of the expression of
functional groups, with naming the gadgets, range of allowed values, etc.

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

Not only. Look at the code for DTML Method editing, where " Add ", "wider",
"shorter" etc. is used.

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

No, thats a design flaw ;) Did you ever see Amiga OS (3.x) localisation?
They used a similar approach like lookup in translation libraries, but
the program only uses constants as key rather then the expression in a
given language. This solves the problem of false matches and long keys.
The mechanism even provided a version for the "catalog" as they were called,
so if the application gets developed, an unmatching translation could
then be dropped.

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

Slow down? Why this? I'm praying for more then a year for 
internationalisation.
Now the effort begins to walk forward, would it not be better to do it
right at the beginning? Design (I mean software design) should go before
doing implementation. Otherwise we end up having a pile of problems to solve
later. I can not see the use of doing something intentionally wrong.

> 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 ...
>
The cat bites its tail here ;) What first looks simple will become 
complicated
at the end end vice versa.

Regards
Tino