17488 Posts in 4473 Topics by 1978 members
|Go to End|
25 April 2007 at 6:34am Last edited: 25 April 2007 6:34am
I have a client who wants to have two versions (English and French) of each page. Is it possible to create such website using SilverStripe and let the client manage it on her own.
Thank you in advance.
1 May 2007 at 9:35pm
same issue here:
19 May 2007 at 10:17pm Last edited: 19 May 2007 10:17pm
I'm quite new here, but I need different languages too.
What could be a quick and easy solution is an extra field in the SiteTree_Live (and SiteTree_versions) with a language ID, and a selectbox in the CMS.
Enabling a second language would be quite simple this way.
SilverStripe might need a 'Preferences' page, to enable these site-wide things (also site-title, etc etc). It might need a constants file as well so all language aspects can be removed in templates etc.
The language_id will probably be nessesary in other DB tables as well.
Setting a default language could be nice, so pages not filled in the second (or nth) language defaults to the standard page.
For the actual site the language can be included in the page-path (like domain/home_en/ or domain/en/home/)
20 May 2007 at 4:44pm
internationalisation/localisation support is one of the many GSoC projects that is being worked on over the next few months. - http://www.silverstripe.com/google-summer-of-code-students-announced/ . So hopefully you will see some new wicked features eg different language support in the future.
21 May 2007 at 10:32pm
"SilverStripe might need a 'Preferences' page, to enable these site-wide things (also site-title, etc etc). It might need a constants file as well so all language aspects can be removed in templates etc. "
good idea - at the moment, we're trying to keep global preferences mostly in <myproject>/_config.php (as static variables or constants), but we understand the need for a preferences-GUI. at the moment, we're trying to figure out how to avoid horrible global array-structures like TypoScript (http://typo3.org/documentation/document-library/core-documentation) and retain the flexibility of "code-level" settings (inheritance, easy access, ...).
|Go to Top|