[Zip] Initial Mail after ZIP revival at EuroZope Conference

[Juan David Ibáñez Palomar]

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

It seems too much magic to me, does it work now? which is the status
of ZBabelObject?


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

In the squishdot example posts would need a method like this:

  def content(self):
      s = []
      for p in ('title', 'summary', 'body'):
	  for lang in self.get_languages():
	      s.append(self.getLocalProperty(p, lang))

      return join(s)

and index posts by content as a text index.

Perhaps I'll add some facilities to LocalPropertyManager, not sure.


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

Agree, we need a Wiki, Stefane, are you there? :)


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

Because it really is just a different version of the same object. It is
much easier to implement if the different versions are stored together,
and the implementation will be faster. It will also eliminate the problem
of context (when similar strings have different translations depending
on the context).

A web application is different than applications like word processors or
spreadsheets. If you get a spreadsheet it's already internationalized and
localized, you don't have to do anything. But a web site has content, some
times multilingual content, that needs to be managed.

Message catalogs as provided for example by gettext are only a part of
the solution, very useful for Zope itself and Zope products, but no so
much for developing multilingual web sites. In a web site multilingual 
content should be stored together, and only few strings should be stored
in message catalogs.

Actually, I'd like to get rid of message catalogs in the ZODB and use
it only for Zope and Zope products (the file system) where they're
really useful. But I'm still not sure.

Garbage collection?


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

Well, it was not my intention, but the Localizer already solves or
helps to solve it, just put the specific logic in the localized folders.


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

Perhaps you're right, or not, I'm not sure because the langauges I use
always go from left to right and top to bottom. It would be nice to hear
opinions of people with more experience about these topics.

Anyway, what I'm meaning is that the problem is more complex than what
it seems at a first glance. Another example, how would you internationalize
and localize the Zope on-line help system? Message catalogs doesn't work
there, we need to address this issue in a different and specific way, just
another "tool" to the collection.


Regards,
jdavid


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