Translating numbers

This thread is resolved. Here is a description of the problem and solution.

Problem:
You reported an issue where digits translated in WPML are not saved when the original page is updated, specifically when the translated digits are identical to the original (e.g., translating "01.01.2024" to "01.01.2024").
Solution:
We found that the issue occurs when the translated string of digits is identical to the original. If you translate the digits to something different (e.g., "01-01-2024"), the issue does not occur. We recommend translating the digits only if they differ from the original. By default, numbers are hidden in translations, so keeping them untranslated will not affect the completion of your translation. We are currently investigating the cause of this behavior to prioritize the issue accordingly.

If this solution does not resolve your issue, or if it seems outdated or irrelevant to your case, we highly recommend checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If you still need assistance, please open a new support ticket at WPML support forum.

This is the technical support forum for WPML - the multilingual WordPress plugin.

Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.

Tagged: ATE

This topic contains 21 replies, has 3 voices.

Last updated by Dražen 11 months, 2 weeks ago.

Assisted by: Dražen.

Author	Posts
May 10, 2024 at 6:25 pm #15616129
olegA-5	Here are the strings you asked for. I took the example of a page for which not only the strings consisting only of digits (and punctuation marks, like dates in the format 01.01.2004), but any changes made via search-box are not saved when making changes to the original. In this case I am talking about loss of translations of all anchors (i.e. strings that consist of only anchors, in other words, strings in #abc format, but to be more precise, in #%ab%cd%ef format, because in the originals all my anchors consist of escaped characters). URL when I made the translations and saved them: hidden link URL when I opened ATE again after making changes to the original and found that all translations made via search-box were missing (I saved this version of the translation and then continued with this page and its translations in other sessions): hidden link But this is still a voluminous (200K characters) non-top-level (grandchild) page with the non-Latin original (and escaped URL) translated into 39 languages, which _could_ be the cause of the problem (making changes to this page easily loads the site's 24 (yes, twenty-four) CPU cores to the max, which actually seems rather odd to me). At the same time, the problem purely with maintaining translations of strings consisting of numbers/digits is evident even with simple examples. Here are links for a page with nothing but one line: 01.01.2004 (this page has no escaped characters in the URL, it is the top level one). The search-box translation of this line is not saved when the original is changed (by adding another line of the same type): hidden link hidden link
May 13, 2024 at 7:04 am #15618624
Dražen Supporter Languages: English (English ) Timezone: Europe/Zagreb (GMT+02:00)	Hello, thanks for getting back. I have shared the links and info with our 2nd tier to check and advise further. Regards, Drazen
May 13, 2024 at 12:46 pm #15620995
Dražen Supporter Languages: English (English ) Timezone: Europe/Zagreb (GMT+02:00)	Hello, we have checked the shared ATE jobs with numbers, and it seems what you have experienced there is expected. We checked both jobs in the first job original string is 01.01.2024 In the 2nd job, the original string is <![CDATA[<p>01.01.2024</p> <p>01.02.2024</p>]]> You can see the difference first string is missing the paragraph tags while the 2nd job has the paragraph tags. So there is a difference in string send for translation and is expected you need to re-enter the translation. Regards, Drazen
May 13, 2024 at 1:12 pm #15621096
olegA-5	There is something wrong here, since I don't use such a markup. Accordingly, I don't understand where it came from. Perhaps my mistake was that the first time I saved the page like this: 01.01.2024 The second time I saved the page like this: opening p-tag 01.01.2024 closing p-tag opening p-tag 01.02.2024 closing p-tag I should have left the first line unchanged for the sake of purity. However, I'm more or less sure that "01.01.2024" and "opening p-tag 01.01.2024 closing p-tag" have exactly the same meaning for the translation. In any case, I don't use some "<![CDATA[" or square brackets at all. Furthermore, I absolutely never use Gutenberg. I always write in the code editor. So "opening p-tag 01.01.01.2024 closing p-tag opening p-tag 01.02.2024 closing p-tag" should in no way turn into what you quoted. I just looked at how the code for this page is displayed in the frontend. And it's exactly like this: "opening p-tag 01.01.01.2024 closing p-tag opening p-tag 01.02.2024 closing p-tag." Which is to be expected. I don't understand where all this CDATA markup is coming from. Wikipedia tells me that this is how character data sections in XML are marked up. But I don't use that kind of markup. Isn't it added by WPML itself? But if so, isn't that why WPML stops realising that the strings are the same and therefore don't need a new translation?
May 13, 2024 at 1:21 pm #15621112
Dražen Supporter Languages: English (English ) Timezone: Europe/Zagreb (GMT+02:00)	Hello, I shared an example code from our side it seems it was formed wrong in my reply, I see how it can cause confused. Anyway, the only difference that you see and is done from your side is one string has a p tag, and the other doesn't have one. That is the difference for ATE and translation will not match and you need to enter it again, that is expected. On how it can happen, maybe if you switch between visual / code, the code can be gone, that is one way if it wasn't removed manually. From our side, I think we have done our best to explain to you how the issue happens for case 1 which is now escalated to dev and a workaround you can use (different numbers), and for 2nd case you have shared with ATE jobs. If you experience any other issue and still have problems, it is probably a similar example as above, or some steps you are doing. I suggest opening a new ticket or I can do it for you and we can check on your staging site's exact steps / case what steps you do and what goes wrong. Regards, Drazen
May 13, 2024 at 1:33 pm #15621140
olegA-5	Yes, you are right, if you use p-tag right away, the translation is preserved in this example. Here is an example where the translation is not preserved. hidden link hidden link Here p-tags were used from the beginning. The difference in this example is that this is not a top level page. New threads created by Dražen and linked to this one are listed below: https://wpml.org/forums/topic/split-translation-is-not-preserved/
May 14, 2024 at 6:32 am #15623351
Dražen Supporter Languages: English (English ) Timezone: Europe/Zagreb (GMT+02:00)	Hello, as I have said, this looks like a different issue than the one originally reported, and we would need to check it further. We limit 1 issue per 1 ticket, to keep things clear and easy to follow. I have opened a new ticket for your new issue: - https://wpml.org/forums/topic/split-translation-is-not-preserved/ Let's continue there. Regards, Drazen