Background of the issue:
1. We use ACF Pro extensively, plus custom post types. Most of those are passing through the translation system.
2. We also use ACF Pro for custom options pages, created via “acf_add_options_page” in functions.php and set up in the plugin interface. Those are not being translated (near as we can tell), although in the
Edit Field Group” UI they’re set to “Same fields across languages”.
3. In the WordPress admin Japanese pages, the custom options pages are showing blank entries. (Translated posts/pages are appearing in their relevant lists.)
4. In the page code itself, a given ACF options set is fetched with "get_field('vantiq_megamenu2024_section', 'options’)”. These commands return no data in Japanese.
5. It’s not clear that the ACF fields are being submitted for translation, and if they are, where the Japanese results go. Ideally it would work just like the ACF “get_field” command for individual posts/pages, but if there’s a logic to where translated versions of (for example) “vantiq_megamenu2024_section” and its subfields end up in the database, I can work with that if simpler solutions aren’t available.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+01:00)
Hello!
I'll try to answer all the points you added there and then we can focus on one at a time if you still have doubts:
1) Ok, so you're translating them via the ACF GUI, correct? (if it's via the php/json embedded way, then it's just a matter of knowing how you're setting them up)
2) Options pages can't be translated via our translation editor since they are different. having the option "same fields across pages" might not be the best way to go here, it's one of the only exceptions. it's not bad nor will it create issues, but i think that at most the copied content will be passed, apart from that you'd have to translate them manually. the labels can be translated via Translation Management, though.
3) Yes, this is expected for options, because they do not behave like pages or standard post types. they are somewhat individually translated. This is a bit of a limitation based on how an options page behaves and how it's structured.
4) Even if you have translated the content manually in the options page? even then it doesn't return anything? because that's quite odd.
5) May i know the workflow you use to translate this content? because it seems your issue is specific to ACF coming from OPTIONS pages, not really from pages or blocks. is that correct?
We have a number of WordPress “archive” pages, such as this for blog posts:
hidden link
But the Japanese version shoots blanks:
hidden link
The template’s there, but no content.
In WordPress settings for Japanese, it appears to be selecting the right “posts” page:
And we know that blog posts themselves are being translated:
hidden link
The posts archive page itself is coded conventionally, presuming WordPress has already selected posts for display. It includes options for authors and categories, and uses “the_posts_pagination” to display page numbers.
So: How to get it displaying Japanese posts? And if needed, are there extra tricks to manage authors/topics and pagination?
(Also, I notice that archive pages for “custom post types” don’t have Japanese versions at all, at least not indicated in the footer language switcher. Is there a special setting or page code for those?
Related: We have other landing pages that use “get_posts” and similar calls direct to the WordPress database, like so…
Is there a setting we should include (where relevant) to gather Japanese posts only? We already have code mechanics to determine which language is being displayed, so it’s just a matter of knowing whether the request should have an alternate structure where needed.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+01:00)
Would it be possible to have access to a staging site with this problem and also if you can tell me in which files are you calling these fields? this way i can look at it and try to understand what happens, these issues are usually cofiguration issues but they are not always super straightforward (they greatly depend on so many things, starting from the way the ACF is even created to how it's coded later on).
I'd like to give it a look so we avoid too much back and forth. I've enabled the credential fields if you're ok with this.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+01:00)
Hi there!
You can create a fake mail, preferably and create a user and pass and send it to me via the credential fields.
1) If the problem comes from the archives then please:
- Go to WPML > Settings > Custom post types translations
- Make sure the slugs for each post type is set for all the languages and they are different from other languages.
I think that's the issue because of the example you provided: hidden link hidden link
This tells me that the slug is not translated and that might be the root of the problem or at least part of it. try it out and let me know how it goes 😀
ALejandro, were you able to answer the question? Is that something WPML Does?
Another question we have is can the original publish date be preserved when translating and publishing Blogs and News releases? When we go to publish our newly translated Japanese Blogs, they get published in a randomized order. Not in the order that they should be chronologically. How do we fix this?
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+01:00)
Hi there, the issue with the permalink hook from WPML and the archive could be caused because the CPT Slug hasn't been translated. please translate it and try again and see if that works, that might be the missing step, as i mentioned on my last reply.
Try that first and let me know how it goes.
----------
About the original published date on the translations. It can but I'm verifying with another case if by any chance it's not working at the moment. I'll be able to give you more info about this tomorrow. Let's continue with the first issue, in the meantime.
Another issue: Sometimes, we go into a page and go to update the copy from English to Japanese. When we click update, the page jumps back to english and won't translate the parts we want, leaving it in english. WHy? This is an acf pro field, and it is not saving any changes, English or Japanese.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+01:00)
I suspect that you're not reading my replies because you're replying almost after i reply to you!
Can you check my last 2 replies and let me know, please? this way i can better understand what to do next.
Let's focus on a problem at a time to avoid confusing the thread. i'll take note of this last question and answer it as soon as I have confirmation that the other issue is fixed.
My bad. Thank you for all your help! I think I got the CPT Slug translated correctly, but I would like some help with the other ones. Particularly the original publishing dates. Will you enable the box that enables me to give you access again?
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+01:00)
Done, you should be able to add them now. please send me a reference post.
By the way I checked on our other issue about this and the feature WAS working correctly, however the problem was that the translated content was a always a draft and when you published it, the publish date would get overwritten. this is expected, so if that's the case with you, then that could be the problem as well.
in that case, you can run this query to sync them:
UPDATE wp_posts p
JOIN wp_icl_translations t1 ON p.ID = t1.element_id
JOIN (
SELECT t.trid, p.post_date
FROM wp_icl_translations t
JOIN wp_posts p ON t.element_id = p.ID
WHERE t.source_language_code IS NULL
AND t.element_type = 'post_post'
) AS source_posts ON t1.trid = source_posts.trid
SET p.post_date = source_posts.post_date
WHERE t1.element_type = 'post_post'
AND t1.source_language_code IS NOT NULL;
Can you let me know your workflow and if the posts indeed get first saved as a draft and published later?
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+01:00)
Hello, this is what i see: hidden link
It's not completely translated and opening in the Classic Translation Editor. however I don't see things they way you do, can you check the video and let me know if by any chance I'm doing something wrong or differently from what you do?
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+01:00)
Well, the main question here is:
Did you translate the content using the classic translation editor or the advanced? so the problem is that a lot of the translations are missing here?
If so, the next step would be to see if there's a revision or something that can show us if there were edits to that content that could've created this problem or at least try to understand when did these strings go missing so we can check what to do next.
I used the classic. I tried to flip it to advance but nothing changed in my UI. I don't know how to do reversion or check when they went missing. Is there a way You can just change it for just that specific text so that I can edit it. It isnt a problem anywhere else on the site for the most part
This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.
