#174: More configurable and reusable i18n features

Contents
  1. Motivation
  2. Proposal
  3. Participants
by Hanno Schlichting — last modified Jan 21, 2010 07:27 AM

Move code for normalizing of ids out of CMFPlone and make it optionally configurable per language. Also consolidate all the three availablelanguage.py files currently found in AT, CMFPlone and PloneLanguageTool into an external package and hook these up using utilities instead.

Proposed by
Hanno Schlichting
Proposal type
Architecture
Assigned to release
State
completed

Motivation

Plone has some great i18n/l10n capabilities. These have been implemented at various layers of the framework stack and are hard to customize and impossible to re-use. With Zope3 technologies it is possible now to refactor this code into an external pure-Zope3 package, which in turn will be reusable and provide a clearer seperation of concerns. Also using interface driven programming customizability of the features in question will be a lot easier.

Proposal

This proposal aims to rip the following features from the current stack and reintroduce them refactored by using a plone.i18n / plone.app.i18n package combination:

  1. UnicodeNormalizer.py - Used in the automatic title to id generation, this file currently needs to be replaced as a whole when support for new character sets should be added or some small changes to the normalizing logic should be made. Right now this has also grown a relaxed more, for generating technical ids for css files for example. These two should end up as two different utilities, where the first one is optionally language dependend.
  2. availablelanguages.py - This file backs up the language listings found in the metadata_edit view for defining the DC metadata language, in the member properties with no clear intention and backs up the language listings in PloneLanguageTool/LinguaPlone to determine which languages should be allowed to be translated into in a site. Currently there are three independent files which are not in sync by any means. Besides the file in PLT has grown support for showing off the language name in both English, native language name and the ISO639-1 code at the same time, whereas the other listings only show the native name, which isn't optimal in most cases. All these files should be replaced by (local configurable) utilities, based on the same language listing.
  3. Some parts of PloneLanguageTool are generally useful, as for example the whole set of language flags and the yet unused country listing. These should be made reusable by making them available as Zope3 resources instead of through CMF skin layers and utilities.
  4. There is more code in Plone that can be refactored along these lines and the mentioned two packages are good places to put more of these minor features into.


Participants

Hanno Schlichting

Comments (0)