[Zip] Initial Mail after ZIP revival at EuroZope Conference

[Juan David Ibáñez Palomar]

> 
> 
> >Say, for example, that we want to make squishdot multilingual. If we only
> >want to localize the interfaces gettext is enough. But if we also want to
> >provide multilingual posts the best solution would be to make posts inherit
> >from LocalPropertyManager, with title, summary and body being multilingual
> >properties. Then a user could post a message in, for example, french, and
> >another user could translate it to english, spanish, etc.., making weblogs
> >for multilingual communities a reality.
> 
> Well, for something like this we use ZBabel Objects, which are some sort of 
> localized containers. Currently their are still only supporting the basic 
> objects, but I did that, so I knew about the icons. With a little though 
> they can accept any object type. This way you keep the content together, 
> but separated and since the usage of the Localized Object versus the real 
> original object will be transparent, one does not need to think in a 
> different way.

How exactly would you do it?

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

Would posts inherit from ZBabelObject?

How would you catalog posts?


> All what I am saying is that the localization really does and should not 
> require more than a couple of tools. Right now it seems that the Localizer 
> grows and has many different things doing similar work.
> 

For some definition of "similar", I prefer to say that these features
complement each other.

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.


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


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


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


Regards,
jdavid


> FOR ALL OTHER READERS: PLEASE COMMENT ON THESE MAILS TOO, SINCE THEIR 
> RESULT WILL INFLUENCE THE DEVELOPMENT OF THE JOINT INTERNATIONALIZATION 
> TOOL GREATLY!!!
> 
> Regards,
> Stephan
> 
> --
> Stephan Richter
> CBU - Physics and Chemistry Student
> Web2k - Web Design/Development & Technical Project Management
>