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

[Joachim Werner]

O.k., let's go on with that ;-)

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

No, string replacement actually SOLVES the problem. I mean, you change the
code, but the translations still work ...
BTW: DTML IS code; I am always a bit surprised how much actual functionality
the DC people have put into DTML instead of Python; Zope is very much like
ZClass-based programming if you look into the ZMI ;-))

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

if it is logical markup, it should be possible ...

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

O.k., those are the things DC definitely HAS to change. You are right ...

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

With ZBabel, the actual internal key is a very efficient hash. Stephan
thought a lot about implementing that efficiently. And if you want to avoid
mismatches, use unique names. It's that simple. What we are planning to add
is domain-specific namespaces, so you can say things like "calender.Sun" and
"star.Sun". It would also be nice as you mentioned to have versions for the
language packages; I guess I dealt with that problem in the Wiki already ...

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

O.k., you should explain that in more detail. We don't want to do anything
wrong, but e.g. I do not see any problems with adding better content
negotiation later. ZBabel or Localizer just need a language variable set.
Whether it comes from content negotiation or some other piece of code
doesn't matter much.

I do however see a problem in having to wait for the perfect abstraction
layer in the ZMI to be built. I mean, as soon as ZBabel or Localizer have
been selected as the official way to go it might take a couple of weeks to
make the tool release quality and then a couple of days (maximum) to
internationalize the ZMI. Then we are done with that. With zzLocale we
proved that it is feasible. zzLocale just had the problem that it didn't use
string replacement but translated the full DTML pages including all the
code. With the new approach, all changes in the code would just have to make
sure that the label names are preserved, so when we talk about the risk of
"having to do it again and again" we only talk about a couple of days of
work. Waiting for the perfect architecture from DC can take many months or
years as experience shows!

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

I have a totally different opinion here: If we manage to do the simple thing
first (and do it quickly and with low risk because it is simple and easy),
it actually becomes EASIER to refactor everything as soon as we see that we
have to change everything again as we will have collected some additional
experience. It's what the Xtreme Programming people would call "refactor
mercilessly" I guess. And: in the meantime we will have a running system for
out clients ;-) And still another reason for going the easy way is that it
breaks much less existing code ...

Joachim