Migrated from http://open.silverstripe.org/ticket/3503

TinyMCE > Insert Link > Page chooser : Translatable Bug

If you are using Translatable and want to insert a link into a page - TinyMCE shows in all languages only the links from the default language (normally en).

WYSIWYG Editor > Insert Link > Page Chooser

Should be similiar to the existing SubsiteTreeDropdownField? in the subsites module.

Running dev/build throws an error when using an Extension to add custom DB fields to SiteConfig. This actually prevents me from adding any custom fields to SiteConfig. Manually adding the fields to the DB works fine.

Setup to reproduce:

class CustomSiteConfig extends DataExtension {
    public static $db = array('Test' => 'Varchar(255)');
}

And in mysite/_config.php:

Object::add_extension('SiteConfig', 'CustomSiteConfig');

SilverStripe3 has AJAXy URLSegment suggest, which is broken when using Translatable

translatable\code\controller\TranslatableCMSMainExtension.php
LINE 83 decorates links with locale

function updateLink(&$link) {
        if($this->owner->Locale) $link = Controller::join_links($link, '?locale=' . $this->owner->Locale);
    }

As a result, AJAX request to suggest URLSegment is malformed, and returns error:

/admin/pages/edit/EditForm?locale=en_US/field/URLSegment/suggest/?value=MyNewPage

instead of

/admin/pages/edit/EditForm/field/URLSegment/suggest/?value=MyNewPage

Migrated from http://open.silverstripe.org/ticket/4202

Removing fields in getCMSFields() works fine with Translatable enabled. But in translated Pages the original fields still are displayed (as read only).

ideally we can append the "original" field in some augmented formfield instance with the original identifier, rather than creating a new second field instance. Nothing we can do about that for 2.3.2 unforunately. Its closely related to #4183

We are unable to view or edit the different translations of the SiteConfig object using the cms. On the translations tab the different translations are not loaded. Is there a quick fix?

We are currently using it by appending ?locale=en_US so that we can edit the english translation of our SiteConfig.

Thank you in advance!

Migrated from http://open.silverstripe.org/ticket/7779

calls depricated function
static function get_by_locale() calls DataObject::get and makes SS3.01 throw a depricated warning

gives error message about not found Page::$Locale
Fix: add !empty() $locale = ($this->owner->ID && !empty($this->owner->Locale)) ? $this->owner->Locale : Translatable::get_current_locale();

found in:

function augmentSQL(SQLQuery &$query) [...] $locale = ($this->owner->ID && $this->owner->Locale) ? $this->owner->Locale : Translatable::get_current_locale();

Migrated from http://open.silverstripe.org/ticket/7057

In the pages created automatically (Security/Login?, Security/Lostpassword? , Security/Passwordsent? , forummemberprofile/register, etc. ) The texts are not translated correctly although if I connect the appropriate locale.

This is a problem in SilverStripe? 2.4, but I guess it must be equally at SilverStripe? 3, besides is probably a kernel problem.

Example 1:

ScreenShot? SC001.png

_config.php

$cu_locale = 'en_US'; TranslatableEx::set_current_locale($cu_locale); i18n::set_default_locale($cu_locale); i18n::set_locale($cu_locale);

Page.php

public function init() {

parent::init(); $cu_locale = 'es_ES'; TranslatableEx::set_current_locale($cu_locale); i18n::set_default_locale($cu_locale); i18n::set_locale($cu_locale); ........

}

All text is displayed correctly in Spanish, no problem.

ScreenShot? SC002.png

_config.php

$cu_locale = 'en_US'; TranslatableEx::set_current_locale($cu_locale); i18n::set_default_locale($cu_locale); i18n::set_locale($cu_locale);

Page.php

public function init() {

parent::init(); $cu_locale = 'es_ES'; TranslatableEx::set_current_locale($cu_locale); i18n::set_default_locale($cu_locale); i18n::set_locale($cu_locale); ........

}

Login page: All text are displayed correctly in Spanish, except Site Tagline/Slogan? and the page title that are incorrectly displayed in English.

Example 3:

ScreenShot? SC003.png

_config.php

$cu_locale = 'es_ES'; TranslatableEx::set_current_locale($cu_locale); i18n::set_default_locale($cu_locale); i18n::set_locale($cu_locale);

Page.php

public function init() {

parent::init(); $cu_locale = 'es_ES'; TranslatableEx::set_current_locale($cu_locale); i18n::set_default_locale($cu_locale); i18n::set_locale($cu_locale); ........

}

Login page: All text are displayed correctly in Spanish, except Site Tagline/Slogan? that is incorrectly displayed in English.

As you can see, not enough to set the locale in the controller init function, you need to put it into _config.php, however, even putting it in both places, the text Site Tagline/Slogan? is shown incorrectly in English.

In addition to this problem, $_SESSION cannot use to propagate the locale between the pages, since in _config.php not yet exists.

Regards, Jose

http://open.silverstripe.org/attachment/ticket/7057/SC001.png
http://open.silverstripe.org/attachment/ticket/7057/SC002.png
http://open.silverstripe.org/attachment/ticket/7057/SC003.png

Migrated from http://open.silverstripe.org/ticket/6098

I have translatable enabled on SiteConfig?.

I was attempting to use $SiteConfig? in my custom Security_login.ss template and noticed that none of the correct values were being output. A little digging showed that the Database now held a en_US siteconfig even though the current locale was set to en_GB. Security seems to confuse the locale getter.

Another note is that en_US was not in my allowed translations array, so this should never have been created anyway. The site config creator doesn't check the allowed locales before creating it.

Migrated from http://open.silverstripe.org/ticket/5388

In the backend i'm using pages which are not visible on the frontend to structure my content. These pages have sub-pages which are visible in the frontend. That works pretty well.

Example structure:

+-- Site Content
  +-- 2010                    (invisible, en_EN)
    +-- 03                    (invisible, en_EN)
      +-- Article 1           (visible, de_DE, en_EN)
      +-- Article 2           (visible, de_DE, en_EN)
    +-- 04                    (invisible, en_EN)
      +-- Article 1           (visible, de_DE, en_EN)
      +-- Article 2           (visible, de_DE, en_EN)

These 'parent' pages (2010, 03, 04) are in the default language (english) If i now translate a sub-page to another language (german/french/etc.) they are not reachable in the frontend. I have to do a translation of the invisible parent-page to see the translated sub-page in the frontend as well.

Both the parent-pages and it's sub-pages are of a custom type derived from the default "Page" type.

Is there something I forgot to do?

I enabled translation using Object::add_extension('SiteTree?', 'Translatable'); in the mysite/_config.php I also tried to enable translation not globally but only in my derived page type for the sub-pages but that didn't work as well.

Migrated from http://open.silverstripe.org/ticket/3698

Currently you can't edit records in other languages outside of the main CMS interface, although its generally possible to decorate Translatable onto DataObject? subclasses (not only SiteTree? subclasses). It seems fairly simple to implement:

Add a configuration option which is disabled by default, e.g. ModelAdmin::$use_i18n
Add field to default search forms to choose language - would have an "all languages" option
Add "language" column to result list
A dropdown above the search/create forms would handle the "current language", which influence the default seetings for the language search option, as well as the defaults for "create" action

Is there some reason why has_one relations aren't added to the list of translatable fields at https://github.com/silverstripe/silverstripe-translatable/blob/master/code/model/Translatable.php#L538 ?

Related to http://open.silverstripe.org/ticket/6668

Basically add an extra "Locale" column on the join table, and ensure queries are filtered by this property.

Migrated from http://open.silverstripe.org/ticket/4033

On the "Create Translation" tab, add a checkbox to optionally include all children pages when translating into a new language. Make sure all created translations are not published. If any of the children in the tree have been translated already, make sure to honor this translation and don't create a new translation for it.

Ideally, this would work as well when selecting the root-node of a page, so trigger a translation of all toplevel pages including all their children. Currently we don't have a tabbed editform for the root-node, although there might be other use cases for site-wide settings requiring an edit form.

Hi there,
I experienced some strange behaviour using translatable together with the GridField. It throws something like:
Error: "Uncaught InvalidArgumentException: Invalid locale "en_US?locale=en_US?locale=en_US"" at line 299 of ...Translatable.php,
It seems to mess up the get vars here.
if i try to add a new Item to the GridField. Dont knwo if i m missing something here, or this is a bug actually

EDIT: This problem might be caused by the GridField....

Regards
Sebastian

Hi,
when you create a new translation in Edit Page View via the tab "Translations" then the URLSegment that was created looks like that:

kontakt-nl-nlkontakt-nl-nl

(original page had the segment "kontakt")

When you try to change the segment e.g. to "test" and then click save, then the the segment textfield displays the value "testtest".
But in the database it is written correctly (URLSegment: test) and you can open the page via mysite.com/test.

So actually it seems to be just a display problem of the URLSegement Textfield.
Kind regards,
Florian

Hi,

When a new page is created and you add content and choose it as a sub page, it does not save some of the information. Does not save the page content or the id of the parent page.

Is there a fix for this?

Migrated from http://open.silverstripe.org/ticket/4261

Login form (used with /admin or through the Forum module) is presented in the default language, appending ?locale=xx_XX to /admin does not work (as expected), but it works with /Security/login.

It's maybe that the function I'm using to switch languages is faulty, but it works with all other pages.

Migrated from http://open.silverstripe.org/ticket/7044

Followup from #7041

The "Switching languages" section mentions the ?locale= GET param, and using that param would only show links to pages in a certain language. But some pages are statically linked, e.g. Security/login. Describe how to work around this by using session based locales through init(). Also fix usage of Translatable::set_reading_locale().

Migrated from http://open.silverstripe.org/ticket/4939

Steps to reproduce:

Set up a translatable site
Ensure that set_allowed_locales isn't set
Log in as admin and create pages in a few languages
Go to the security area, and the permissions tab on a group
We would expect to have the right to assign permission to translate into each of the languages that we specified. However, the language-specific permission checkboxes aren't shown if we omit set_allowed_locales.

We only have the option "Translate into all available languages".

Recommended fix is to update Translatable::providePermissions() to search for all the translations that have been used on SiteTree? pages, if allowed_locales isn't set.

While the bulk of the logic has been separated out into this module,
there are still many places across SilverStripe CMS which this modules relies on:

• CMSBatchActionHandler->handleAction()
• ContentController->handleRequest()
• ContentController->ContentLocale()
• ErrorPage::response_for()
• LeftAndMain->init()
• ModelAsController->getNestedController()
• RootURLController::get_homepage_link()
• SearchForm
• SiteConfig
• SiteTree->RelativeLink()
• SiteTree->getSiteConfig()

These APIs mostly require either hooks for an Extension subclass,
or refactoring to allow better customization.

When you switch between pages of the site tree on a multilanguage site the Content field html editor is hidden by some javascript code.

When this happens if I reload the page the html editor appears. I tested with a clean installation of silverstripe 3.0.2 and the latest Translatable module on IE9 and Chrome.

The html controls initially appears but is hidden immediately after a few milliseconds when the javascript executes. If I do an inspect of the page using firebug it appears as display none, but if I remove this it appears as a basic textarea.

Migrated from http://open.silverstripe.org/ticket/5122, see for patch file and further comments.

I've created an improved version of Translatable::choose_site_locale with session support, browser language detection and member locale detection. Locale will be assigned in order with following priority:

?Locale= URL
--2. "Locale" Session--

Member->Locale
Browser detection

If the translatable module is installed the details view of a file in the asset admin does not work. I get the following error message:
ERROR [User Error]: Uncaught Exception: Object->__call(): the method 'gettranslation' does not exist on 'Folder'
IN GET /admin/assets/EditForm/field/File/item/2/edit?locale=de_DE
Line 633 in /var/www/rlehmann/pixeltricks/silvercart2/sources/htdocs/framework/core/Object.php

Source

624:
625: default :
626: throw new Exception (
627: "Object->__call(): extra method $method is invalid on $this->class:" . var_export($config,
true)
628: );
629: }
630: } else {
631: // Please do not change the exception code number below.
632:

• 633: throw new Exception("Object->__call(): the method '$method' does not exist on '$this->class'",
  2175);
  634: }
  635: }
  636:
  637: //
  -----------------------------------------------------------------------------------------------------------------
  638:
  639: /**

Trace

Object->__call(getTranslation,Array)
TranslatableCMSMainExtension.php:35

Folder->getTranslation(de_DE)
TranslatableCMSMainExtension.php:35

TranslatableCMSMainExtension->init(,,,,,,)
Object.php:870

Object->extend(init,)
LeftAndMain.php:331

LeftAndMain->init()
AssetAdmin.php:57

AssetAdmin->init()
Controller.php:138

Controller->handleRequest(SS_HTTPRequest,DataModel)
LeftAndMain.php:341

LeftAndMain->handleRequest(SS_HTTPRequest,DataModel)
AdminRootController.php:88

TranslatableCMSMainExtension::init() causes the bug on line 35 when it tries to call the function getTranslation() on a Folder object. Folder is not decorated by Translatable so getTranslation does not exist.

Still this error when I select language and presso GO into the admin panel.

Silverstripe 3.0.3rc2
translatable from github 2012-11-23

And The button create when I select the second language, doesn't work.

Migrated from http://open.silverstripe.org/ticket/3722

Currently you only have "full" translations in our Translatable datamodel, meaning every single column is copied and editable for a specific language. This will lead to problems for properties like prices or foreign key relations - you have to rely on the translator/editor to keep the records consistent across languages.

Master/Original? Record

First problem: In our current datamodel we don't have the notion of a specific "original" - every record is essentially a "translation" in a pool of related pages. This was necessary to avoid requiring that each translated tree is a subset of a master tree (meaning if your "default language" is english, you can't have a german page which is not hooked into an english original). We define "original" as "record in default language" (a static property on Translatable class). This might not always exist, though...

Column Selection

Developers need some way to denote which properties are translatable or global.

Blacklisting

All columns except from the specified ones are translatable.

Whitelisting

Columns need to be explicitly marked as translatable. This gives a more finegrained control, especially when dealing with additional columns from decorators and modules.

Datamodel

Solution 1: Self Joins

Translatable->augmentSQL() would self-join all required tables for a specific dataobject with themselves. This has to happen automatically on a very low level (SQLQuery), meaning we have to detect certain SQL-patterns by string-parsing to limit usage and make sure we still produce valid SQL. As this happens on a database level, its fairly performant though.

To research: Can you self join specific columns only?

Solution 2: ORM-level fallbacks

Each DataObject? would have an optional reference to an "original" or "fallback" record, which is queried upon construction time. This record would be stored as a DataObject? itself, with some special flag to denote its fallback-status. The fallback can just be in one language (Translatable::default_lang()) - if the record doesn't have a related record in this language, there is no fallback for it. Each call to __get() and __set() would now determine if the field in question is translatable, and set the record accordingly. Each call to DataObject::write() would essentially cause two writes (record and fallback).

The big downside of this approach is that its very hard to side-step the ORM and get fallback from straight SQL (see "Solution 1: Self Joins").

How do dynamic getters influence the fallback mechanism?

Does DataObject? caching still work in the same way when each DataObject? can have a fallback?

If no fallback exists, do we allow editing of all fields on the "translation"? Otherwise these fields will not be writeable from anywhere...What happens if this fallback is created later on, after all fields have been written to the translation?

Misc

• Interesting article for different database approaches: http://www.gsdesign.ro/blog/multilanguage-database-design-approach/
• Symfony/Propel? split all i18n columns into a separate table: http://vit.free.fr/symfony/0.6.3/i18n.html ("Text information in the database")

Migrated from http://open.silverstripe.org/ticket/6816

when you change the language in the CMS, you have to separately reload the current page to the current language - this is confusing, counter-intuitive and a superfluous taks

Please update documentation with the right name of the directory the extention needs.
And the place where to put it.

If not in the right place and right name this error is displayed:
The action 'LangForm' does not exist in class CMSPagesController

I've lost lot of time before understand that the name has to be "translatable" and it needs to stay in the Silverstripe root, not under cms, not under mysite, nor under thirdparties.

So like this:
/cms
/framework
/translatable

With the changes in recent site config updates it is now not possible for 'guest' users to be able to view a translated page. This is because in the Model Translatable the canTranslate function requires a permission to be set but non registered users won't ever have this by default. Also when checking for a member no matter what the member is always NULL when even calling Member::currentUser();

This is stemmed from when viewing a page locale it seems to be calling createTranslation which also rewrites it to the DB by default so does not seem like this should be called when simply viewing a page.

Migrated from http://open.silverstripe.org/ticket/5647 (more comments in there)

After translated page has been created, redirect to this new page dosen't work correctly. Link string is wrong -> .../admin/admin/70/show....

This problem occurs in Windows XP, Vista + IE 8.0.6001. Version 2.4 has the same problem, all works fine in Mozilla, Safari, Google Chrome and IE8 in Win7.

It appears that this is a IE specific bug, but it could be alleviated by using a random cache buster string on AJAX request (like all the js/css files carry).

Here is the silverstripe forum link where this problem discussed: http://www.silverstripe.org/general-questions/show/273728#post273728

Best regards, Maarika

Migrated from http://open.silverstripe.org/ticket/2793

This would entai creating extra "_lang" tables for each manymany table (e.g. "MembersGroups_lang"), which would just hold the translated information, and the ID to the original row in the manymany table.

For lack of easy definition at the moment, I would suggest for all extrafields to be translatable by default. As a limitation, we could just create the "_lang" tables when extrafields exist.

Migrated from http://open.silverstripe.org/ticket/6770, see patch files in there.

Assuming I want to remove the MenuTitle? field in CMS from all pages and return Title instead, I modify Page.php by overwriting getCMSFields()

public function getCMSFields() {
$fields = parent::getCMSFields();
$fields->removeByName('MenuTitle');
return $fields;
}
and adding getMenuTitle:

public function getMenuTitle() {
return $this->Title;
}
This works fine when viewing the page in the default locale, but when switching to a localized version of the page, the text field for MenuTitle? is gone, but the original value in English is still displayed. See the first screenshot.

The second problem is when adding elements before other ones. addFieldToTab accepts as third parameter the name of the field to insert before. Again, in English everything appears OK, but in localized versions of the page, the fields are nested incorrectly because of the original version that appears below the input field. See the second screenshot.

From http://open.silverstripe.org/ticket/6433

( Code at: http://open.silverstripe.org/attachment/ticket/6433/mysite.zip )

I added Translatable extension to SiteTree and a DataObject, 'DOStaffMember'. Using a default locale of en_US, i translated a page to another language, and when i open a DataObject from a ComplexTableField, the popup believes it is an en_US locale, not the current locale. this is running silverstripe 2.4.5 release codebase.

after changing a page type of a page that has translations in the cms, getTranlations doesn't return those translations anymore although they are still linked in the translation group. another problem is that these translations are stuck with the original page type forever because the field in the cms is readonly.

since the page type field for translations in the cms is readonly i assume that the page types of all translations are supposed to be changed to the one of the default translation in the Translatable::onBeforeWrite() method. this seems to be broken.

the query for getTranslations filters by classname so getTranslations only returns translations of the same classname. thats probably why the Translatable::onBeforeWrite() method uses this to work around the filter:

    $this->owner->ClassName = $changedFields['ClassName']['before'];
    $translations = $this->owner->getTranslations();
    $this->owner->ClassName = $changedFields['ClassName']['after'];

the weired thing is that $changedFields['ClassName']['before']; is set to the new value instead of the original so getTranslations returns an empty DataList and the following foreach doesn't get executed.

assuming again i think that $changedFields['ClassName']['before'] equals $changedFields['ClassName']['after'] may be due to not using DataObject::setClassName() to change the class name but DataObject::newClassInstance($newpagetype) on the default translation so that the original original class name is not available in Translatable::onBeforeWrite() anymore.

i dont't have a patch to supply at the moment. i'm not even sure if this is a problem in translatable, framework or cms.

Hi, when i create a translation, the system redirect correctly to the translated page, but the locale of the site tree don't change.

Thanks

Hi there,

I am getting the following error trying to access a translated page in frontend if I am not logged in silverstripe backend:

[User Error] Uncaught Exception: Creating a new translation in locale "en_US" is not allowed for this user

My current silverstripe setup is (up-to-date from github repositpries):

silverstripe-silverstripe-installer-3.0.1-8-g494956d
silverstripe-sapphire-3.0.2-76-gd0153f3
silverstripe-silverstripe-cms-3.0.2-17-g4af60df
silverstripe-silverstripe-translatable-1.0.0-28-g67915ea

Trying to view a translated page in frontend silverstripe is running into "createTranslation()" method of Translatable.php model. If I am not logged in as admin the permission check falis. Why should this method be called by a frontend user?

Can anyone reproduce this?

If the locale-filter is disabled, the variable $reEnableFilter on line 1663 in Translatable.php is not defined, this results in a notice during execution.

Every site we've done which needs Chinese translations we've had to add something like the following to _config.php for things to work smoothly.

i18n::$common_languages = array_merge(i18n::$common_languages, array('zh'=>array('Chinese','**的')));
i18n::$common_locales = array_merge(i18n::$common_locales, array('zh_CN'=>array('Chinese','**的')));

There is (rightly) a distinction between Mandarin and Cantonese, however having zh_CN in the list of locales but not in the list of common languages creates a problem. I'm expecting someone to say that zh_CN isn't a language, but it seems to me that it probably is (and in fact, the CMS translation files use zh_CN). Additionally the advice from our translators has always been that written Chinese (the vast majority of websites) should use simplified Chinese, and in fact Mandarin and Cantonese are the same written language. Can anyone confirm or deny?

This has also been a problem for Portuguese in the past.

Migrated from http://open.silverstripe.org/ticket/4231, see patch and comments there.

Currently all the updatecmsfields logic is limited to SiteTree? objects, and it makes certain assumptions on the controller context by the "create translation" action.

I've attached a patch that shows a language dropdown for DataObjects? instead, which sets the locale explicitly rather than through a hidden field. There is no "create translation" action at the moment.

Creating translations is essentially a controller task, and hence shouldn't be baked in to Translatable. It works for CMSMain, now we have to get it working for ComplexTableField? (#4199), ModelAdmin? (#3698) etc.

Migrated to http://open.silverstripe.org/ticket/7058

There should be a standard way of knowing that a page is multilingual by itself, ie Security/Login?, that's to say, that all your texts are translated into global $lang . A function, perhaps in Translatable module, we should give this information, since it should be accessible even from _config.php

We need to know that a page is multi-language by herself to properly connect the locale.

The following, that it is the standard according to documentation, is not suitable for these pages:

Public function init () {

Parent::Init ();

If (Translatable)) { ($this dataRecord hasExtension

i18n::Set locale ($this dataRecord Locale); }

Furthermore, the locale must be possible to change from _config.php, so we should know if a page is multilingual at the time.

We should also have another function to tell us if the page has been created hardcoded.

To know if a page is multilingual by itself, we also suggest that language selection options should be put on the page ($Translations).

Regards, Jose

Hello,

when i try to create a translation in other lang, the module returns this error

ERROR [User Deprecated]: Director::redirect is deprecated. Use Controller->redirect() instead. Called from TranslatableCMSMainExtension->createtranslation.
IN POST /admin/pages/edit/EditForm?locale=en_US

Migrated from http://open.silverstripe.org/ticket/6665

When creating a translations page in IE8 using the translations tab in the CMS after selecting a language and clicking the "Create" button the page is not created, instead I receive a http 404 error.

Migrated from http://open.silverstripe.org/ticket/4070

Selecting a suitable parent page and using 'Create -> Page -> Go' results in the new page appearing in the site tree root. Refreshing the CMS shows that the new page is actually a child of an unpublished copy of the original parent.

NB: This appears to only happen in the default language. The translation gives the expected result, i.e. the child appears under the parent.

See more discussion on original ticket.

Downloaded Silverstripe 3.0.2 stable
Downloaded latest translatable-master from github on 2012-11-23

After put module (into a folder silverstripe-translatable) on site root
and executed /dev/build?flush=1

all the site disappeared.

It's like if now the urls refer to not existent pages.
also /admin doesn't work.

It works again if I change translatable with previous versions (i.e. 1.0.0).

Migrated from http://open.silverstripe.org/ticket/4230

I ran across a bug in 2.3.2-rc2 where pages can disappear from the CMS after translation:

steps to reproduce:
add to mysite/_config.php:
Object::add_extension('SiteTree', 'Translatable');
with an en_US default locale, create a standard page type in the cms, enter content, etc...
create a german translation of the page via the Translations tab
CMS will reload with the german (de_DE) locale. In the main window, the translated page will be visible, however in the left sitetree window, the current page (written in a draft stage) is not selected. if the page is saved & published at this point the database records NULL as the locale and the page wont show up in the CMS or on the site. If I clicked to select the page in the left site tree window before saving and publishing, the page will reload in the main window, and 'save and publish' will correctly record the locale.

Migrated from http://open.silverstripe.org/ticket/4236

StaticPublisher? does not find translated urls when running dev/buildcache.

Migrated from http://open.silverstripe.org/ticket/4071

After enabling translations, existing pages are flagged as changed requiring them to be re-published. (Not sure: Perhaps this is by design?)

Migrated from http://open.silverstripe.org/ticket/3877

See discussions on http://groups.google.com/group/silverstripe-dev/browse_thread/thread/17908f7318decfac#

The translatable feature is only half as useful if all pages have to be addressed with their specific locale as a GET parameter, e.g. http://mydomain.com/mypage/?locale=de_DE.

• While this can be achieved through URL rewriting on Apache level (for a specific language domain or subdomain), it would be more "beginnerfriendly" to allow putting the locale in a toplevel subfolder.
  /de_DE/mypage, /en_US/mypage - this way, the same URLSegment "mypage" could be reused for different languages. This is imposing a URL structure on the system, but seems to be a widespread way of doing things. Would have to be tested for compatibility for the nestedurl work.
• For SEO reasons, a page should just be available under ONE url - so if /de_DE/mypage is the primary location, then /mypage should redirect with a Google-friendly 302 http status code.
• The homepage as a special case should also redirect correctly (mydomain.com -> mydomain.com/), without showing the /home suffix.
• SiteTree?->validURLSegment() should be allowed to overwrite built-in uniqueness checks to allow mydomain.com/de/mypage as well as mydomain.com/en/mypage (ideally only voting TRUE if this specific rule is matched, and doesn't interfere with other logic which might disallow a URL segment, e.g. subsites)
• Links in navigation and CMS URL preview should adapt to the new pattern
• Having unique URLs is also important for caching (proxies, browser) as well as static exports - please test this still works with the new implementation.
• Optional: Validate that the approach still works with the subsites module

Migrated from http://open.silverstripe.org/ticket/7771

I added a DataObject? and ModelAdmin? with this code:

class Category extends DataObject {
        static $db = array(
                'Title' => 'Varchar(255)'
        );
}

class CategoryAdmin extends ModelAdmin {
        public static $url_segment = 'categories';
        public static $menu_title = 'Categories';
        public static $managed_models = array('Category');
}

and this in the mysite/_config.php:

Object::add_extension('Category', 'Translatable');

I then created a Category and attempted to make a new translation of it, and nothing happened. I didn't see any Javascript errors either.

I have been alternating between this and the tractorcow repo in a site with the subsite plugin and multi language.

I have observed than when using the context menu to add pages from another as parent the language query string is prepended to the addPage and breaks it. Furthermore Google would prefer (IMHO) to have a url segment such as mysite/de/mypage as opposed to a query string. This way the same pages can all have the same name.

This article talks about this in a Silverstripe context and failing any developments here I will have a go at marrying it. http://www.balbuss.com/translatable-and-the-url/

Migrated from http://open.silverstripe.org/ticket/4183

getCMSFields / updateCMSFields works fine in translations for all fields in SiteTree? but not in Page or any other SiteTree? or Page sub class.

updateCMSFields should be called after all fields are added (on the results of the final getCMSFields call) (see line 1328 / SiteTree?.php):

$this->extend('updateCMSFields', $fields);

else (see Translatable.php line 805):

$allDataFields = $fields->dataFields();

will return only translatable (and orig) fields from SiteTree?. Fields from sublcasses are added after updateCMSFields is called and therefore are not transformed within the foreach loop starting at 811 / Translatable.php.

This is a bit deeper problem with decorating cmsfields, we have two options:

Build all updateCMSFields() method in a way that they can be applied more than once without altering fields twice, and force developers to call it after every overloaded getCMSFields() call in all subclasses. This is a heavy performance penalty depending on the modifications
Create a new wrapper method in DataObject? around getCMSFields(), which is used instead by CMS forms. Decoration would be applied after all getCMSFields() calls. Ideally we'd need a hook to alter decorated getCMSFields() as well before actually returning the form. This is a deeper change to the API, needs some discussion.