Ingo,

You guys came up with a very elegant solution to the Translatable problem, thanks for that !

The problem with the default-language is sorted. I did find a little problem when upgrading an old site though ..

I created a ticket in Trac :
http://open.silverstripe.org/ticket/4009

Hello,

I tested the new release and I've got some questions.

In mysite/_config.php, I add these lines

Object::add_extension('SiteTree', 'Translatable');
Translatable::set_default_locale('fr_FR');

I've got the content language in french, it's OK.

But when I try to make this, the language is always english :

- Login to the admin zone : http://www.mysilverstripe.com/Security/login

How can I do ?

I must have these lines too ?

In 2.2.4, I had :

i18n::enable();
i18n::set_default_lang('fr');
i18n::set_locale('fr_FR');

Sorry but I don't understand the new release and the documentation and I m not a developper :(

The Translatable locale is different from the i18n locale (you might view a page in english, but with german date settings etc). i18n spans to all templates though, so this distinction becomes a bit more fuzzy that we'd like it to be. If you want static template content to react to the pages' language, the best place is Page_Controller->init() which should be executed before any template output is rendered.

Thanks Ingo, I will try this method.

A big bug

1. I put the code in _config.php
Object::add_extension('SiteTree', 'Translatable');
Translatable::set_default_locale('fr_FR');

2. I run a dev/build

3. I change the default language in the admin area
If I don't change the default language, the bug doesn t appear.

4. I logged out

5. When I try to login in the admin area, the page is not loading. I ve got only the Silverstripe logo and i can t have access to the area.

Hi developers
Thanks for the new-and-improved translatable - I'm going to be very happy!!! On my first try of 2.3.2b I found some issues:

I set my site to Translatable::set_default_locale('nl_NL'); and added Translatable as Object::add_extension('SiteTree', 'Translatable'); So far so good.

1.
I created an english translation for a couple of pages. I found that Page version history is not available in the cms for this secundary language. It says 'Can't find page #5' although the info (#5) is stored correctly in the SiteTree-versions table

2.
Now I deleted a page from the secundary language. Without first selecting another page (the screen still shows the 'this page has been deleted' message) I navigated back to the Dutch language, and got the following error (repeated).

. Website Error
. There has been an error
. The website server has not been able to respond to your request.

At times it took a whole lot of switching back and forth (with page load error popups and things) before I regained a working SiteTree again...

3.
I don't know if this is by design, but after making some translations to the english and german secundary languages, both english and german translations are mentioned in the Translation tab of the translations themselves (Existing translations), but they are never mentioned in the (original) dutch language page's translation tab where I expected them to be (confused? I hope not)

4.
This is not a bug, but still seems somewhat unpractical: translating a page from a higher hierachy will create an entire tree up to the selected page. But there seems to be no obvious way to translate its sibblings: for each one a new tree is translated, resulting in (if you're unlucky), an awfull lot of similar trees you'll have to reorder and clear away... Please forgive me if I missed something here. I think it would be handy to be able to translate a tree down from a certain page - instead of up: you could then translate an entire tree or just a part of it. A partial tree could be easily dragged to a new location... And I wouldn't mind being able to create singlepage translations...

I'm really looking forward to using this. I'm very happy with the freedom of creating extra pages for all languages.

Thanks a lot for the detailed bug reports, I've filed them as tickets:
http://open.silverstripe.com/ticket/4016
http://open.silverstripe.com/ticket/4013
http://open.silverstripe.com/ticket/4014
http://open.silverstripe.com/ticket/4015

> I don't know if this is by design, but after making some translations to the english and german secundary languages, both english and german translations are mentioned in the Translation tab of the translations themselves (Existing translations), but they are never mentioned in the (original) dutch language page's translation tab where I expected them to be (confused? I hope not)

Did you use the "Translation"->"Create" tab? Switching to a language via the left-hand language dropdown and then using the standard CMS "create page" functionality won't recognize a page as a translation.

> This is not a bug, but still seems somewhat unpractical: translating a page from a higher hierachy will create an entire tree up to the selected page.

This is by design, yeah. If we wouldn't translate the parent pages (in an unpublished state), the translation wouldn't be accessible through the sitetree in the CMS. You can still translate "top down" though, unless I'm missing something here :)

> And I wouldn't mind being able to create singlepage translations...

That should be possible - just make sure to translate the homepage instead of just creating a new page for an empty translation. Otherwise choosing the homepage for a certain locale gets tricky when called by /?locale=xx_YY instead of /my-translated-homepage-url.

@Ingo
Glad to be of some help :-)

> Did you use the "Translation"->"Create" tab?

Yes I did. Maybe this is a consequence of starting with a default language other then English? Haven't tested this yet...

> This is by design, yeah. If we wouldn't translate the parent pages...

OK, I think there might be some confusion about top down/bottom up. Anyway - let me explain what happens by example. Lets say in the default language (dutch) I have a ParentPage with two children (ChildPage1 and ChildPage2). When I translate the ParentPage to Enlish, these children are ignored, and only the ParentPage is translated - which is by design I now understand.

But when I try and translate Childpage1, it is not added to the ParentPage translated earlier. Instead a new ParentPage is created that has ChildPage1. Translating ChildPage2 results in a third ParentPage that has ChildPage2. If I understand you correctly the CMS should have remembered where the ChildPages belonged in the translation? In that case this is a bug, maybe connected with the fact that no existing translations are mentioned/remembered in the default language pages...

If not - I dread what would happen if I had 30 ChildPages... :-)

Oh, and I forgot: I think it would be nice to have an option to translate a whole tree in one turn, and then happely start translating it in bits and pieces (since they're all unpublished anyway) without having to switch back to the other language all the time to collect sibblings and grandchildren, remembering which ones I'm still missing, and from which language I got them in the first place? Or did I miss that one again? :-)