search

tractorcow-farm / silverstripe-fluent

Multi-language translate module for Silverstripe, without having to manage separate site trees.
BSD 3-Clause "New" or "Revised" License
93 stars 111 forks source link

Fluent brakes draft pages #652

Open t3hn0 opened 4 years ago

t3hn0 commented 4 years ago

Fluent doesn't handle saving translations (at least on SiteTree and descendants) correctly on site with multiple locales. I tested this on Fluent 4.4.5, with Silverstripe 4.5.1.

Test case:

Files

Page.php

<?php
class Page extends SiteTree {
    private static $db = [
        'Intro' => 'Text'
    ];

    private static $has_one = [
        'BlocksMain'         => ElementalArea::class,
        'BlocksRight'        => ElementalArea::class,
        'BlocksFooter'       => ElementalArea::class,
        'BlocksPlaceholder'  => ElementalArea::class,
    ];
}

Tables in database:

SiteTree
SiteTree_Live
SiteTree_Versions
SiteTree_Localised
SiteTree_Localised_Live
SiteTree_Localised_Versions

Page
Page_Live
Page_Versions
Page_Localised
Page_Localised_Live
Page_Localised_Versions

Create at least 2 languages in Fluent (in our case SL [sl_SI locale] and EN [en_US locale]).

Create a page in SL language and publish it. Result: This writes data in all of the above tables:

Base tables SiteTree/Page, SiteTree/Page_Live, SiteTree/Page_Versions now contain text in SL language. New ElementalAreaIDs are created. We get versions nr. 1, 2 and 3 of that page.

Switch language to en_US and create translation of same page and publish it. Result: This too writes data in all of the above tables:

Base tables SiteTree/Page, SiteTree/Page_Live, SiteTree/Page_Versions now contain text in EN language. New ElementalAreaIDs are created. We get versions nr. 4 and 5.

Switch back to SL language and click "Save and publish". Result: This creates version nr 6. So far all should be ok.

Switch back to EN language, change Intro (I added a dot at the end) and click "Save" Result: This creates version nr 7.

Table Page now contains EN intro text and ElementalAreaIDs from SL language. // should be all in EN Table _PageVersions now contains EN intro text and ElementalAreaIDs from SL language. // should be all in EN Table _Page_LocalisedVersions now contains EN intro text and ElementalAreaIDs from SL language. // should be all in EN Table SiteTree now contains URLSegment and Title from SL // should be all in EN Table _SiteTree_LocalisedVersions now contains URLSegment and Title from SL // should be all in EN Table _SiteTreeVersions now contains SL content // should be all in EN

Screenshots of content in database: https://imgur.com/a/6QFPmCZ

tractorcow commented 4 years ago

I think you may need to review the discussion on elemental area localisation; it's quite a fussy topic, so it's not hard to product an undesirable output.

The long and short of it is, adding a has_to localised fields doesn't automatically make elemental translated. You need to decide if you are doing direct localisation, or indirect.

have you followed the guide at https://github.com/dnadesign/silverstripe-elemental/blob/4/docs/en/advanced_setup.md#elemental-with-fluent-setup ?

t3hn0 commented 4 years ago

Thanks for link to guide, I'll go through it and check if we have everything set up correctly on our side.

But that still doesn't answer why contents of Title and URLSegment fields from SL language are now in EN draft. You can see that in 1st and 4th tables in image. I know 1st is not so relevant..but SiteTree_Localised_Versions shouldn't contain such values.

tractorcow commented 4 years ago

That's true; Not sure why that is the case.