[Zope-Checkins] CVS: Zope3/lib/python/Zope/I18n - I18nObject.stx:1.1

[Stephan Richter]

Update of /cvs-repository/Zope3/lib/python/Zope/I18n
In directory cvs.zope.org:/tmp/cvs-serv25811/Zope/I18n

Added Files:
	I18nObject.stx 
Log Message:
Some early docs.


=== Added File Zope3/lib/python/Zope/I18n/I18nObject.stx ===
I18n Objects

  I18n objects are used to interantionalize content that cannot be translated
  via messages. The problem is three fold:

    - Internationalize an object iteself. The best example an Image. Often
      people put text into an image that needs to be localized, but since it
      is a picture the text cannot be retrieved as a string. You therefore
      will need a mechanism create a different version of the object for every
      language. (Note: This behavior is the same as currently implemented in
      the ZBabelObject.) 

    - Internationalize fractions of the content. Let's say for example you
      wanted to internationalize the DublinCore information of your content
      object. In order for this to work out you need to have an
      I18n-supportive AttributeAnnotation. Solving this use case would be
      similar to some of the work David Juan did with
      InternationcalizedContent in Localizer.

    - Formatting Objects. This problem involves converting basic or complex
      types into a localized format. Good examples for this are decimal
      numbers and date/time objects. In this case you would like to specify a
      format via a templating expression and then pass the object to the
      formatter to apply the parsed template. Initial steps for implementing
      the template parser have been already taken, therefore we only need to
      develop some interfaces and unittests here, so the parser developer
      (which will use the ICU C/C++ libraries) will what parts of the parser
      to wrap for Python. 

   
  The first two problems are very similar and can actually share the same
  interface for the language negotiation and redirection of the content
  request. I would therefore propose to have a II18nContent interface that
  somehow specifies how to get the and then redirect the call to the correct
  local content.

   
  I18nObject

    There will be an interface called II18nObject (which inherits I18nContent
    of course), which is a cameleon-like container, as it adapts to the
    properties of the contained object type. In order to accomplish all this,
    you will have to implement your own traverser which looks up the correct
    subobject.


  I18nAttributeAnnotation

    This object will basically provide an internationalized version of
    Zope.App.OFS.AttributeAnnotations. which will be accomplished in a similar
    manner as the I18nObject.


  One issue left to solve is how to know the language when we need to make the
  decision. These objects are **not** Views, therefore they do not know about
  the request variable. 

  One way to solve the issue would be that I18nAttributeAnnotation, for
  example, would not actually implement the IAnnotations interface, but that
  there would be an Adapter converting the II18nAnnotations to
  IAnnotations. Since adapters are short-lived (meaning they are initialized
  for a particular call), we can safely store some language information in
  them in order to make the language decision.