/usr/lib/python2.7/dist-packages/zope/i18n/i18nobject.txt is in python-zope.i18n 4.1.0-1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 | ============
I18n Objects
============
The Problem
-----------
I18n objects are used to internationalize content that cannot be
translated via messages. The problem is three fold:
- Internationalize an object iteself. The best example is 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 to 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
`InternationalizedContent` 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 (choose?) 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 to the translated content
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 chameleon-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.annotation.attribute.AttributeAnnotations, which will be
accomplished in a similar manner as the `I18nObject`.
Open Issues
-----------
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.
|