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