I need to add markup (italics) only to a translation, to indicate a term in the source language. So far the only way appears to be to edit the translated page (which always brings up the dire warning that it will be lost when the page is updated (true).
There are two main scenarios:
1. When using foreign language terms, it is good, standard, practice to write them in italics, e.g. "Comité d'honneur" (since we do not have a native word or wish to use the more traditional/formal term.
2. Names of things in the source language, e.g. the "sardana" dance (a Catalan traditional dance).
Thanks in advance for thoughts on this matter. It seems to be a major yet long-standing oversight that we may wish to apply markup only to the translated text.
At the moment, WPML does not support adding different markup in translations that does not exist in the original content. Translations always inherit the same markup structure as the original. While this may change in the future, this is how it currently works.
That said, here are a couple of possible workarounds:
1. Disable the Advanced Translation Editor (ATE) and translate the content directly in the WordPress editor or your page builder. This allows you to use different markup per language.
Guide: https://wpml.org/documentation/translating-your-contents/using-different-translation-editors-for-different-pages/
2. Add neutral HTML wrappers (for example, span or div elements) in the original content, and then apply language-specific CSS rules that target only translated languages.
I hope this helps clarify the limitation and provides a viable path forward.
This is a serious oversight for such an established provider of localisation software. It is a basic cultural sensitivity need.
It is completely unacceptable that we have to edit the content directly, however easier that is in many occasions, since this will be eliminated with updates to the original, as I said.
In fact, I am currently battling with the fact that having been asked to update key headings, I realised that the plugin completely eliminated all the affected pages, and even blocks of text which had already been translated and should have been in the database. I am now having to retranslate whole swathes of text.
Having been a loyal user for over 15 years, I am becoming seriously disillusioned by the software. There is so much that is great about it, but it's causing serious amounts of extra, unnecessary work.
Especially as I'm working on my own and the plugin seems now geared towards teams, so there are extra hoops to jump through to assign myself translations, which I have to remember. When you have four languages, even a small site like this has become a complete nightmare to manage.
Sorry for the rant, but I didn't expect to be spending Sunday evening redoing lots of work, instead of completing the final, donation system form translation work.
I guess I should open a new ticket but since I don't want to mark this one as resolved until I at least have some indication that the markup issue will be taken seriously, and I need urgent help with what has been a dog's breakfast with updates, I am adding a message here.
Apart from having to repeat a load of translations, I have found that the URLs are not updating. Indeed I have had to update visible ones manually, but there are some that are not even appearing in the translation and on the translated page (hidden link) the links from the image box go to the Catalan page; in one case, it has the English slug but misses out the /en/ so it goes to the original Catalan page anyway.
I've tried flushing cache but it makes no difference.
Please see the screenshot with the URL at the bottom, taken hovering over the left image. The other images show Catalan links directly.
(Related) update:
It looks like I have no choice but to avoid the ATE for several areas of the site. There is more content that is purely designed for the local population.
And I also realise why things disappeared and broke. I was trying to "do things properly" using the ATE, but of course, there were things I'd had to change that the ATE couldn't handle, so when I sent it back to the ATE to try and fix issues like the links, I lost those changes.
Yes, I should have documented all this. But the system should cater for this and (I always try to provide suggestions, not just criticise), have a mechanism to assign special status to those pages/sections that need special treatment in different languages.
It would be good if onTheGoSystems could widen its vision of translation to what we professionals actually do - localisation, not "simple"(!) translation. Again, this is about more than just language, but culture, geography, demographics and a long etc. of local factors that mean content must be adapted not just translated.
I'm surprised that this hasn't had more attention. I still instinctively rank WPML as the best in breed (my last experience with one of the other main ones did not change that view), so I hope this serves as motivation to continue to innovate in this multi-cultural, not only multi-lingual, world in which we live.
I would like a response to my queries, but I appreciate there will not be an answer that will help my immediate situation, so I am lowering my expectations and will close the issue once I have some sort of response and assurance that you guys will take my concerns and requests seriously.
Thank you for taking the time to share your feedback with us.
I truly appreciate your continued trust and loyalty as a WPML user over the years. Feedback from experienced users like you is extremely valuable to us.
I’ve added your support ticket as an additional vote to the existing feature request. Every piece of feedback helps our development team evaluate requests and prioritize improvements, with the goal of making WPML as smooth and reliable as possible for all workflows.
Regarding the warning you’re seeing: it appears because the translated page is being opened directly in the WordPress editor. This message is shown to inform you that any translation previously created using WPML’s Advanced Translation Editor (ATE) would be overwritten if you proceed with editing the translation manually (for example, in Elementor, WordPress editor).
At the moment, WPML does not support mixing translation methods for the same content. You’ll need to choose one consistent approach:
• either continue translating using WPML’s Advanced Translation Editor, or
• switch to manual translations using the WordPress editor exclusively.
This is to avoid conflicts and unintended loss of translation data.
As for the additional issue you mentioned about links and other items that need to be handled without ATE, I’m not sure you still want me to check the link issue. If so, please let me know, and I’ll be happy to open a new support ticket to assist you further.
Yes I do understand and appreciate the need to use either the ATE or manual editing. I'd already been bitten there (accidentally, I left a tab open..)
I have now documented
* which pages need to avoid the ATE and
* why/which elements are customised by language.
I was also able to resolve the URL issue, which was probably mainly due to the confusion of 4 languages (3 active/visible so far, on in progress), pages and sections linked from different places and this whole ATE/non-ATE thing.
To give a bit more detail on potential new assistance for these situations, I don't think it would be too complicated to at least provide a framework which allows users to safely use the ATE (which for large, standardised content is excellent, by the way), while keeping track of the pages that should not use it.
Even a simple flag that could generate more specific warnings if manual changes have been made - that's all in the db already, so easy. A more sophisticated setup would involve actively setting certain pages to "no ATE" and store webmaster notes in situ, rather than Slack (or simple desktop notes in my case).
Or even...to allow sections to be "cordoned off", allowing the rest to use the ATE, but that would clearly require working with WP core and site builders, not all of which would play ball. Good to dream though!
I'm now imagining a visual sitemap showing all this, with colours for languages, clickable and greyed-out areas for ATE / non-ATE...
Food for thought.
And that doesn't even go down the rabbit hole I would love to explore around the whole localisation and syntax issue (beginning with the premise that syntax ≠ semantics so a new approach is needed for string translation especially.
The biggest problem, or certainly one of them, in strings is the Saxon Genitive and derived "adjectival nouns" - nouns used as adjectives, like "website terms", which simply don't work in most languages. Romance languages, for example always need to use "terms of the website", which breaks the string. It doesn't generally work in Cyrillic or Semitic languages either.
It's not always a problem in practice, but it is when %s is arbitrarily assigned a position in the target languages that simply doesn't work because a completely different structure is needed. In my case "Make it annually" (admittedly, not good English either, but I didn't write the plugin...!) would never be translated with an adverb, but with, for example "every year". But if the string "annually" is used elsewhere, that string wouldn't work!
Oops, I appear to have gone down the rabbit hole after all. It's a fascinating conundrum!
Thanks, I think we can close this now, but hopefully the thread will provide some clarity for people going through what I have been (hence the bullets above so the key information doesn't get lost in my dissertation!
