How to handle a locale switch when the record is not localised?

[conny-nyman]

Hello,

I would like to ask for some advice on how to handle a locale switch when viewing a record which is not localised? Currently SilverStripe will return a 404 which makes sense but it's not very user friendly for CMS users which are not familiar with the data model.

I already opened an issue in the Elemental repository but they suggested me to open it here as it is only related to Fluent not Elemental (https://github.com/dnadesign/silverstripe-elemental/issues/771).

[tractorcow]

I see the context of this issue is in the CMS (not the frontend), so it does feel a bit concerning... I've not often seen fluent 404 inside the CMS before.

Indirect localisation does feel like a good general solution; You don't want to force all locales to have the same content blocks, so segmenting each locale by ElementalAreaID feels natural. However, you may not want to use this for your project if it's causing you these issues.

So, in order to help you get your project fixed, I could suggest that you use direct localisation; You would need to localise the content blocks directly, rather than segmenting the area ID. This would still mean that (unless you do a bit of extra work) you would end up with the same blocks for each region, just with different content in each. This may suit your case...

To do direct localisation:

• Remove ElementalAreaID from field_include
• Add FluentExtension to the content block base class
• Ensure that each block has the right localised fields (you may need to add a translate config to each block to tweak).

The docs at https://github.com/dnadesign/silverstripe-elemental/blob/master/docs/en/advanced_setup.md#elemental-with-fluent-setup are pretty good, but they only do a good job of presenting one real solution. There is a bit of a mix of fluent 3 / 4 docs there heh. :) I might need to go make a PR there.

In order to fix the core fluent issue (changing locale sometimes causes a 404 if a block isn't visible), then the issue is a bit trickier... we would need to find a way to get the current record and the left hand menu to talk to each other (somehow).

Maybe we could implement a 404 handler in the CMS, so that fluent captures these errors and does a redirect. It's a serious edge case though, so it would require a bit of testing.

[conny-nyman]

Thanks @tractorcow for the detailed response.

I have started to use direct localisation in a few projects and it's working great. I guess for projects where some pages will have shared blocks and some unique blocks per locale, the solution could be to create two different block page types, one that uses direct localisation for shared blocks and the other one with indirect localisation for unique set of blocks

In order to fix the core fluent issue (changing locale sometimes causes a 404 if a block isn't visible), then the issue is a bit trickier... we would need to find a way to get the current record and the left hand menu to talk to each other (somehow).

Maybe we could implement a 404 handler in the CMS, so that fluent captures these errors and does a redirect. It's a serious edge case though, so it would require a bit of testing.

Yes that would probably work, and I agree it can be tricky to get it tested correctly.

[tractorcow]

If you are doing direct localisation and need to toggle certain blocks on/off for each region, you can consider adding FluentFilteredExtension, although it increases the amount of work you need to do to manage block visibility.

The develop branch has improved handling of this, but I haven't tested this with elemental yet.

[mfendeksilverstripe]

@conny-nyman Another consideration is to use this suggestion. You can override locale switcher link to point to page edit form instead of the block edit form. This will make the 404s go away :)

Direct localisation on blocks is fine as long as the content structure is almost identical in different locales. With major differences in content structure the direct localisation becomes tedious to manage.