[Closed] BUG: String Translation and Types Custom Fields

[Author]

Posts

[ellesd]

Guys I found a serious problem with Types latest version and WPML slug translation. Slug translation is in the "WordPress" context and whey I use my render fields with raw is true it translate my string! I tried everything, also the options in the custom field checkbox was set on "do nothing". I solved my problem to use the normal WP function for custom fields. I have added another serious issue of Types and String translation on the WPML forum yesterday.

[Yvette Oliveau Supporter Languages: English (English ) Spanish (Español ) French (Français ) Timezone: Pacific/Niue (GMT-11:00)]

Hello.
I understand that you are encountering issues between the WPML and the TYPES plugins.

Concretely, you have found that custom fields strings (labels or values) created with Types are being returned translated by WPML when using the call to [types_render_field].

The expected behavior when using the “raw” output attribute is that the returned value is in the original created language (e.g. the value stored in the database).

(0) Clarifications.
0.1 Can you please confirm that I have understood the problem correctly?
(1) Technical Information on you environment
1.1 Could you please provide information about your environment by following thsese steps: https://toolset.com/faq/provide-debug-information-faster-support/
(2) Temporary access to your system
Could you please provide access to your system (wp-admin and ftp) so that I can further investigate this particular problem? The fields to provide this data are included in a private section that I will open for your next response. You can find it above the comments area. The information in this private section is only visible between WPML Support and you.

(3) Test Case
Would you please provide instructions on how to recreate this problem in your system? As much detailed information that you can provide can allow me to work faster. If you could include screenshots this would be helpful as well.

(4) Next Steps
I understand that you currently have a workaround for this problem. Nevertheless we would want to address this issue as quickly as possible. With your assistance, I will first confirm the bug then recreate it, if possible, on my own test system.
As soon as these steps are completed, I will be able to escalate this issue to our 2nd level support if necessary.

Thanks for your collaboration on this process!

[Yvette Oliveau Supporter Languages: English (English ) Spanish (Español ) French (Français ) Timezone: Pacific/Niue (GMT-11:00)]

Hello,
I appreciate the screenshots and details – this has helped a lot.

Observations and Clarifications:
1. I see that you have implemented a workaround with get_ post-meta() for the variable $listType only. Does this mean the other custom fields are behaving as expected and the only field that is causing problems is of type “select field (conditional)”?

2. What language was this field created in? I can see that your system default language is Dutch. Was the custom field created in Dutch or English?

3. Can you confirm that when you deactivate WPML, the “raw” attribute is returned in the language you are expecting? (i.e. the language in which the field was created).

4. Can you confirm that this was behaving normally at any point in the past?

Other notes.

A) I think the underlying question is to understand if it is expected behavior to translate database contents with the “raw” attribute when WPML is active. I will need to consult our development team on this matter but I would want to first understand clearly the parameters of your case.

B) I am sorry to hear that the recent upgrades caused general havoc in your installation! I hope you will have the patience to work with us through these various issues. I will also give feedback to our development team on the need to improve integration testing in the future.

Moving forward, I understand that there are 3 outstanding issues that you need help with.

B1. Raw input for fields being translated – how to turn it off….
B2. Broken permalinks when not using parameter options
B3. Exporting/Importing Types Fields

I need to kindly ask you to open separate threads for each of these concerns so that we can direct the problem to the correct resource internally and to also allow other clients to benefit from the forum threads by only addressing one problem per thread.

I look forward to receiving your responses to my questions. Thank you!

[ellesd]

1.
Other fields may will cause problems, but this field has values who are also used as slug. When I removed the slug context "WordPress" from String Translations, than it was acting normal without translation. I used this field to show the content of the Custom Post Type in a list so thats why the slug is the same as the field value.
2. Theme and Types has default English language and I use po. files to create the Dutch translation.

3. See my answer at 1. After removing WordPress context at string translation it works as it should be.

4. Before the last update of WPML, Types and String Translation this worked normal. I am working with this WP network sites allready for 1 year and this has been triggered after the last updates.

No problem to help you guys. If you mention my name to Amir, maybe it rings a bell because I helped him a lot when Types was just beta testing 😉

[Yvette Oliveau Supporter Languages: English (English ) Spanish (Español ) French (Français ) Timezone: Pacific/Niue (GMT-11:00)]

Hello,

I was exploring your site in more detail in order to recreate the problem in my own system. Here is my understanding of your situation :

Setup:
==========================================================
CPT 1 : “Block”
Includes custom field: “select-list-type” (conditional)
One of the created “options” for this field type is string: “Employee”.

CPT 2 : “Employee”
The slug for this translatable CPT is “Employee” and is translated via Strings Translation under context WordPress URL slug.

Scenario:
===========================================================
In page the “About-Us” / “Over-Ons” you had, at some point, included a display of this custom field with attribute “raw”.

As per your screenshot of this page, you had content displaying in Dutch. But you expected the content of the Custom Field label to be displayed in English.

I checked your site configuration – here are my observations/questions:
============================================================
1. You currently have the setting “Localisation themes/plugins” to be using only .mo files. Is this intentional? Can I set this back to using WPML?

2. I no longer see the integration of this field on the front-end of the “about-us” page. Has this been removed? Would it be possible to put it back so that we can observe the problem directly and make sure I have recreated the case correctly?

3. I also notice that your strings table includes completed translations for the custom-field option “Employee” (see image). I had thought that the only existing translation for this string was under the context of WordPress URL slug.

4. I noticed that you do not have Translation Management active. It is active on my test system, and as such, within the settings for Multilingual Content Setup, I have the option to “Convert URLs to point to translated content in Views and Content Templates”. It is “ticked” by default.

It might be worthwhile to activate Translation Management to see if your integration with Types/Views and WPML is better

Thanks for your confirmation and clarifications.

[ellesd]

1. We also use .mo/.po files for translation the forms. The main language of theme and forms is English and we translate this without using WPML

2. Sorry my collegue put an extreme aggressive caching plugin. I removed it, so now you can see what happens. I showed both ways of getting the field with a php echo so you can see the difference. Types field was translated and the normal WP field stayes untouched.

3. The string is under the context of WordPress slug. When I remove that one, translation is okay. The context you refer to is not the value but the string itself. This one does not harm the value...I allready checked that. if you change the WordPress context is something else you can also see the text changing on the about us page. See the screenshots.

4. I only use this plugin to copy the content. Afterwards I deactivate it because I don't need it for the use.

[Yvette Oliveau Supporter Languages: English (English ) Spanish (Español ) French (Français ) Timezone: Pacific/Niue (GMT-11:00)]

Hello.

Thank you for your response and the inclusion of screenshots that clearly illustrate the problem you are experiencing.

I am now able to escalate this ticket but would ask that you please provide one “permanent” example of the issue at hand in your system so 2nd level support can test and verify for themselves.

You may do this by making a duplicate of the “About-us” page and modifying the corresponding template file with the php calls to the “types_render_field” as you did in your example. Please include the name of this page in your response so I can point the developers to the correct case study.

Can you confirm that you will do this?

I have summarized the problematic integration points as follows:
=========================================================
1. Consultation of Strings Table

Backgound info - WPML Architecture:
The configuration setting “WPML > Theme & Plugin Localisation > Select how to localize theme “ set to “Translate using .mo files” should deactivate the consultation of the Strings Table for any strings found in theme/plugin template files.

Integration problem
Observed Behaviour:
It appears that the php call “types_render_field” within a themes template does not respect the WPML configuration setting.
1.1 The custom field value is being “translated” with matching content of the Strings Table
1.2 The “context” used for the translation is incorrect. In this case, the context being used for the lookup is “Wordpress – URL Slug” when it should be the active theme or plugin.

Expected Behaviour
No consultation of the Strings Table and only a direct read of the database.

=============================================================
2. Precedence of WPML and Toolset Types and Views Filters

Backgound info - WPML Architecture:
The source language of strings in the Strings Table is always English. The default language of a system can be non-English. When a non-English installation displays a page, the theme will use the active display language to retrieve the translated version of the string from the Strings Table. The behavior invokes WordPress filters to ensure that all content is displayed in a consistent language.

Integration Question:
2.1 What is the intended value of a TYPES custom field when the attribute “raw” is applied to a non-English default language installation? The documentation states that the “raw” attribute returns unformatted database content. Does this content bypass language filters imposed by WPML?

Concretely what is the intended behavior for the following cases:
a) Default language is non-English
b) Custom field (cf1) included in a non-translatable CPT created in English
c) WPML configuration localization setting = “use .mo archives”
d) A PHP call to types_render_field with attribute “raw” is included in theme template file.

Case 1: The display language is default non-English language
Case 2: The display language is secondary English language

Please let me know if you do not agree with the description of the integration problems contained in this thread. And also please confirm the example page that contains a “persistent” illustration of your problem.

Thanks again for your patience as we work to get to the kernel of the problem and more importantly find a solid answer.

[Yvette Oliveau Supporter Languages: English (English ) Spanish (Español ) French (Français ) Timezone: Pacific/Niue (GMT-11:00)]

This has now been escalated - we are still awaiting your details on how to access a more persistent example for testing on your system.

I will add this detail to the escalated ticket once you provide it.

Thanks again for your collaboration.

[ellesd]

Unfortunately I can't only create this for one page, but I just turned it on for my staging environment. I created a php echo with 3 outputs. One with types output raw set on true, one set on false and the basic WordPress get meta. Hope this will be enough to test with. Cause I did this for my whole network installation, you can also see the changes on this page: hidden link
This is multi language with Dutch and French. You can also see there 2 different list types. And in French it's translated into this language as you can see: hidden link
I added this site also to your admin account so you can test in 2 websites if you want. Hope this can help the team, but don't hesitate to contact me.

[Yvette Oliveau Supporter Languages: English (English ) Spanish (Español ) French (Français ) Timezone: Pacific/Niue (GMT-11:00)]

Thanks again - I have included all the information in the ticket.

This thread is now being placed on status "Escalated to 2nd tier". I expect someone to contact you shortly with more questions or answers!

Thanks again for your ongoing support in this process.

[Caridad]

I'm discussing your problem with a Types developer and I will get back to you shortly with a reply.

Regards
Caridad

[Caridad]

I can't reproduce your problem on my testing site.

Can you provide a duplicator package of your site to debug this locally?

https://wordpress.org/plugins/duplicator/

Can you install duplicator plugin and I create the package myself.
I dont have permissions to install plugins at the moment.

Thanks
Caridad

[ellesd]

Thats because its a network installation. I gave access to one website but I can't give you the complete website install cause it's more than one website.

[Caridad]

I need to replicate the problem on a server that I have full access to.
This is to allow debugging and find out the root cause of your problem.

At this point, I can create a test server for you and send you the details.
Once we have the problem replicated on our servers I can continue working on this.

Does this solution suit you? Let me know and I will send you access details.

Thanks
Caridad

[ellesd]

I am sorry, I am not allowed to give you access to our environment. I am using WP custom fields to fix this problem so for me that works. I did everything to help, but can't do what you ask.