I need your help. I have a website that we translate with automatic and manual translators in 8 languages. The main language is in Bulgarian / Cyrillic alphabet, and we didn’t have problems so far for over two years. The urls were written In Bulgarian and translated into other languages:
A month ago all new or updated url’s started showing as Unicode:
This is really bad because translators cannot use the automatic translation, neither can read what the url says. Further, I cannot make any change to a product, not even adding a photo, because when translation is updated to show the photo in other language, even already translated URL’s are wiped out and need translation from Unicode. Urls are indexed and any change would result in search engine positions loss that we already have.
I checked the other options in the “translated document options”, but we want to translate the urls from the main language.
Can you please let me have access to your site and give an example of one page that I can check to see this problem?
Meanwhile, I'm also consulting our second-tier supporters about this issue.
If you need further help with this, please share the access details to your site with me.
I'm enabling a private message for the following reply.
Privacy and Security Policy
We have strict policies regarding privacy and access to your information. Please see: https://wpml.org/purchase/support-policy/privacy-and-security-when-providing-debug-information-for-support/ **IMPORTANT**
- - Please backup the site files and database before providing us access. --
-- If you have a staging site where the problem can be reproduced, it is better to share access to the staging site.--
Our second-tier supporter asks for the job ID for the translations you show in your screenshots. You can look up the jobs ID when you go to WPML -> Translation Management -> Jobs.
In addition, I'm still waiting for access to your site.
In WPML -> Settings -> Translated documents options -> Page URL, you have the option "Translate (this will include the slug in the translation and not create it automatically from the title)" selected. Please see the attached screenshot. This makes the slug appear in the Advanced Translation Editor for translation. The default option is "Auto-generate from title (default)". You wrote: "A month ago all new or updated url’s started showing as Unicode...".
Could it be that you changed this option a month ago, and this is when the problem started?
I'm asking this because our second-tier supporters tell me that it always has been like this. Cyrillic URLs are always shown this way in the Advanced Translation Editor. The option "Auto-generate from title (default)" lets you or your translators only translate the title of the product, post, or page. The product, post, or page slug will be translated according to the title.
We need to isolate this issue and determine if this issue is coming from WPML or its Advanced Translation Editor. If you are certain that it was different before while the option "Translate (this will include the slug in the translation and not create it automatically from the title)" was selected, please let us know where we can see this problem on a 100% complete translation that has not been updated.
Do you have such an example product that we can look at?
Otherwise, you can simply switch back to the option "Auto-generate from title (default)".
I have always used translate before, about a year and a half, I am sure it was always written in bulgarian words not unicode, and here are some examples, but you can see yourself going to products/page2 and any product after the fifth that hasn't been updated in the last month has the url right:
ID: 59271 , ID: 59143, ID: 59088 and 200 more, and if you update any of the products in the main language, the url will change to unicode and on the other side will be wiped out/blank, but please don't do it, make it on a new product.
ABout generating from title, I know this option and I have tried it, but it's not best for SEO, and I prefer translating, In some languages titles are too long for slugs. When I choose it it wouldn''t even be a line for slug translation in the ATE as the examples above and the screenshots.
Thank you for helping!
We want to take a copy of your site to investigate this issue further.
Do you allow us to install a plugin like Duplicator or All In One Migration and take a copy of your site to investigate the issue on our servers further?
Hello, no problem, as long as the main store is not affected because there are decent amount of orders every day and clients are very angry when something breaks. You can make a copy, I also have a full backup from few days.. how should we proceed?
I installed the Duplicator Pro plugin on your site and created a copy of it. Then I deactivated and removed the Duplicator Pro plugin. I'm going to escalate this issue to our second-tier supporters. I'll keep you update here on any news regarding this issue.
I hope they will find the problem, I need to add size charts to all products, but I can't now. I would delete all translated urls. Thank you for your help, Itamar.
Our second-tier supporter has meticulously checked this issue. Here are his findings.
I checked the database locally of the imported dump.
I can see that the products with IDs "59271, 59143, 59088" (the products you gave as an example) are the original products that were translated into the other languages.
If you do a query:
SELECT `ID`, `post_name` FROM `wpln_posts` WHERE `ID` IN (59271,59143,59088)
It is possible to notice that the post name is encoded. Please see the attached screenshot post_name.png. So, it is supposed to behave that way, which means that the Bulgarian Cyrillic URLs will be encoded. Something else is responsible for those slugs, as shown in the screenshot from the client. We don't know what is responsible for this, but it is not the slug of post/product.
WordPress has been putting the URL encoded slugs forever because this is the Bulgarian language... all of their products are like that. The issue is only with translating those, but if you let it generate from the title, it will be fine.
We just get the data that is passed to us, and we are not showing it pretty. I also created a new product - "Тест" locally - and the post_name in the posts table is "%d1%82%d0%b5%d1%81%d1%82" - this is with only WordPress and WooCommerce plugins (without WPML and WCML)- so essentially how it WordPress works and not our bug.
The user recently selected to translate the slug - this is why he sees those values like that. He enabled it on 2023-12-15, as the first job is from that date. We can tell that because there appear to be entries in their icl_translate table.
A possible fix is to go to "Auto generate from title" in that setting, complete it, and re-send it to translation.
So, to summarize this issue:
1. WordPress and WooCommerce always used encoded URLs for Cyrillic characters.
2. The encoded URLs are the expected behavior. You probably started to see them since you changed the settings in WPML -> Settings -> Translated documents options -> Page URL from "Auto generate from the title" to "Translate (this will include the slug in the translation and not create it automatically from the title)."
3. A possible fix would be to complete any in-progress/need-update translations. Set the option back to "Auto generate from the title" and re-send those products to translation. Then, you can continue with adding size charts to all products and updating the translations.
I also noticed that you are using the Rank Math SEO plugin, but our bridge plugin, WPML SEO, is inactive on your site. When working with WPML and the Rank Math SEO plugin, it is a must to also install and activate the WPML SEO plugin. Please read our guide about working with the Rank Math plugin.
Hello, thank you for your help again and sorry for late answer, I was out of the city.
This is true:
The user recently selected to translate the slug - this is why he sees those values like that. He enabled it on 2023-12-15, as the first job is from that date. We can tell that because there appear to be entries in their icl_translate table.
The truth is that since I have installed the plugin, I don't know what option was chosen by default, but the url was always there for translation in the ATE and no unicode was seen for over a year. Suddenly, probably after update, I noticed that the url is missing from the ATE and then I started reading your forums how to change back. When I went to the options it was to "Auto generate from title", but I never set this, so I wanted it back as before and I switched to "Translate", and it started showing as unicode.
Please tell me what is the standard option after installation of WPML?
I don't want to translate from title because of SEO purposes.
"When working with WPML and the Rank Math SEO plugin, it is a must to also install and activate the WPML SEO plugin" I didn't know this, but now I am afraid if it would do any mess with the already SEO optimized pages? Do you have other casses like this and is it safe to add it late like me?
I also have another thing in ATE that bothers me. When I make any change to a line, even a typing mistake, the whole tranlation gets deleted in ATE. I know there is an option to not update translation, but sometimes I need to update it because of something else, as changinf photo. Also in this case with the unicoded url, If i update translation for any reason, the translated urls will be wiped out. Is there any way to keep the old tranlations in the ATE, it will be a lot easier to confirm them or make changes to an already tranlated sentance than to start all over again.
Thank you.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
1) About the encoded option. can you go to WPML > Languages > Edit languages and show me a screenshot of the page? specifically the part about the encoding, because maybe that option currently appears as disabled ("no" option). if that's the case, then try to set it to yes, create a new product with bulgarian slugs and then check if the problem disappears then?
2) The "Auto-generate from title" option is the default from WPML, but once it's changed, it doesn't go back on updates or anything else.
3) Adding the WPML SEO plugin is kind of a must in this case otherwise you'll have issues like content in the sitemap not appearing correctly or maybe some metadata not being updated correctly for the crawlers.
in terms of editing, you'll likely see new entries in the translation editor once the page is updated, so you might need to retranslate the SEO metadata from rank-math, but the thing is that in general you only translate what appears in the translation editor so it's likely that content hasn't been translated yet unless you have done so manually on the translations.
however this will NOT break anything nor will it interfere with all you've done so far, only after you update the content and in that case, you can copy-paste the metadata and info from rankmath in the translation editor gradually when the time comes.
4) There is no way to keep the old translation because it uses a "translation Memory" which is what you are seeing as a "translation" and if the content is different, by logic, then the translation is also different in at least 99% of the cases. that only happens when the content is not recognized as 90% exactly the same (which even with a typo could actually go lower than 80%) but we are trying to find ways to improve this scenario so maybe n the future we'll be able to "crack the code" and find better ways to handle these situations.
The topic ‘[Closed] Advanced Translation Editor suddenly changed all Cyrilic url as unicode’ is closed to new replies.
