[Cubicweb] cube proposal for i18n content management

Florent Cayré florent.cayre at gmail.com
Tue Sep 13 05:47:50 CEST 2011


Hi Aurélien,

Le 12/09/2011 17:11, aurélien campéas a écrit :
>
>
> 2011/9/12 Florent Cayré <florent.cayre at gmail.com 
> <mailto:florent.cayre at gmail.com>>
>
>     Hi list,
>
>
> Hi Florent,
>
>
>     I am about to write a new cube for my own needs: easily write and
>     maintain a web site with textual content translated in several
>     languages.
>     I do not like CMS-like solutions where content translations only
>     reside in the database, but would like to maintain them in
>     mercurial too (providing the ability to easily rollback, see
>     versino history, and so on).
>
>     Below is the small document I just wrote about it, with
>     specifications and first implementation directions.
>     If you know a better/ more general way to do it or have any
>     suggestion, please tell me through the list.
>
>
> I am sure it does not cover everything you want but there is the 
> 'document' cube ... It mixes vcsfile and i18ncontent. It was extracted 
> from the Docaster application used to manage the code aster 
> documentation (hundreds of openoffice documents in a mercurial 
> repository) with a branchy history and translations. Still as of today 
> it is a base for Docaster.
>
> Document handles plain files that represent translations of other 
> plain files ...
> So it does not fit the bill wrt your (more general) requirements.
>
> Just making sure you know the existence of these things.
Thanks for pointing the document cube, I did not know anything about it 
and just went through the code, it was worth it : although it does not 
fulfil my needs, ideas from it are of interest for current subject.
>
> I wish you fun & good luck building your hg-backed cms :)
I do not intend to include any CMS part in the present work, "only" 
versioned i18n attributes.
>
> (somehow I think the hg-backed thing & i18n thing ought to be 
> completely independently usable, e.g I'd like to use a component as 
> written below to handle the i18n aspects of a blog without being tied 
> to VersionContent/vcsfile entities)
>
Indeed, it should be possible to do this, I will try to.
>
>
>     Thanks for your feedback,
>     Florent.
>
>
>     Specifications
>     --------------
>
>     Basic needs:
>
>     * translations should be manageable through VCS and the web interface
>
>      - add a translation, edit the reference version of a text or its
>     translations
>
>      - mark the reference version or one of its translations as 'on-line'
>
>     * must be totally non intrusive in the application schema: managed
>     only by new
>     entity types
>
>
> what does that mean ?
I do not like the idea of i18ncontent that an entity is translated by 
another: not only some attributes may not be translated (an url for 
example), but also, if you assume there are no untranslatable 
attributes, you then naturally use the same entity type for the 
translations, which influences the way you design your initial schema: 
for example, you can no more have a relation with a '1' cardinality to 
your entity type as object, otherwise it is also mandatory for your 
translations. This is not good for cube interoperability. I think 
translations are entity types by themselves (which also naturally solves 
the problem of the "master" entity: there is a single entity, written in 
a given language, translations are naturally "slaves" of it).
>
>
>     * translations can be defined at the field level, but still easy
>     to contribute:
>     should be able to define translations for each translatable field
>     independently,
>     but all fields should be editable at once through the web
>     interface (in a single
>     form). 
>
>
>     Tools translation managers and translators will need:
>
>     * easy way to know if translations are up-to-date compared to last
>     default
>     revision (based on a date + a flag telling if an entity field edition
>     should lead to a translation into the other languages or not
>
>     * list missing/ deprecated translations
>
>     * rollback on-line versions to a given VCS revision
>
>
> This is all provided by or easily addable on top of Document.
>
>
>
>     Implementation
>     --------------
>
>     Use the vcsfile cube to maintain the translations:
>
>     * in the repository, one language corresponds to one branch, one
>     folder to one entity,
>     one file to one field
>
>
>     * from the database point of view, the schema could look like:
>
>      class Language(EntityType):
>         """registered language for an application.
>
>         See http://www.loc.gov/standards/iso639-2 for available codes.
>         """
>         code = String(required=True, maxsize=2, unique=True,
>                       description=_('ISO 639.2 Code'))
>         name = String(required=True, internationalizable=True, maxsize=37,
>                       description=_('ISO description'))
>
>
>      class Translation(EntityType):
>         __unique_together__ = ('fieldname', 'lang', 'translation_of')
>
>         fieldname = String(required=True, maxsize=64)
>         lang = SubjectRelation('Language', cardinality='1*', inlined=True,
>                                composite='object')
>         content = SubjectRelation('VersionContent', cardinality='1?',
>     inlined=True)
>
>
>      class translation_of(RelationType):
>         subject = 'Translation'
>         cardinality = '1*'
>         inlined = True
>
>
>     Ideally, using it with the `card` cube would only consist in defining
>     one RelationDefinition instance for each translatable entity type
>     like:
>
>      class translation_of(RelationDefinition):
>           object = 'Card'
>
>     and an adapter inheriting a supplied base entity adapter
>     `TranslatableAdapter`:
>
>      class TranslatableCardAdapter(TranslatableAdapter):
>           translatable_fields = ('title', 'synopsis', 'content')
>
>     However, implementing translation display would probably imply
>     monkey patching
>     `Entity.printable_value` so that it calls the adapter.
>     If anyone has a better method, please tell me.
>
>     Another difficult point is regarding data migration: what if a
>     translatable attribute
>     is dropped or renamed?
>
>     Hooks needed:
>
>     * translatable field creation/ edition in the web interface:
>     new `online` tagged revision of the corresponding file in the
>     repository
>
>     * translatable entity deletion: removal of the corresponding files
>     in the
>     repository
>
>     * `content` relation synchronization with the online repository tag
>     (or tip if not present?)
>
>     _______________________________________________
>     Cubicweb mailing list
>     Cubicweb at lists.cubicweb.org <mailto:Cubicweb at lists.cubicweb.org>
>     http://lists.cubicweb.org/mailman/listinfo/cubicweb
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubicweb.org/pipermail/cubicweb/attachments/20110913/4ee52518/attachment-0186.html>


More information about the Cubicweb mailing list