Issue Details (XML | Word | Printable)

Key: MAGNOLIA-1431
Type: New Feature New Feature
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Philipp Bärfuss
Reporter: Philipp Bärfuss
Votes: 1
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
Magnolia

i18n: basic content support

Created: 20/Mar/07 02:27 PM   Updated: 17/Mar/09 07:49 PM
Component/s: templating
Affects Version/s: 3.0 Final
Fix Version/s: 3.5 RC1

Time Tracking:
Not Specified

Issue Links:
relation
 
supersession
 

Labels:
Resolution Date: 06/Nov/07 04:04 PM
Date of First Response: 27/Apr/07 04:57 PM


 Description  « Hide
Currently magnolia does not give any advise how to implement i18n support for content. In cases where you have a single page structure with translations you have to come up with a custom solution. Till now the philosophy was that we can not solve this problem in general and that each setup has other needs.

This is still our opinion but we think it is time to deliver basic support for facilitate implementations. More sophisticated all-over approaches may follow in later version.

The framework will support

  • i18n url building (/en/*, page.en.html, ...)
  • multilanguage content
  • all mechanism should be replaceable

The first very basic implementation will do:

  • create url using the separator technic (pagename.en.html)
  • cache is automatically supported by this approach
  • bookmarking is possible
  • cms:out tag extension
  • text_de, text_en fields are used according to the current language if present
  • default language (fallback if content is not translated)
  • cooky (remember selected language)

This allows:

  • build paragraphs with tabs per language just by having language suffixes in the names


 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Philipp Bracher [old account - now Philipp Bärfuss] added a comment - 27/Apr/07 04:57 PM
I commited a first version (so that it goes into the M1 release). It works as such:
  • You call your page with a selector
  • example mypage.de.html
  • After calling a page with a selector the creates links uses the selector as well
  • cms:out tag uses support to get a nodedata
  • i18n support checks if the nodedata exists with the lanugage extension
  • example: title_de
  • if it doesn't exist the normal nodedata is returned --> title
  • in your dialog you define the controls for the languages you support (normal you will do a tab per language)

Philipp Bracher [old account - now Philipp Bärfuss] added a comment - 11/May/07 04:13 PM
  • I added an i18n filter
  • changed the default implementation so that it uses a language prefix like /en/mypage.html
  • the configuration is found at /server/i18n/content

Vivian Steller added a comment - 20/Sep/07 10:14 AM
  • separated two levels of locales: user's locale (the one that is determined from the Magnolia User) and content's locale (the one that is determined from the URI like /es/any/page)
  • user locale is stored in MgnlContext (i.e. Context); content locale is stored in AggregationState
  • Template renderers (JspTemplateRenderer and FreemarkerParagraphRenderer) now grab the locale from Aggr

Grégory Joseph added a comment - 18/Oct/07 08:59 PM
Revision #11392 removed the setLocale method from WebContextImpl. Is there any specific reason? This contradicts with MAGNOLIA-1513.

Grégory Joseph added a comment - 19/Oct/07 02:09 PM
Ok - Since r11390-11392 etc, the jstl locale is set through the JspTemplateRenderer.
I'll change this and have it set by the I18nContentSupportFilter so that we're sure it's always available; it's also more "centralized", i.e anything that's locale-oriented and request-based is set by this filter.