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

i18n translated content not displayed in CMS preview #680

Open jakxnz opened 3 years ago

jakxnz commented 3 years ago

Versions

tractorcow/silverstripe-fluent                           4.5.1

Issue

Content that I configure in an i81n language file (e.g app/_config/lang/mi.yml) is not displayed when I view the website via the CMS Preview in that same locale

Steps to reproduce:

  1. Create a language file for a locale e.g mi.yml https://docs.silverstripe.org/en/4/developer_guides/i18n/, add a translate reference in the locale's namespace
mi:
    Page:
        GREETING: "Kia ora"
  1. Create Fluent locale in the CMS e.g for mi_NZ
  2. Use a _t reference (either with the PHP function or a template) somewhere that appears on the front-end (e.g in Page.ss or the like)
<%t Page.GREETING "Hello" %>
  1. In the CMS, switch to the locale for the translation
  2. Visit a page that can view your _t reference

Result:

The i18n content is not translated to the current Fluent locale, selected in the CMS.

Expected result:

I'm not really sure. It would be nice if the correct language file reference was used, but I don't know if this causes any conflicts. Any thoughts?

tractorcow commented 3 years ago

Not 100% sure what's causing this, but a good fix would be to ensure that all CMS preview links had the locale querystring hard-coded into the url. :P That could probably "force" the rendered locale to be correct.

jakxnz commented 3 years ago

I can see that working.

We overrode the logic at https://github.com/tractorcow-farm/silverstripe-fluent/blob/5.0/src/Middleware/InitStateMiddleware.php#L74, to make our project consider the CMSPrevew as "frontend"

i.e

/**
 * Customised middleware for initialising fluent state
 */
class InitStateMiddleware extends \TractorCow\Fluent\Middleware\InitStateMiddleware
{
    /**
     * Overriding {@see \TractorCow\Fluent\Middleware\InitStateMiddleware::getIsFrontend()}
     * to tweak a small aspect of the logic
     *
     * {@inheritDoc}
     */
    public function getIsFrontend(HTTPRequest $request)
    {
        $bool = parent::getIsFrontend($request);

        if ($request->getVar('CMSPreview')) {
            $bool = true;
        }

        return $bool;
    }
}
tractorcow commented 3 years ago

I think there's an argument that maybe CMSPreview SHOULD have been treated as frontend.

Maybe we should make that change up into core?

Good debugging by the way. :)

tractorcow commented 3 years ago

The reason for this may have been the "you can see un-localised pages in the CMS only" problem. It shouldn't be an issue if we have saved the page, and it's visible in the current locale.

jakxnz commented 3 years ago

That does raise an interesting point. It also makes me wonder: If page content is being inherited from a default locale, should the i18n translations match the currently selected locale in the CMS? Or should they also defer to the default locale?

If we want alignment, we have the inverse issue at the frontend. I believe (using the current version), if you're viewing content inherited from a fallback locale, it will still display the i18n references for the current locale.