Forgot your password?
New user?
Document Actions
#98: Scripted Translation Service Interface
- Contents
- Proposed by
- Simon Eisenmann
- Proposal type
- Architecture
- Repository branch
- plip98-scripted-translationservice-interface
- State
- completed
Motivation
Right now the scripted translation process is a whole mess and there are lots of collector issues regarding encoding problems related to scripted translations. There is no way to get the encoding from the strings returned by the translate wrapper. Also there is lots of fallback code inside all this methods for Localizer and/or zope 2.6.
Assumptions
- This proposal covers any translation of strings not translated by the i18n syntax within templates.
- This includes localized time strings as well.
Proposal
We need a sane, fully unicode aware interface to the translation service which is accessible from restricted code. This interface does not support Localizer, Python 2.1 or Zope 2.6 and thus does not have any fallbacks inside.
The i18n files need to provide the date translation special message ids, matching msgstrs and translated Weekdays and Month names.
Implementation
utils.py
- All restricted code usable translation interfaces where removed from utils.py
- The utranslate method returns unicode type (the translate method is a reference on the utranslate method for bw compatibility)
TranslationServiceTool
There is a new tool which provides public methods utranslate and localized_time.
- utranslate maps to the utranslate method of CMFPlone.utils
- localized_time translate DateTime instances or date strings to a local time format either long or short using special msgids in the message catalogs.
Localized time
The localized_time method requires two special message ids present to work as designed. When these msgids are not translated for a language, the default strftime formatting as defined at the portal_properties sheet is used.
Long time format:
- msgid: date_format_long
Short time format:
- msgid: date_format_short
Both msgstrs support predefined variable names which have to be used inside the msgstr. These variables are the same as in the strftime formating, but tal style: Supported are %A, %B, %b, %H, %I, %m, %d, %M, %p, %S, %Y, %y, %Z. Variables not numbers (eg weekday and monthname) are passed to the translation service seperately. This means that each weekday / month name needs to be present as msgid as well (english).
Example and default:
msgid "date_format_long" msgstr "${Y}-${m}-${d} ${H}:${M}" msgid "date_format_short" msgstr "${Y}-${m}-${d}"
Skin scripts
Now there are two skin scripts. translate.py returns type string encoded with site encoding. This script uses the new utranslate.py which returns type unicode when required. Using the translate script means you have not thought about unicode. The script itself tries do handle things right, and converts type string to type unicode. Please use utranslate and pass strings as type unicode.
Deliverables
- TranslationServiceTool (done)
- utils.py cleanup (done)
- Unittests update (TODO)
- Localized time translations (done)
- Mapping of month and day numbers -> english numbers (done)
Risks
- The translation wrapper returns type unicode instead of type string. This might lead into various problems for scripts using the current wrapper and expecting type string.
- The translation of month and day names is problematic, as it currently relies on an english locale. We probably need a mapping from week day number -> english name, month number -> english name.
Progress log
- TranslationServiceTool implemented
- utils.py cleaned up
- skin scripts updated
- migration written
Participants
Simon Eisenmann
