Behalf Of Sven Schomaker
> Sent: Thursday, April 07, 2005 11:57 AM
> To: firstname.lastname@example.org
> Subject: [Zope3-dev] i18n feature question/proposal
> Hello all,
> I've recently been working on i18n of content fractions
> by means of extended fields that require the content
> component to provide a mapping to store locale dependent
> Currently I'm not quite certain about, whether this
> is a neat style for the issue of fractional content
> internationalization (internationalization just of
> parts of the content-object and not the whole one
> as content internationalization has been acchieved
> by several z2 products, AFAIK) to be solved. This
> is what I've got so far (it actually works great):
> 1 Fields need to be bound to the current locale,
> retrieved from the view/request. Whereas this
> makes it necessary to introduce some minor
> modifications to the form machinery, namely
> setUpDisplayWidgets, setUpEditWidgets, setUpWidget
> and probably _createWidget, to pass the locale to
> the field at the time it gets bound to the context,
> it does not require any modifications to the current
> widget set, since all locale specific logic will be
> realized by the fields.
> 2 This introduces several new field interfaces,
> (and its respective implementation) such as IText,
> ITextLine (and whatever is needed to store locale
> dependend content), that are derived from their
> non-internationalized counterparts. This would
> easily enable people to provide their content
> with internationalized text, etc. and also enable
> the z3 core to provide internationlized DC-titles
> and descriptions, for instance.
> Hmm, maybe there is already another way to get fractional
> content internationalization, that I missed? (Such as a
> pretty nifty z3 package I just overlooked)
> What is your opinion on this? Is there any interest on
> making such thing part of z3, or would it have to vegetate
> in a z3 branch hosted at my workplace, for the rest of its
> Sven Schomaker
Did you take a look at zope.app.i18nfile?
There is no need for different fields for supporting
i18n. I think adding i18n fields is a overhead.
We implemented allready i18n documents and local negotiator
in our projects.
Perhaps we move this after 3.1 to the trunk if somebody
likes to have a generic i18n support.
I propose to improve this part after the 3.1 release
and implement one sample solution where most the time
btw, we didn't improve the i18n part till now, because
there is no correct way where is THE solution.
Different usecses need different implementations.
But sure we can implement one concept in the core
but this should be a simply way with no overhead.
END OF MESSAGE
Zope3-dev mailing list