[Zip] Initial Mail after ZIP revival at EuroZope Conference

[Stephan Richter]

>Would posts contain ZBabelObjects which would store localized versions
>of title, summary and body?

Posts would be ZBabelObjects that represent the Meta-Type Message. The 
ZBabelObject then behaves exactly like the Message, just in the language 
you chose.

>Would posts inherit from ZBabelObject?

No, no, that is exactly what I try to avoid!

>How would you catalog posts?

Ok, now that is a good point!!! I think the ZBabelObject would need a smart 
way to tell the catalog about the multiple sources of content. But maybe it 
would be necessary to make an internationalization-aware catalog in anyway. 
That would be probably one of these objects we would have to work seriously 
on. Okay, that would be something we really would need to push for...
Does the LocalizedPropertyManager solve this problem?

I am thinking some more about that... Certainly a case I have not yet 
considered...

>I also would like to see a very simple set of tools that works for
>everything, unfortunately i18n is a very complex task, especially
>in a web environment.

Well, maybe we should really go back and collect Use Cases; not such 
abstract ones as we had at EuroZope Conference, but really simple ones we 
meet every day. What do you think?


> > Ah, I just remembered another solution (I think better) for the
> > multilingual messages on Squishdot problem. In fact, you should only
> > translate them and change its representation. All you need to provide is a
> > nice interface that says: Show me a translation screen with the fields and
> > content of this object (message). The more I think about it, you should 
> not
> > do translation anywhere else than your presentation.
> >
>
>I don't understand this paragraph.

Well, I want to say: If Message X is in English, why do I have to save its 
translation in the same Message object or somewhere near. The translation 
is really only interesting for display and as you pointed out for searches 
via a catalog. So all I need is to keep track which object uses a certain 
translation, so after a search we can point to it. We need this information 
in anyway for the garbage collection (another open task of mine).

> > Your logic should never change based on your browser settings. If you have
> > to deal with multilingual systems in your logic, then this has nothing to
> > do with your localization in the way we are talking about it anymore.
> >
>
>Don't understand.

Well, there are huge Logistic systems (for example) that do business in 
many countries. In this case taxes, for example, differ. In this case your 
entire application logic depends on the country and region, but I think 
that is not a problem we should try to solve, since such systems will 
implement that stuff by hand in anyway.

> > So my question still remains: Are there Use Cases where you would need
> > Localization/Internationalization anywhere else other than in your
> > presentation?
> >
>
>This is a very simplified and abstract view of the problem, i18n/l10n is
>not only about presentation, it's about content, presentation and logic.
>
>In the EZ conference we wrote a list of things that should be done in
>the i18n/l10n area, it was one full page and probably it only covered
>less than half of the problems.
>
>We still haven't talked about Unicode, indexing/searching or text
>direction for example.

Okay, Unicode support must be done in the core (agreed). Indexing and 
searching as I said above needs to be addressed, but text direction is 
again presentation. Whether my line runs forward or backward really does 
not matter. Maybe setting an alignment, which again could be viewed as a 
presentation problem (and can be easily resolved already).

Regards,
Stephan

--
Stephan Richter
CBU - Physics and Chemistry Student
Web2k - Web Design/Development & Technical Project Management