[Resolved] JetEngine Custom post type meta fields

Hi Nick

What are you using for the custom fields? I see you have ACF installed.

This field in question, it's a select dropdown or similar type of field?

It sounds like you want the stored values of the field to be the same across languages (e.g. "expected", or it could be a number, e.g. 1 = "expected", 2 = "for-sale" etc.), and you simply want to translate the labels.

So set the custom field to Copy (changes made to the field in the default language will be reproduced in the secondary languages), but translate the labels.

If you are using ACF, check this link about what's required for translating labels of select fields etc.: https://wpml.org/documentation/related-projects/translate-sites-built-with-acf/translating-acf-field-labels-and-labels-for-choices-with-wpml/

Hi Nick

OK, so it sounds like your problem is the default characterisation of the strings as English, when they should be Dutch.

Please check this documentation for how to handle that: https://wpml.org/documentation/getting-started-guide/string-translation/how-to-change-the-source-language-of-strings/

As for your side question, about how to "get rid of the fields that are no longer existing", that's not something WPML can help with.

You see those custom fields in the WPML settings, because WPML detects those custom fields (the meta_key's) in the wp_postmeta table.

At some point you have created posts with values for such fields, and have later removed the settings for the custom fields, but the data itself is still stored in wp_postmeta.

If the posts to which those custom fields belonged no longer exist, you could use a database clean-up plugin, which could identify orphan entries in wp_postmeta (custom fields that didn't belong to an existing post) and remove them.

But if the posts still exist, and it's just that you no longer need the custom field entries, that would require a more manual intervention. You would basically need to make a list of all of the custom fields you wanted to remove from your site, and then either write a PHP script to delete them, or a SQL query that you could apply directly, using something like phpMyAdmin.

I haven't used Jet for creating custom fields, so I'm not sure about the best way to identify the label strings for translation, I'd need to try it and see.

If I create a sandbox site that you have admin access to, would you be able to add the relevant Jet plugin and set up a simple demo with the select custom fields registered for some post type that have the labels which need translating?

Otherwise you could provide a staging version of your site that you were happy for me to run tests on.

Let me know if either of these suits, and I'll provide what's needed.

Hi Nick

Thanks for that.

I've had a nosey around to see how JetEngine works here.

I see the custom field Voorraadstatus is registered along with the autos post type, that it is a select field where the options come from a Glossary (of the same name).

When I search in String Translation I find the texts from the glossary available for transation, and they seem to be correctly recognised as Dutch, with available translations (e.g. screenshot).

In WPML > Settings > Custom field translation the custom field ("status") is set to Copy.

So far so good, it seems.

I expect that you would make a change to a post in the default (Dutch) language, updating the value of the custom field, and on the other language versions of the post the field value should be updated to match (thanks to the Copy setting).

(The one thing I would change in your setup is to change the field values for the glossary items to be something not language-specific. Currently the values are the same as the labels. Even when you translate the labels, each language version of the post would share the same custom field value, e.g. "Te koop". You might want something like numbers, where Te koop = 1, Gereserveerd = 2, or letter codes, or similar.)

So, now that I've understood the set up, can you provide me with some steps to actually see the problem you have?

I tried that and switching the page to English it showed the field value as "TestjeMetaboxVeld", which was unexpected.

Looking again, it seems Jet has two ways of adding custom fields to custom post types, and it looks like you are using both, and I don't know which is intended, if you can please review how you have this set up and clarify.

In the settings for the autos post type (at JetEngine > Post types) you have a status field (label "Voorraadstatus") which is a select field whose values come from the Voorraadstatus glossary.

But at JetEngine > Meta Boxes you also have a Voorraadstatus metabox set up with a Voorraadstatus auto field whose values are manually added, rather than coming from the Voorraadstatus glossary.

So there seems to be quite a lot of overlap here and I'm not sure which field we are supposed to be working with. I expect it should be one or the other rather than both, but you will know JetEngine better than me, if you could please clarify.

This duplication together with re-using the same texts for field values and labels makes it difficult to see what strings are being translated on your site.

So I went ahead and set up a sandbox site with a simple demo to check and illustrate how to translate such strings.

You can access it here: hidden link

I used JetEngine to register a glossary ("Stages") that includes 5 options, e.g. "First" (value = 1), "Second" (value = 2) etc.

I then registered a custom post type ("Things") and added a meta field thing-stage to it, whose options come from the glossary.

In WPML > Settings I set the thing post type as translatable, and I set the thing-stage custom field to Copy.

I created a few sample Thing posts, with values chosen for the stage field, and then translated the posts.

I verified that the translated posts have the value of the thing-stage field copied across. (I enabled the default WordPress custom field UI so that it is easy to see when editing a post the stored value for the field; if I edit the EN version of the post and then use the language switcher to change to NL or ES I can see field value.)

I made a change to the selected option for one of the posts (I edited "Something" and changed the option from First to Third) and then verified that the value for the translations of the post changed, which it did. That's one of your requirements fulfilled.

As for translating the labels, I was able to find the texts to translate using String Translation, with mixed results. It works, but there is a problem, which makes it confusing.

(On your site it is particularly confusing because, as I mentioned before, you use the same texts in different places, e.g. for the labels and the values, in glossaries and meta boxes, so it is hard to tell what text you are translating.)

On my sandbox, the default is EN and I have translations to NL and ES.

I translated the labels First, Second, Third, Fourth, Last to NL and ES.

First, the good news is that works. I was only able to verify in the back end (I don't know how you output the JetEngine field labels on the front end; I tried generating a jet shortcode which you can see I added to the post bodies, but it only outputs the stored value not the label). If you edit one of the translations of the posts, you will see the options in the dropdown are shown translated rather than in the original EN from the glossary.

Next, the bad news relates to what you were initially describing, I think. You will see that String Translation has identified the translated texts as new texts as if they were English.

You should be able to understand what I mean from the screenshot.

I need to create an internal ticket to escalate this to our compatibility team, but in the meantime you can hopefully understand that it is possible to get this working, but one thing you should do is update the texts you use in various places to use unique texts so that you can be clear what it is you are translating.