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.
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
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.
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 "<
