refs Ability to add Translation for CMS pages and CMS blocks.

[miguelbalparda]

Translate CMS Pages in Magento. New PR for #506 as requested by @maksek

Use: In any CMS Page or Block use {{translate text="Text here"}} and the text will be translatable with the Inline translator.

Also available as custom variable:

[Sanuch]

Where is this method use?

[miguelbalparda]

@Sanuch that method is the one in charge of making the {{translate text="Text here"}} directive usable in pages/blocks.

[verklov]

MAGETWO-32350

[verklov]

@miguelbalparda, so the issue you are trying to solve is that text content on CMS pages cannot be changed via inline translates. You suggest adding a custom variable and all text that you enter want translated on a page must be contained in this variable instance, right?

I am just wondering how often people think of using inline translates to localize content of CMS pages? I guess this functionality was designed for a bit different purpose - for interface labels, not the content, so using inline translates for the page content is a bit weird as for me.

What I am thinking of as a solution is to have similar approach to CMS pages as for products. In this way you would create content of a page and then replace the original (for example, English) text with Spanish, German, French etc. localized text having switched to a specific store view with all other content like widgets inserted on a page preserved.

Please let me know your thoughts.

[miguelbalparda]

I think the decision to translate or not CMS pages with a variable should not be taken but left to the Magento user.
This is just another possibility for the end user, there will be cases where translating pages will be the best approach and cases where it will not be advisable, but the end decision will be left to the end user. I think the best architecture is the one where you don't take decisions for the end user but let them decide with the resources the plattform have.
I created this extension for Magento 1 from a StackExchange post and it had a pretty good acceptance among the users, always knowing they have to check by themselves if this is the approach they need or not.

[maksek]

Hi @miguelbalparda. Why do you think CMS page must be translated the way? Usually for CMS you need to change webstore and create completely new CMS for it. At the same time if you use some variables they will be translated using locale.
From first look it overuse of the Translator, and there is unknown side effect with respect to CMS pages.
Have you validated performance impact, severe store view with different locales e.t.c.?

[tzyganu]

@maksek @miguelbalparda. Not really related to this issue, but still related to CMS translation.

Why not make the CMS entities (pages, blocks) EAV with a flat indexer.
Now (M1 I mean) I kind of struggle to make relations between 2 pages available in 2 different store views that actually mean the same thing. Now I have to create them as 2 separate pages each one available in one store view only. In order to link them I have to use the same url key but sometimes I need different url key for SEO purposes.

My very custom and not so good solution is to have an additional internal field that acts as a common identifier.

An EAV approach would solve these problems.
I know this means a lot of refactoring, but could you at least consider it? Or at least give some reasons for not taking this approach?

[miguelbalparda]

@maksek i did validated this in a Magento 1 site and the site's performance was not impacted. I did not checked the impact on Magento 2, but in my opinion should be minimum.
As i answered @verklov this is a new approach only valid for certain cases, but it should be a Magento user decision. Creating and maintaining CMS pages is something a stakeholder normally ask to do by themselves and this will definitelly simplify this task for them.
I think the main issue about this PR is the fact that the feature is new and it will add a new possibility for any end users of the plattform, but that is not necessarily bad.

[verklov]

@miguelbalparda, since the Inline Translates functionality was designed for overriding interface labels localization and has no idea of localizing pages content behind, we do not consider having this functionality in Magento 2 core. Nevertheless, we highly encourage you to create an extension for Magento 2 in the same way you did for Magento 1, so community members preferring this way of localizing content on CMS pages would take advantage of your suggested functionality.

[maksek]

Hi @tzyganu, interesting idea. Not sure if EAV makes sense in the specific case you described, maybe having 1 additional row with linkage is enough.EAV is heavyweight pattern and implementing him for CMS requires more complex case. But it is worth to be considered, i will contact product team. Thanks!

[verklov]

@tzyganu, could you please provide the reason for the necessity of linking two pages (localized variations of the same page) assigned to different store views?

From the SEO perspective, if I am not mistaken, even if you set the URL for both pages to be the same, if you go to Stores > Configuration > Web and enable the Add Store Codes to Urls setting, SE will be able to index both pages as their URLs will be different thanks to the store codes added to URLs.

[tzyganu]

@verklov I can list here the impediments I found so far related to the CMS while working with M1. I'm not saying that an EAV approach would solve all the issues (maybe it will create others) but It has some advantages. Let's say I have 2 store views. EN and FR. (the problems are even worse for each store view added)

• Inserting a page link / static block widget. Because UI for inserting the widgets uses the entities ID, I have to insert in a page 2 widgets each time (one for each store view) to make sure the page link / static block show up on each store. And I have to edit everything and insert new widgets if I add a new language.
• Switching languages on cms pages. In the EN store I view the page about-us and want to switch to FR. I should see a-propos-de-nous in URL. I have to create the redirects manually (or with a tool). On an EAV approach, the rewrites could be on the save event.
• If I add a new language I have to make sure to duplicate all my pages and static blocks from an existing one so I won't get empty page sections or 404 pages. For example I add the RO language. Until I'm able to translate my legal-terms page, I would rather my customers see a page in EN than a 404. Now, In order to do this I have to edit all the pages and relate them to the RO store view in order to avoid 404 pages. Same goes for static blocks.

And most important maybe...having the CMS section behave like the catalog section I won't have to explain to the clients, why they need 2 pages, and why is done some way in one place and another way in the other place. I would just say, "You fill in some default values, then you change the from the top left corner and translate your page.".

[verklov]

@tzyganu, we've looked at the issues that you mentioned in the previous comment. Here are the comments that I have based on what I understood:

1. If you have, let's say two store views, you have to create two pages each for its localization and also do double work to have a widget inserted on each page, right?
2. Again, having two localizations (store views), you'd like to switch from EN to FR store view on the frontend and to see the reflection of this in localized URLs that you specified for the localized pages.
3. You have to duplicate all the content for a new store view if you introduce one.

Here are improvements I'd like to suggest to be done in scope of CMS to resolve issues that you and others have:

1. Add scope selector to CMS entities on the backend like it is made for products. This will solve the necessity of creating multiple pages for each store view. As a result, you will always create one page and operate with its content having switched to a specific desired store view. The principle of having the default value entered will be preserved. So that, for example, English content will also be used for the French store view until you clear the Use Default check box and enter the French localized text.
2. Add the ability of creating permanent redirects to CMS pages as it is done in Categories. This will allow you specify localized URL for, for example, the French store view or other.
3. Have single widget configuration per instance on all store views. Let's say you insert a widget instance on a CMS page while having multiple store views. Once you clear the Use Default check box on each store view, there appears to be as many widget instances as you have store views. To save your efforts and time, widget instance is configured once for a page variations in all store views. Configuration changes are applied then to all variations of a page existing in different store views.

I am interested in your opinion regarding the suggested improvements I described. Could you please share your thoughts?

Thank you!

[tzyganu]

@verklov I'm 100% on board with your suggested improvements. Having a store view selector will help for sure the editors. It doesn't even need to be an EAV entity. If there selector is there it's enough (even if I can't still imagine how will that work if it's not EAV - but I trust you). And the auto URL rewrites would be a big help.

[verklov]

Thank you for your feedback, @tzyganu! I really appreciate it. We will be discussing the technical details with the architects more to provide a better solution. Please feel free to suggest more of what's on your mind. Your suggestions are valuable source of information for us.

[kishanemipro]

I think in Magento2, CMS page and static block should be EAV entity instead of flat entity. So that it have store switcher ability same like product entity and page or static block can be translated within single entry (by switching store view).

[viktor-zhuromskyy]

👍