Re: multilanguage advice: p.a.m or multilanguagefields?

Kees Hink <[email protected]>
Newsgroups gmane.comp.web.zope.plone.user
Message-ID <[email protected]>
I just uploaded what we have so far to 
https://github.com/collective/collective.multilanguagefields, hoping it 
will help to form thoughts.

We have, so far:
* a multilanguage TextLine field
* this is stored as a dictionary having the language code as keys.
* rendered field value should be the dictionary value for the current 
request language. Failing that, it falls back to site default language, 
or finally whatever language we do have.

Currently the problems are mostly with having a multilingual title 
field, which is to us in an important use case:

* our INameFromTitle behavior setup isn't working like it should: We 
need to specify the exact behavior interface in our content type's FTI.

* attribute access takes precedence over method access in some cases 
(dexterity accesses the attribute directly), so we probably we need to 
store in a different attribute (like _ml_FIELDNAME) and create a custom 
getter/setter in a DataManager.

* plone.app.layout.viewlets.common accesses the title attribute 
directly, so an override for the Title() method is necessary.


On 22/12/14 12:02, Kees Hink wrote:
> We're building a site that should have very basic multilingual functionality:
>
> * Title and Description should be translatable.
>    - This is about custom content types (DT) and Plone's dexterity content types.
>    - All other fields are language-independent.
>    - Content types may contain Images, which should also not be translated.
> * Pages should be translated. (There are not many of these, <10, all
> in site root)
> * Currently we have 3 languages, later others may be added.
>
>>From the start we were not sure if plone.app.multilingual is a good
> solution for this. Will it be possible to mark the Images as not
> needing translation? Won't it be an overly complex solution?
>
> We were considering an approach where we create extra fields for the
> Title and Description in the desired language, but we might want to
> roll out the product to other customers with different selectable
> languages.
>
> We are now considering creating a simple dexterity version of
> raptus.multilinguagefields.
>
> Can anyone suggest a good reason to use p.a.m? Anyone interested in a
> DT version of multilanguagefields? Other thoughts?
>
> Kees
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.