[FIX] website: update table of content navbar when heading style changes#264152
Closed
fw-bot wants to merge 1 commit into
Closed
[FIX] website: update table of content navbar when heading style changes#264152fw-bot wants to merge 1 commit into
fw-bot wants to merge 1 commit into
Conversation
Contributor
Contributor
Author
|
@sben-odoo @robinlej cherrypicking of pull request #260378 failed. stdout: Either perform the forward-port manually (and push to this branch, proceeding as usual) or close this PR (maybe?).
More info at https://github.com/odoo/odoo/wiki/Mergebot#forward-port |
85b5fc3 to
5bc1cd5
Compare
5bc1cd5 to
ef30ad4
Compare
Steps to reproduce: =================== 1. Enable a second language on the website 2. Add a Table of Content snippet to a page 3. Apply bold (or any inline style) to one of the headings, save 4. Switch to the second language in translation mode 5. Translate the styled heading and save => The TOC navbar entry keeps showing the source text on reload. => Expected: navbar shows the translated heading text, unstyled. Cause: ====== When a TOC heading carries inline markup, the server emits the heading and the navbar entry as two independent translation terms with different `data-oe-translation-source-sha` values, even though their textContent matches. A translation written under the heading's sha therefore never reaches the navbar's slot. `handleToC` was meant to bridge that by aliasing the navbar span's sha to the heading's during translation-mode setup, but two issues prevented it from working in saas-18.4+: - The TOC navbar lives under `.o_not_editable`, so its translation spans were excluded from `findOEditable` and `handleToC` never ran on them. The class `o_translation_without_style` was never added, and the sha was never aliased. Solution: ========= - `prepareTranslation` iterates TOC navbar translation spans explicitly, so `handleToC` reaches them despite `findOEditable` skipping `.o_not_editable`. - `handleToC` always tags the navbar span with `o_translation_without_style` when a matching heading exists. - An `after_replication_handlers` hook flags every replicated unstyled-translation target as `.o_dirty`, so the replicated translation is included in the save. opw-5950228 X-original-commit: 76e179f
ef30ad4 to
23dcb1f
Compare
Contributor
Author
|
@sben-odoo @robinlej this forward port of #260378 is awaiting action (not merged or closed). |
Contributor
|
robodoo r+ |
robodoo
pushed a commit
that referenced
this pull request
May 20, 2026
Steps to reproduce: =================== 1. Enable a second language on the website 2. Add a Table of Content snippet to a page 3. Apply bold (or any inline style) to one of the headings, save 4. Switch to the second language in translation mode 5. Translate the styled heading and save => The TOC navbar entry keeps showing the source text on reload. => Expected: navbar shows the translated heading text, unstyled. Cause: ====== When a TOC heading carries inline markup, the server emits the heading and the navbar entry as two independent translation terms with different `data-oe-translation-source-sha` values, even though their textContent matches. A translation written under the heading's sha therefore never reaches the navbar's slot. `handleToC` was meant to bridge that by aliasing the navbar span's sha to the heading's during translation-mode setup, but two issues prevented it from working in saas-18.4+: - The TOC navbar lives under `.o_not_editable`, so its translation spans were excluded from `findOEditable` and `handleToC` never ran on them. The class `o_translation_without_style` was never added, and the sha was never aliased. Solution: ========= - `prepareTranslation` iterates TOC navbar translation spans explicitly, so `handleToC` reaches them despite `findOEditable` skipping `.o_not_editable`. - `handleToC` always tags the navbar span with `o_translation_without_style` when a matching heading exists. - An `after_replication_handlers` hook flags every replicated unstyled-translation target as `.o_dirty`, so the replicated translation is included in the save. opw-5950228 closes #264152 X-original-commit: 76e179f Signed-off-by: Robin Lejeune (role) <role@odoo.com> Signed-off-by: Saif Allah Ben Khalil (sben) <sben@odoo.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Steps to reproduce:
=> The TOC navbar entry keeps showing the source text on reload.
=> Expected: navbar shows the translated heading text, unstyled.
Cause:
When a TOC heading carries inline markup, the server emits the
heading and the navbar entry as two independent translation terms
with different
data-oe-translation-source-shavalues, even thoughtheir textContent matches. A translation written under the heading's
sha therefore never reaches the navbar's slot.
handleToCwas meant to bridge that by aliasing the navbar span'ssha to the heading's during translation-mode setup, but two issues
prevented it from working in saas-18.4+:
.o_not_editable, so its translationspans were excluded from
findOEditableandhandleToCneverran on them. The class
o_translation_without_stylewas neveradded, and the sha was never aliased.
Solution:
prepareTranslationiterates TOC navbar translation spansexplicitly, so
handleToCreaches them despitefindOEditableskipping
.o_not_editable.handleToCalways tags the navbar span witho_translation_without_stylewhen a matching heading exists.after_replication_handlershook flags every replicatedunstyled-translation target as
.o_dirty, so the replicatedtranslation is included in the save.
opw-5950228
Forward-Port-Of: #263547
Forward-Port-Of: #260378