[Resolved] Problem Content template translation files

[Author]

Posts

[paulw-2]

Hi there,

We build a website with native language EN and translations in DE and NL.
Our client haves a partner in NL and want a duplicate there original website under another domain but with native language NL.

After moving the site and change the default language to NL the wp-views content templates are not editable and says:
"You are trying to edit a Content Template translation. Only original laguage can be edited here. Please edit the translation through WPML Translation Management."

This was expected so I've changed the native language back to EN again but when I try to open the content template it's still giving the message.

The original website
The problem seems to occur also on the original website.
It's not possible to have any of the three languages as native and open the original template file.

Can somebody help us out to just open the original WP-views content templates?

Hope you can help us out...
Kind regards,

Paul Wolthuis

p.s.

WPML vs Toolset
Why is it made so difficult and static to translate templates (the way it works now)? If I remember right it was possible in the past.

It would be much easier and more flexible if there is a possibility to use a different template per language in stead of the translation fields it has now.

In that case we would have the possibility to:
- serve another design to different languages (which might be great because different markets (read language groups) have different needs
- Possibly. easier switch the native language (since every language has another template file)

[Beda]

Toolset Content Templates are (usually) created in the default language of the website.
There is nothing we can change about this since it's how it works since a while now (mainly the idea here is to translate the Content Templates later in String Translation)

However, you have the option to have a dedicated Content Template for each language, and maybe it is that which you mean?
In this case, you need to head to Toolset > Settings > WPML and allow a CT each Language.
Then, you will not translate anymore the CT in String Translation but create a new CT for each language.
This allows full power over the output in every single language and avoids tedious translation of strings.

If you have not set this option and instead have one CT for all languages, to be translated in WPML, and after changing the native blog language it's stuck on non-editable, then this is because the old default language may still be stored.
I would here suggest contacting WPML support to solve this (in WPML > Support > Debug there are some buttons to actually solve this issues, which usually come from mis-assignments of translations and other, but it's best you ask WPML Specialists about this here https://wpml.org/forums/forum/english-support/)

Also, another option is to migrate the site as is, then copy the contents of the CT, save locally, delete the CT and recreate it in the new default language.
This way you should be able to avoid the current blocking issue.

[paulw-2]

Hi Beda,

Thanks.
Also, another option is to migrate the site as is, then copy the contents of the CT, save locally, delete the CT and recreate it in the new default language. This way you should be able to avoid the current blocking issue.
We moved the website as is - after that we changed the default language.
When we noticed it was impossible to open the template, we changed it back to the original default language but it was still not possible to open.

I cannot understand why it would be impossible to to open the template after changing the default language.
In my opinion it would be easier to attach a language to the file but not dependent of the default language...

__________________________________________

However, you have the option to have a dedicated Content Template for each language, and maybe it is that which you mean?
I'm aware of this option and we use it but this option is not working the way it should be.

This allows full power over the output in every single language and avoids tedious translation of strings.
What you would like or expect when using this option, is a completely different template (just like it would be in a single language website). The reality is it will strip the (wpml) strings and give a couple of translation fields.

When it was possible to have a complete page and decide for which language it is (just like a wpml post or wpml page) then you have full power over the output, in the way it's set up now I have only 'some power' over the strings.

When I should be the case that every language should have its own template, this is not working.

I made a image where you can see 2 scenario's:
- Top half: the way it works in our site - with option create content template for each language
- Bottom half the way a user would expect it, a true content template for each language

__________________________________________

If you have not set this option and instead have one CT for all languages, to be translated in WPML, and after changing the native blog language it's stuck on non-editable, then this is because the old default language may still be stored. I would here suggest contacting WPML support to solve this (in WPML > Support > Debug there are some buttons to actually solve this issues, which usually come from mis-assignments of translations and other, but it's best you ask WPML Specialists about this here

I think this is quite weird, the whole website is behaving as expected, except for the Toolset part. In what way should wpml help in that?
We do use the option 'create content template for each language'

Another thing is toolset build's their tool and wpml is used for translation.
When the toolset tools are not working as expected it's weird to contact wpml isn't it...

__________________________________________

I think it would be good to reconsider the way translations and templates work together. In the past it was possible to use different (full) templates for different languages. Some how it's changed to the way it works today but it's not a 'upgrade' in my opinion.

At least a extra possibility to point templates to a language would be enough...

Kind regards,

Paul

[Beda]

Well, this is mainly expected (referring to the Screenshot).
If you have a template each language as the option selected you will not translate Content Templates but create each language a Content Template.
It is correct that this will apply only to the content (post body) and not the entire template which is provided by the theme.
When you select the Content Template to be translated then yes, that's correct you will translate what is wrapped in the wpml shortcode for translation wpml-string only.

Now, this will not affect the problem you reported in either way as you are simply not able to edit the Content Template no matter what, I understand, after migration.

I believe, this is due to the Translation settings for it getting "confused" when you migrate, and change the language, and in the WordPress menu WPML > Support > Debug Information (where you can find the WPML debug info) there is a Troubleshooting Button which leads to a screen where you can fix exactly such issues.
But those features are relatively powerful and I would suggest seeking the assistance of WPML experts directly for this, I can if you want to ask a WPML expert to reply here directly with each features instruction and which could -if- potentially solve the issue.
I say this because you mentioned that you "use the option 'create content template for each language'".
This is since the begin, correct?
Hence, there is no reason why Toolset would block you to edit any of those templates as they would all be in "original language" for Toolset (since each template is covering one only language), no matter the WPML setting.

However, I think we can accelerate this and find a solution faster if you could eventually (since you migrated the site already repeatedly) send me the package of that migration?
I assume you used Duplicator or eventually some other software to migrate the site (or eventually manually).

I would like to try this locally so I can find the cause for you and you could then migrate the site avoiding the problem if I can find a good solution.

I will enable private fields for you to add the links to the Site's copy if possible.

You can also find here some information about how to create a copy of the original site (so I can install it locally to test a migration) or you can even create a copy of the migrated site which is broken so I can look at that as well.
https://toolset.com/faq/provide-supporters-copy-site/

[Beda]

The usage and translation of CT's (Content Templates) is elaborated here https://toolset.com/documentation/translating-sites-built-with-toolset/translating-content-templates-wordpress-archives-views-cred-forms/
The wpml-string shortcode is also explained well here https://toolset.com/documentation/translating-sites-built-with-toolset/wpml-string-shortcode/
It is clear that only what is inside the string shortcodes will be sent to translation, and Fields (which are shown by ShortCodes) are not to be set inside those as they are translated with the posts when you translate the posts.

So this is expected to not show Fields when you translate the CT's string shortcodes content.
When you have different templates for languages - still you do not translate any field. Fields are translated in the Post. Then, in the CT, you can add code that shows those fields - that is why usually - unless you need particular design each language or completely different content you will not use different templates each language but instead use wpml string shortcode to localize hardcoded strings in the templates.
Fields, post data, etc, is translated by WPML when translating the post.
You can refer to WPML's support to better understand how this mechanism works.

If you think that WPML causes this issue, then it should be reported at the WPML forum.

Now, the password seems incorrect - so tells me the login.
I need a copy of the site before migration

I will then deploy it, and as I understand all I need to do is change language from the default to any other already active on site.
Then I can see this happening and will be able to find the cause and solution for it.

I could also work with a copy of the database and wp-content FTP, I think, if a full copy is too large

[Beda]

Well, those CT are not made in English or Dutch.
They are in Czech.
Please head to WPML > Settings > Languages and see what I attached as screenshot here too.

If you activate those languages back, does it work then?
I see also you chose "Create different Content Templates for each language", so you would not translate them but for each language create a template.

Can you confirm that after reenabling Czech things work again?

[paulw-2]

Hi Beda,

Strange, when activating CZ, there is no template in that language (see image).
Checked the other 2 (link and pencil) bot none of them are editable.

I changed the language switcher on top op the page to check as well...
(I think it's annoying this language menu is not visible in the toolset section anyway).

I had a message from WordPress as well when I checked the templates in my email.
I will attach in underneath, seems something wrong with the WPML:

Error Details
=============
An error of type E_ERROR was caused in line 45 of the file /var/www/vhosts/creativematter.nl/httpdocs/projects/mynext2/wp-content/plugins/wpml-translation-management/classes/records/class-wpml-tm-icl-translations.php. Error message: Uncaught InvalidArgumentException: Unknown column: id_type_prefix or invalid id: a:2:{s:10:"element_id";N;s:11:"type_prefix";s:4:"post";} in /var/www/vhosts/creativematter.nl/httpdocs/projects/mynext2/wp-content/plugins/wpml-translation-management/classes/records/class-wpml-tm-icl-translations.php:45
Stack trace:
#0 /var/www/vhosts/creativematter.nl/httpdocs/projects/mynext2/wp-content/plugins/wpml-translation-management/classes/records/class-wpml-tm-records.php(138): WPML_TM_ICL_Translations->__construct(Object(WPML_TM_Records), Array, 'id_type_prefix')
#1 /var/www/vhosts/creativematter.nl/httpdocs/projects/mynext2/wp-content/plugins/wpml-translation-management/classes/class-wpml-translation-job-factory.php(72): WPML_TM_Records->icl_translations_by_element_id_and_type_prefix(NULL, 'post')
#2 /var/www/vhosts/creativematter.nl/httpdocs/projects/mynext2/wp-content/plugins/wpml-translation-management/classes/menu/translation-queue/class-wpml-translations-queue.php(569): WPML_Translation_Job_Factory->create_local

[paulw-2]

I dived deeper and there are weird things:

WPML
1. the list of CZ content templates: 5

TOOLSET
1. the list of templates in toolset - 5 different - the page opens in EN while the default language is CZ now...
pay attention: the CZ templates are empty (2)

Another thing is, there is a template named ' Loop item in team-content-template' which is impossible to remove.
I have searched for such a template but is (no longer) in the toolset views and content templates.
Its weird its impossible to Rome this.

[Beda]

I think, the WPML troubleshooting even fixed the last issue, as now hidden link works like a charm.

These other issues (error when translating, etc) (when related to translation) should be directed to WPML, they are specialized in Translation issues, while we are specialized in Toolset.
It seems though, I was able to adjust it despite that.

Please let me know.

[paulw-2]

Hi Beda,

Yes we can open the template but still not working as expected!
When I open the translation I have some fields of the template, not the whole template for which we started this exercise.

What I did to test is to remove all string translation shortcode from our template, but still I don't have a template per language

I tried to wrap the whole template in short code [wpml-string] CODE [/wpml-string] but still Toolset decides what is translatable even with the shortcode around all text...

TEST
I placed the default language to NL
I created a new template named 'Projects - 2019 - MNH - NL'
It won't show up but when settings EN back as default language this template is under default language EN.

I did the test again, same result...

These other issues (error when translating, etc) (when related to translation) should be directed to WPML, they are specialized in Translation issues, while we are specialized in Toolset.
It seems though, I was able to adjust it despite that.

I think we can conclude 2 things:
A. Toolset is ignores the default language, as described, when we create a new template under default language NL, its only visible when moving tWPML settings to default language EN
B. The option 'Create different Content Templates for each language' is not working, see screenshot!

I don't think these issues belong to the WPML helpdesk since they happen in your plugin...
They will guide me back to you guys.

I understand which tool to contact for requesting help, I don't ask for translation issues but problems with content templates which relate to translation...

[paulw-2]

It seems WPML and TOOLSET views are not working very nice together.

When having an option: "Create different Content Templates for each language" it would expect I would be able to edit a template per language, this is not true. It will trigger a workflow with WPML translation management.

Content Templates for each language
It would be much easier to have a content template per language.
It would give the option to serve a design per language en do some -in-the-content-template translations and for instance another form attached.

As I remember right it used to be that way.
This new strategy to send users over WPML translation management is not working for Toolset setup, especially because template files are difficult to translate for (external) translators...

Kind regards,

Paul

[Beda]

I understand what you mean.
To have this, a new feature would need to be implemented.
To have new features implemented you can ask and suggest them to our Product Management directly, using this form:
https://toolset.com/home/contact-us/suggest-a-new-feature-for-toolset/

I do not recall that this ever was like this, Content Templates always were either translated using wpml-string shortcodes (the recommended way) or translating the entire template, which is basically the same as creating a new one.
It's like translating a post in WPML. This also creates a new translated post and using Translation editor you will edit that as well in the Translation GUI, generally.

The setting allows exactly what it says, that you can have a content template each language. While otherwise, you will have the same template, and only translate its strings.

I understand the issue itself is resolved by the WPML troubleshooting steps after migration, then.
I suggest submitting the feature requests or ideas to the Form mentioned, then our Product Managers can take care of this and eventually schedule it for production.

However, the translation is the same as creating a new template, it's just the edit place that is different.

[Beda]

I saw you closed the ticket as solved.
I am reopening it, in case this is still an issue:
https://toolset.com/forums/topic/problem-content-template-translation-files/#post-1288733

You should not use WPML String ShortCode when having different templates each language.

When you have different templates each language you will translate the entire template according to this Information because you use a Page Builder on the Content Template:
https://wpml.org/documentation/translating-your-contents/page-builders/#translating-toolset-templates-designed-using-page-builders
This exact workflow cannot be changed in this situation.

1. If you use Page Builder to Build your Content Template you should not have different templates each language set in Toolset > Settings but should instead have one Template and then in WPML set that Content Template Post Type to translatable.
2. To enable the translation of a specific Content Template to go to the WPML -> Translation Management page and on Multilingual Content Setup tab find the Post Types Translation section. Here, mark your Content Template as translatable.
This is also where you would turn off such translations.
3. Important, if you have previously selected to use a different Content template for each language (which is the case) you can not use this workflow. Instead, you have to use your page builder to individually add content to each language’s Content template.

This means, if you want to keep the CT "one each language", you must disable the CT from translation in WPML.
Then, you build each language a CT.

So what I would recommend here, in this case, is remove translation of WPML for this Post Type (Content Template).
Then, edit each template in each language with the Builder you use.

[paulw-2]

Hi Beda,

Thanks for your 2 replies. Really appreciated.

You should not use WPML String ShortCode when having different templates each language.
I tried that, but it still feeds the different translation fields in the translation content template

1. If you use Page Builder to Build your Content Template you should not have different templates each language set in Toolset > Settings but should instead have one Template and then in WPML set that Content Template Post Type to translatable.
We use the code of a Visual composer page, but don't build it with the toolset VC possibility

2. To enable the translation of a specific Content Template to go to the WPML -> Translation Management page and on Multilingual Content Setup tab find the Post Types Translation section. Here, mark your Content Template as translatable.
We noticed translation management was creating a to complex workflow, we deactivated it.

3. Important, if you have previously selected to use a different Content template for each language (which is the case) you can not use this workflow. Instead, you have to use your page builder to individually add content to each language’s Content template.
You would expect to use the pencil next to the filename and have a complete editor page instead of the couple of selected translatable fields with this option. T

Underneath we described our workaround. We used one wpml shortcode all around the whole code which works almost fine.
In my opinion, this is something which should be possible to automate by toolset, when somebody decides to 'create a CT per language'

This means, if you want to keep the CT "one each language", you must disable the CT from translation in WPML. Then, you build each language a CT.
Should I do that with translation managent? (we deactivated it)

_____________

OUR WORKAROUND:
I cleaned out the complete string database yesterday and removed all strings of old posts, languages, etc.

After that I tried to place my whole content template's design inside one string translation shortcode which seems to work.
In this workflow you cannot see the code in a editor screen inside the WPML string translation tool, but it works...

Because the default language of my content template was in English, I decided to create a second test.

I followed the next steps:
- Default language in WPML placed to NL
- Created the test template with WPML string shortcode
- Went to WPM string translation to place the EN test translation

PROBLEM
I noticed the new template was created with default language EN (while it should be NL) .
I think somehow Toolset still sees the website as one with default language EN while it's not.

If you like you can have a login so you can see for yourself.

[Beda]

1. I tried that, but it still feeds the different translation fields in the translation content template

I do not understand what you mean by this.
Does the translation still apply, that you made before, for the wpml strings? That is not a Toolset issue, please report such issues to WPML, as they will be able to tell you how to delete, restore or create translations of any content.
It sounds like your translation is still there, in WPML, and hence, still applies as the strings are still registered.
Toolset, however, cannot control that, it's done in the WPML Plugin.

All you could do is to remove the WPML String ShortCodes entirely from the CT's and then delete the translations, in WPML, for assistance on that however you'll need to ask WPML Support.

I also do am not sure to understand what you mean by "fields" here.
Fields are not to be wrapped in WPML String ShortCodes or translated in any other way than when editing the POST itself.
You will never translate Custom Post Fields in String Translation as a WPML String.
This because in Content Templates those Fields are shown with ShortCodes and those should not be translated, obviously, but their content (which belongs to the post) should.
This is done, and can only be done when you use WPML's translation as when you translate posts. It is unrelated to whether you have CT's or not, as the field, can be shown wherever with a ShortCode, and that ShortCode automatically displays the right language details depending on where you view it.

So, if a Field is attached to a post and that post is translated and that field with it, then it will display as translated on any translated post in the front end no matter if inserted in a Layout, a CT or a Visual Composer template.

2. We use the code of a Visual composer page, but don't build it with the toolset VC possibility

You cannot (well, maybe you can, but you are not supposed to) create content in a Post A and copy that to Post B
I assume, Visual Composer will add a lot (!) of stuff behind the scenes that are not solely within the ShortCodes produced by the Builder, and the whole purpose of the builder is to build posts with a user friendly dnd interface, hence, copy-paste was not in the mind of the developers, I assume.
If it works, it is still something related to what content is build with what code, and it is a page builder content - whether copy-pasted or not.
WPML's instruction talks about when building the Template with the Builder. I am almost sure, it makes no difference whether you actively build or copy paste a build, however, that question can only be answered by a WPML expert as it relates to "how to translate copy-pasted Page Builder Content". I assume it is the same process as when "building" with it.

Please clarify this with your preferred WPML Supporter, because I cannot give a certain answer on translation issues of this kind.

3. We noticed translation management was creating a too complex workflow, we deactivated it.

You cannot translate Page Builder Contents without Translation Management.
That is a WPML condition.

If you think it should be possible, I can only direct you to WPML's support. I cannot change how this is supposed to work, unfortunately:
- To translate Page Builder Content you need translation management.
- Please consult the DOC here, which I shared before, it states it on the top of the DOC:
https://wpml.org/documentation/translating-your-contents/page-builders/

The issue summarized in this Ticket, however, is not directly related to whether the Translation Management is lean or not. Please direct this kind of concerns to WPML, because I cannot influence this.
It is better you mention that to the Supporters at WPML which will eventually even be able to present leaner methods of translation.

4. Underneath we described our workaround. We used one wpml shortcode all around the whole code which works almost fine. In my opinion, this is something which should be possible to automate by toolset, when somebody decides to 'create a CT per language'

We cannot automate and detect if you copy-paste Page Builder Content in the CT; then accordingly decide whether to translate strings (strings, not ShortCodes!) or to let the user edit the template as a standalone (not translated) in each language.
This would require a (very) expensive scan of the content, checking what is a shortcode and what is not, and then also check of what kind the code is - whether page's builder or not.

In your case, it seems you would be perfectly fine using an own CT each language.

That should work fine, once you remove all WPML strings in the templates, do not translate the page's builder content added to CT's with WPML translation and create one language each a Content Template by clicking the Plus.
This is also elaborated here:
https://toolset.com/documentation/translating-sites-built-with-toolset/translating-content-templates-wordpress-archives-views-cred-forms/#creating-different-content-templates-for-different-languages
You need https://wpml.org/documentation/translating-your-contents/ for this.

Please let me know if anything remains unclear related to Toolset.

If necessary I recommend adding a few screenshots of what you see and think must change, if you feel I do not understand the point.