Skip to content

Conversation

@HydrionBurst
Copy link
Contributor

@HydrionBurst HydrionBurst commented Jan 17, 2025

Before:

The typofix feature treats terms in the old and new values with similar text
content as the same term, migrating the translations of the old term to the new
term.

For example

The old value has the mapping:
'Draft': 'Brouillon'

The new value contains the term:
'<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>'

Since the old term and the new term share the same text content, 'Draft', after
write, the new term reuses the old translation of 'Draft'. However, the
translation 'Brouillon' is always visible, unlike its en_US counterpart.

This behavior is acceptable in non-upgrade mode because the user writes the
en_US value and is responsible for verifying translations afterward. However, it
is problematic during upgrades because users cannot easily identify which
records have changed and need to be rechecked.

After:

The translation inheritance behavior can be described as below
Translations can be inherited after write from old terms to new terms which
share the very close text contents

  1. when write in production mode, text contents for translation terms are more
    important than the HTML/XML structures of them, and the old term translations
    should be remained as much as possible. Because
    • the writing user is responsible to recheck all translations after write.
    • it is easier for the writing user to copy technical HTML/XML structures
      than translate text contents for a language they may not know.
    • the feature can also be used as typofix when the only small diff is the
      text content
  2. when write in upgrade time, the HTML/XML structure is more important than
    the text content, and the new term structure should be remained as much as
    possible. Because
    • HTML/XML structures might be changed a lot after upgrade, which may
      contain behavior relevant diff (e.g. invisible), even if text contents
      are not changed.
    • users have no idea which records' values are changed during upgrade and
      are hard to recheck their translations.
    • new terms are highly likely to be correctly translated in the latest po
      files which will be imported during upgrade.
    • the typofix feature can still be remained when the only small diff is the
      text content

Based on the above feature analysis, we use the below new strategy

  1. translations can be inherited only if the old source term and the new source
    term share the same HTML/XML structure
  2. translations can be inherited only if the old translation term and the new
    source term share the same HTML/XML structure
  3. when translations are inherited, MODIFIER_ATTRS will be synchronized with
    the new source term, other attributes will be copied from the source term if
    available.

@robodoo
Copy link
Contributor

robodoo commented Jan 17, 2025

Pull request status dashboard

@C3POdoo C3POdoo requested review from a team, Gorash and xmo-odoo and removed request for a team January 17, 2025 15:30
@C3POdoo C3POdoo added the RD research & development, internal work label Jan 17, 2025
Copy link
Contributor

@aj-fuentes aj-fuentes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we also add something like

        # order of terms was inverted
        archf = '<form>%s<div>%s</div></form>'
        terms_en = ('<i>Draft</i>', '<span invisible="1">Draft</span>')
        terms_fr = ('<i>Brouillon</i>', '<span invisible="1">Brouillon</span>')
        view = self.create_view(archf, terms_en, en_US=terms_en, fr_FR=terms_fr)

        archf = '<form>%s<div>%s</div></form>'
        terms_en = ('<span invisible="1">Draft</span>', '<i>Draft</i>')
        terms_fr = ('<span invisible="1">Brouillon</span>', '<i>Brouillon</i>')
        view.with_context(install_mode=True).write({'arch_db': archf % terms_en})

And perhaps the same term-inverting tests but with a pure text element as well.

@C3POdoo C3POdoo requested a review from a team January 20, 2025 10:37
@HydrionBurst HydrionBurst force-pushed the 17.0-disable-upgrade-xml-typofix-cwg branch from edd470f to 2bebeb3 Compare January 20, 2025 11:03
@Gorash Gorash removed their request for review January 20, 2025 13:09
@HydrionBurst HydrionBurst force-pushed the 17.0-disable-upgrade-xml-typofix-cwg branch 5 times, most recently from 489e8a1 to e6c8256 Compare January 22, 2025 17:12
@HydrionBurst HydrionBurst changed the title [FIX] core: disable typofix translations during upgrades [FIX] core: inherit translations better when upgrade Jan 23, 2025
Before:
The typofix feature treats terms in the old and new values with similar text
content as the same term, migrating the translations of the old term to the new
term.

For example

The old value has the mapping:
'Draft': 'Brouillon'

The new value contains the term:
'<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>'

Since the old term and the new term share the same text content, 'Draft', after
`write`, the new term reuses the old translation of 'Draft'. However, the
translation 'Brouillon' is always visible, unlike its en_US counterpart.

This behavior is acceptable in non-upgrade mode because the user writes the
en_US value and is responsible for verifying translations afterward. However, it
is problematic during upgrades because users cannot easily identify which
records have changed and need to be rechecked.

After:
The translation inheritance behavior can be described as below
Translations can be inherited after `write` from old terms to new terms which
share the very close text contents
1. when `write` in production mode, text contents for translation terms are more
   important than the HTML/XML structures of them, and the old term translations
   should be remained as much as possible. Because
    * the writing user is responsible to recheck all translations after `write`.
    * it is easier for the writing user to copy technical HTML/XML structures
      than translate text contents for a language they may not know.
    * the feature can also be used as typofix when the only small diff is the
      text content
2. when `write` in upgrade time, the HTML/XML structure is more important than
   the text content, and the new term structure should be remained as much as
   possible. Because
    * HTML/XML structures might be changed a lot after upgrade, which may
      contain behavior relevant diff (e.g. `invisible`), even if text contents
      are not changed.
    * users have no idea which records' values are changed during upgrade and
      are hard to recheck their translations.
    * new terms are highly likely to be correctly translated in the latest po
      files which will be imported during upgrade.
    * the typofix feature can still be remained when the only small diff is the
      text content

Based on the above feature analysis, we use the below new strategy
1. translations can be inherited only if the old source term and the new source
   term share the same HTML/XML structure
2. translations can be inherited only if the old translation term and the new
   source term share the same HTML/XML structure
3. when translations are inherited, MODIFIER_ATTRS will be synchronized with
   the new source term, other attributes will be copied from the source term if
   available.
@HydrionBurst HydrionBurst force-pushed the 17.0-disable-upgrade-xml-typofix-cwg branch from e6c8256 to cc01f5d Compare January 23, 2025 09:28
Copy link
Contributor

@aj-fuentes aj-fuentes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Nice work!

HydrionBurst added a commit to odoo-dev/odoo that referenced this pull request Jan 23, 2025
Before:
The typofix feature treats terms in the old and new values with similar text
content as the same term, migrating the translations of the old term to the new
term.

For example

The old value has the mapping:
'Draft': 'Brouillon'

The new value contains the term:
'<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>'

Since the old term and the new term share the same text content, 'Draft', after
`write`, the new term reuses the old translation of 'Draft'. However, the
translation 'Brouillon' is always visible, unlike its en_US counterpart.

This behavior is acceptable in non-upgrade mode because the user writes the
en_US value and is responsible for verifying translations afterward. However, it
is problematic during upgrades because users cannot easily identify which
records have changed and need to be rechecked.

After:
'state' is removed from MODIFIER_ATTRS since it is not customized by Odoo

The translation inheritance behavior can be described as below
Translations can be inherited after `write` from old terms to new terms which
share the very close text contents
1. when `write` in production mode, text contents for translation terms are more
   important than the HTML/XML structures of them, and the old term translations
   should be remained as much as possible. Because
    * the writing user is responsible to recheck all translations after `write`.
    * it is easier for the writing user to copy technical HTML/XML structures
      than translate text contents for a language they may not know.
    * the feature can also be used as typofix when the only small diff is the
      text content
2. when `write` in upgrade time, the HTML/XML structure is more important than
   the text content, and the new term structure should be remained as much as
   possible. Because
    * HTML/XML structures might be changed a lot after upgrade, which may
      contain behavior relevant diff (e.g. `invisible`), even if text contents
      are not changed.
    * users have no idea which records' values are changed during upgrade and
      are hard to recheck their translations.
    * new terms are highly likely to be correctly translated in the latest po
      files which will be imported during upgrade.
    * the typofix feature can still be remained when the only small diff is the
      text content

Based on the above feature analysis, we use the below new strategy
1. translations can be inherited only if the old source term and the new source
   term share the same HTML/XML structure
2. translations can be inherited only if the old translation term and the new
   source term share the same HTML/XML structure
3. when translations are inherited, MODIFIER_ATTRS will be synchronized with
   the new source term, other attributes will be copied from the source term if
   available.

Forward-Port-Of: odoo#194181
robodoo pushed a commit that referenced this pull request Jan 24, 2025
Before:
The typofix feature treats terms in the old and new values with similar text
content as the same term, migrating the translations of the old term to the new
term.

For example

The old value has the mapping:
'Draft': 'Brouillon'

The new value contains the term:
'<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>'

Since the old term and the new term share the same text content, 'Draft', after
`write`, the new term reuses the old translation of 'Draft'. However, the
translation 'Brouillon' is always visible, unlike its en_US counterpart.

This behavior is acceptable in non-upgrade mode because the user writes the
en_US value and is responsible for verifying translations afterward. However, it
is problematic during upgrades because users cannot easily identify which
records have changed and need to be rechecked.

After:
The translation inheritance behavior can be described as below
Translations can be inherited after `write` from old terms to new terms which
share the very close text contents
1. when `write` in production mode, text contents for translation terms are more
   important than the HTML/XML structures of them, and the old term translations
   should be remained as much as possible. Because
    * the writing user is responsible to recheck all translations after `write`.
    * it is easier for the writing user to copy technical HTML/XML structures
      than translate text contents for a language they may not know.
    * the feature can also be used as typofix when the only small diff is the
      text content
2. when `write` in upgrade time, the HTML/XML structure is more important than
   the text content, and the new term structure should be remained as much as
   possible. Because
    * HTML/XML structures might be changed a lot after upgrade, which may
      contain behavior relevant diff (e.g. `invisible`), even if text contents
      are not changed.
    * users have no idea which records' values are changed during upgrade and
      are hard to recheck their translations.
    * new terms are highly likely to be correctly translated in the latest po
      files which will be imported during upgrade.
    * the typofix feature can still be remained when the only small diff is the
      text content

Based on the above feature analysis, we use the below new strategy
1. translations can be inherited only if the old source term and the new source
   term share the same HTML/XML structure
2. translations can be inherited only if the old translation term and the new
   source term share the same HTML/XML structure
3. when translations are inherited, MODIFIER_ATTRS will be synchronized with
   the new source term, other attributes will be copied from the source term if
   available.

closes #194186

Backward-port-of: #194181
Backward-port-of: #150152
Signed-off-by: Raphael Collet <rco@odoo.com>
fw-bot pushed a commit to odoo-dev/odoo that referenced this pull request Jan 24, 2025
Before:
The typofix feature treats terms in the old and new values with similar text
content as the same term, migrating the translations of the old term to the new
term.

For example

The old value has the mapping:
'Draft': 'Brouillon'

The new value contains the term:
'<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>'

Since the old term and the new term share the same text content, 'Draft', after
`write`, the new term reuses the old translation of 'Draft'. However, the
translation 'Brouillon' is always visible, unlike its en_US counterpart.

This behavior is acceptable in non-upgrade mode because the user writes the
en_US value and is responsible for verifying translations afterward. However, it
is problematic during upgrades because users cannot easily identify which
records have changed and need to be rechecked.

After:
'state' is removed from MODIFIER_ATTRS since it is not customized by Odoo

The translation inheritance behavior can be described as below
Translations can be inherited after `write` from old terms to new terms which
share the very close text contents
1. when `write` in production mode, text contents for translation terms are more
   important than the HTML/XML structures of them, and the old term translations
   should be remained as much as possible. Because
    * the writing user is responsible to recheck all translations after `write`.
    * it is easier for the writing user to copy technical HTML/XML structures
      than translate text contents for a language they may not know.
    * the feature can also be used as typofix when the only small diff is the
      text content
2. when `write` in upgrade time, the HTML/XML structure is more important than
   the text content, and the new term structure should be remained as much as
   possible. Because
    * HTML/XML structures might be changed a lot after upgrade, which may
      contain behavior relevant diff (e.g. `invisible`), even if text contents
      are not changed.
    * users have no idea which records' values are changed during upgrade and
      are hard to recheck their translations.
    * new terms are highly likely to be correctly translated in the latest po
      files which will be imported during upgrade.
    * the typofix feature can still be remained when the only small diff is the
      text content

Based on the above feature analysis, we use the below new strategy
1. translations can be inherited only if the old source term and the new source
   term share the same HTML/XML structure
2. translations can be inherited only if the old translation term and the new
   source term share the same HTML/XML structure
3. when translations are inherited, MODIFIER_ATTRS will be synchronized with
   the new source term, other attributes will be copied from the source term if
   available.

Forward-port-of: odoo#194181
X-original-commit: 90aa858
robodoo pushed a commit that referenced this pull request Jan 24, 2025
Before:
The typofix feature treats terms in the old and new values with similar text
content as the same term, migrating the translations of the old term to the new
term.

For example

The old value has the mapping:
'Draft': 'Brouillon'

The new value contains the term:
'<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>'

Since the old term and the new term share the same text content, 'Draft', after
`write`, the new term reuses the old translation of 'Draft'. However, the
translation 'Brouillon' is always visible, unlike its en_US counterpart.

This behavior is acceptable in non-upgrade mode because the user writes the
en_US value and is responsible for verifying translations afterward. However, it
is problematic during upgrades because users cannot easily identify which
records have changed and need to be rechecked.

After:
The translation inheritance behavior can be described as below
Translations can be inherited after `write` from old terms to new terms which
share the very close text contents
1. when `write` in production mode, text contents for translation terms are more
   important than the HTML/XML structures of them, and the old term translations
   should be remained as much as possible. Because
    * the writing user is responsible to recheck all translations after `write`.
    * it is easier for the writing user to copy technical HTML/XML structures
      than translate text contents for a language they may not know.
    * the feature can also be used as typofix when the only small diff is the
      text content
2. when `write` in upgrade time, the HTML/XML structure is more important than
   the text content, and the new term structure should be remained as much as
   possible. Because
    * HTML/XML structures might be changed a lot after upgrade, which may
      contain behavior relevant diff (e.g. `invisible`), even if text contents
      are not changed.
    * users have no idea which records' values are changed during upgrade and
      are hard to recheck their translations.
    * new terms are highly likely to be correctly translated in the latest po
      files which will be imported during upgrade.
    * the typofix feature can still be remained when the only small diff is the
      text content

Based on the above feature analysis, we use the below new strategy
1. translations can be inherited only if the old source term and the new source
   term share the same HTML/XML structure
2. translations can be inherited only if the old translation term and the new
   source term share the same HTML/XML structure
3. when translations are inherited, MODIFIER_ATTRS will be synchronized with
   the new source term, other attributes will be copied from the source term if
   available.

closes #194181

Signed-off-by: Raphael Collet <rco@odoo.com>
fw-bot pushed a commit to odoo-dev/odoo that referenced this pull request Jan 24, 2025
Before:
The typofix feature treats terms in the old and new values with similar text
content as the same term, migrating the translations of the old term to the new
term.

For example

The old value has the mapping:
'Draft': 'Brouillon'

The new value contains the term:
'<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>'

Since the old term and the new term share the same text content, 'Draft', after
`write`, the new term reuses the old translation of 'Draft'. However, the
translation 'Brouillon' is always visible, unlike its en_US counterpart.

This behavior is acceptable in non-upgrade mode because the user writes the
en_US value and is responsible for verifying translations afterward. However, it
is problematic during upgrades because users cannot easily identify which
records have changed and need to be rechecked.

After:
'state' is removed from MODIFIER_ATTRS since it is not customized by Odoo

The translation inheritance behavior can be described as below
Translations can be inherited after `write` from old terms to new terms which
share the very close text contents
1. when `write` in production mode, text contents for translation terms are more
   important than the HTML/XML structures of them, and the old term translations
   should be remained as much as possible. Because
    * the writing user is responsible to recheck all translations after `write`.
    * it is easier for the writing user to copy technical HTML/XML structures
      than translate text contents for a language they may not know.
    * the feature can also be used as typofix when the only small diff is the
      text content
2. when `write` in upgrade time, the HTML/XML structure is more important than
   the text content, and the new term structure should be remained as much as
   possible. Because
    * HTML/XML structures might be changed a lot after upgrade, which may
      contain behavior relevant diff (e.g. `invisible`), even if text contents
      are not changed.
    * users have no idea which records' values are changed during upgrade and
      are hard to recheck their translations.
    * new terms are highly likely to be correctly translated in the latest po
      files which will be imported during upgrade.
    * the typofix feature can still be remained when the only small diff is the
      text content

Based on the above feature analysis, we use the below new strategy
1. translations can be inherited only if the old source term and the new source
   term share the same HTML/XML structure
2. translations can be inherited only if the old translation term and the new
   source term share the same HTML/XML structure
3. when translations are inherited, MODIFIER_ATTRS will be synchronized with
   the new source term, other attributes will be copied from the source term if
   available.

Forward-port-of: odoo#194181
X-original-commit: 90aa858
@robodoo robodoo closed this Jan 24, 2025
robodoo pushed a commit that referenced this pull request Jan 24, 2025
Before:
The typofix feature treats terms in the old and new values with similar text
content as the same term, migrating the translations of the old term to the new
term.

For example

The old value has the mapping:
'Draft': 'Brouillon'

The new value contains the term:
'<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>'

Since the old term and the new term share the same text content, 'Draft', after
`write`, the new term reuses the old translation of 'Draft'. However, the
translation 'Brouillon' is always visible, unlike its en_US counterpart.

This behavior is acceptable in non-upgrade mode because the user writes the
en_US value and is responsible for verifying translations afterward. However, it
is problematic during upgrades because users cannot easily identify which
records have changed and need to be rechecked.

After:
'state' is removed from MODIFIER_ATTRS since it is not customized by Odoo

The translation inheritance behavior can be described as below
Translations can be inherited after `write` from old terms to new terms which
share the very close text contents
1. when `write` in production mode, text contents for translation terms are more
   important than the HTML/XML structures of them, and the old term translations
   should be remained as much as possible. Because
    * the writing user is responsible to recheck all translations after `write`.
    * it is easier for the writing user to copy technical HTML/XML structures
      than translate text contents for a language they may not know.
    * the feature can also be used as typofix when the only small diff is the
      text content
2. when `write` in upgrade time, the HTML/XML structure is more important than
   the text content, and the new term structure should be remained as much as
   possible. Because
    * HTML/XML structures might be changed a lot after upgrade, which may
      contain behavior relevant diff (e.g. `invisible`), even if text contents
      are not changed.
    * users have no idea which records' values are changed during upgrade and
      are hard to recheck their translations.
    * new terms are highly likely to be correctly translated in the latest po
      files which will be imported during upgrade.
    * the typofix feature can still be remained when the only small diff is the
      text content

Based on the above feature analysis, we use the below new strategy
1. translations can be inherited only if the old source term and the new source
   term share the same HTML/XML structure
2. translations can be inherited only if the old translation term and the new
   source term share the same HTML/XML structure
3. when translations are inherited, MODIFIER_ATTRS will be synchronized with
   the new source term, other attributes will be copied from the source term if
   available.

closes #195032

Forward-port-of: #194181
X-original-commit: 90aa858
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Chong Wang (cwg) <cwg@odoo.com>
HydrionBurst added a commit to odoo-dev/odoo that referenced this pull request Jan 24, 2025
Before:
The typofix feature treats terms in the old and new values with similar text
content as the same term, migrating the translations of the old term to the new
term.

For example

The old value has the mapping:
'Draft': 'Brouillon'

The new value contains the term:
'<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>'

Since the old term and the new term share the same text content, 'Draft', after
`write`, the new term reuses the old translation of 'Draft'. However, the
translation 'Brouillon' is always visible, unlike its en_US counterpart.

This behavior is acceptable in non-upgrade mode because the user writes the
en_US value and is responsible for verifying translations afterward. However, it
is problematic during upgrades because users cannot easily identify which
records have changed and need to be rechecked.

After:
'state' is removed from MODIFIER_ATTRS since it is not customized by Odoo

The translation inheritance behavior can be described as below
Translations can be inherited after `write` from old terms to new terms which
share the very close text contents
1. when `write` in production mode, text contents for translation terms are more
   important than the HTML/XML structures of them, and the old term translations
   should be remained as much as possible. Because
    * the writing user is responsible to recheck all translations after `write`.
    * it is easier for the writing user to copy technical HTML/XML structures
      than translate text contents for a language they may not know.
    * the feature can also be used as typofix when the only small diff is the
      text content
2. when `write` in upgrade time, the HTML/XML structure is more important than
   the text content, and the new term structure should be remained as much as
   possible. Because
    * HTML/XML structures might be changed a lot after upgrade, which may
      contain behavior relevant diff (e.g. `invisible`), even if text contents
      are not changed.
    * users have no idea which records' values are changed during upgrade and
      are hard to recheck their translations.
    * new terms are highly likely to be correctly translated in the latest po
      files which will be imported during upgrade.
    * the typofix feature can still be remained when the only small diff is the
      text content

Based on the above feature analysis, we use the below new strategy
1. translations can be inherited only if the old source term and the new source
   term share the same HTML/XML structure
2. translations can be inherited only if the old translation term and the new
   source term share the same HTML/XML structure
3. when translations are inherited, MODIFIER_ATTRS will be synchronized with
   the new source term, other attributes will be copied from the source term if
   available.

Forward-port-of: odoo#194181
X-original-commit: 90aa858
robodoo pushed a commit that referenced this pull request Jan 24, 2025
Before:
The typofix feature treats terms in the old and new values with similar text
content as the same term, migrating the translations of the old term to the new
term.

For example

The old value has the mapping:
'Draft': 'Brouillon'

The new value contains the term:
'<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>'

Since the old term and the new term share the same text content, 'Draft', after
`write`, the new term reuses the old translation of 'Draft'. However, the
translation 'Brouillon' is always visible, unlike its en_US counterpart.

This behavior is acceptable in non-upgrade mode because the user writes the
en_US value and is responsible for verifying translations afterward. However, it
is problematic during upgrades because users cannot easily identify which
records have changed and need to be rechecked.

After:
'state' is removed from MODIFIER_ATTRS since it is not customized by Odoo

The translation inheritance behavior can be described as below
Translations can be inherited after `write` from old terms to new terms which
share the very close text contents
1. when `write` in production mode, text contents for translation terms are more
   important than the HTML/XML structures of them, and the old term translations
   should be remained as much as possible. Because
    * the writing user is responsible to recheck all translations after `write`.
    * it is easier for the writing user to copy technical HTML/XML structures
      than translate text contents for a language they may not know.
    * the feature can also be used as typofix when the only small diff is the
      text content
2. when `write` in upgrade time, the HTML/XML structure is more important than
   the text content, and the new term structure should be remained as much as
   possible. Because
    * HTML/XML structures might be changed a lot after upgrade, which may
      contain behavior relevant diff (e.g. `invisible`), even if text contents
      are not changed.
    * users have no idea which records' values are changed during upgrade and
      are hard to recheck their translations.
    * new terms are highly likely to be correctly translated in the latest po
      files which will be imported during upgrade.
    * the typofix feature can still be remained when the only small diff is the
      text content

Based on the above feature analysis, we use the below new strategy
1. translations can be inherited only if the old source term and the new source
   term share the same HTML/XML structure
2. translations can be inherited only if the old translation term and the new
   source term share the same HTML/XML structure
3. when translations are inherited, MODIFIER_ATTRS will be synchronized with
   the new source term, other attributes will be copied from the source term if
   available.

closes #195055

Forward-port-of: #194181
X-original-commit: 90aa858
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Chong Wang (cwg) <cwg@odoo.com>
adhoc-cicd-bot pushed a commit to adhoc-cicd/odoo-odoo that referenced this pull request Jan 24, 2025
Before:
The typofix feature treats terms in the old and new values with similar text
content as the same term, migrating the translations of the old term to the new
term.

For example

The old value has the mapping:
'Draft': 'Brouillon'

The new value contains the term:
'<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>'

Since the old term and the new term share the same text content, 'Draft', after
`write`, the new term reuses the old translation of 'Draft'. However, the
translation 'Brouillon' is always visible, unlike its en_US counterpart.

This behavior is acceptable in non-upgrade mode because the user writes the
en_US value and is responsible for verifying translations afterward. However, it
is problematic during upgrades because users cannot easily identify which
records have changed and need to be rechecked.

After:
The translation inheritance behavior can be described as below
Translations can be inherited after `write` from old terms to new terms which
share the very close text contents
1. when `write` in production mode, text contents for translation terms are more
   important than the HTML/XML structures of them, and the old term translations
   should be remained as much as possible. Because
    * the writing user is responsible to recheck all translations after `write`.
    * it is easier for the writing user to copy technical HTML/XML structures
      than translate text contents for a language they may not know.
    * the feature can also be used as typofix when the only small diff is the
      text content
2. when `write` in upgrade time, the HTML/XML structure is more important than
   the text content, and the new term structure should be remained as much as
   possible. Because
    * HTML/XML structures might be changed a lot after upgrade, which may
      contain behavior relevant diff (e.g. `invisible`), even if text contents
      are not changed.
    * users have no idea which records' values are changed during upgrade and
      are hard to recheck their translations.
    * new terms are highly likely to be correctly translated in the latest po
      files which will be imported during upgrade.
    * the typofix feature can still be remained when the only small diff is the
      text content

Based on the above feature analysis, we use the below new strategy
1. translations can be inherited only if the old source term and the new source
   term share the same HTML/XML structure
2. translations can be inherited only if the old translation term and the new
   source term share the same HTML/XML structure
3. when translations are inherited, MODIFIER_ATTRS will be synchronized with
   the new source term, other attributes will be copied from the source term if
   available.

closes odoo#194181

Signed-off-by: Raphael Collet <rco@odoo.com>
adhoc-cicd-bot pushed a commit to adhoc-cicd/odoo-odoo that referenced this pull request Jan 25, 2025
Before:
The typofix feature treats terms in the old and new values with similar text
content as the same term, migrating the translations of the old term to the new
term.

For example

The old value has the mapping:
'Draft': 'Brouillon'

The new value contains the term:
'<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>'

Since the old term and the new term share the same text content, 'Draft', after
`write`, the new term reuses the old translation of 'Draft'. However, the
translation 'Brouillon' is always visible, unlike its en_US counterpart.

This behavior is acceptable in non-upgrade mode because the user writes the
en_US value and is responsible for verifying translations afterward. However, it
is problematic during upgrades because users cannot easily identify which
records have changed and need to be rechecked.

After:
The translation inheritance behavior can be described as below
Translations can be inherited after `write` from old terms to new terms which
share the very close text contents
1. when `write` in production mode, text contents for translation terms are more
   important than the HTML/XML structures of them, and the old term translations
   should be remained as much as possible. Because
    * the writing user is responsible to recheck all translations after `write`.
    * it is easier for the writing user to copy technical HTML/XML structures
      than translate text contents for a language they may not know.
    * the feature can also be used as typofix when the only small diff is the
      text content
2. when `write` in upgrade time, the HTML/XML structure is more important than
   the text content, and the new term structure should be remained as much as
   possible. Because
    * HTML/XML structures might be changed a lot after upgrade, which may
      contain behavior relevant diff (e.g. `invisible`), even if text contents
      are not changed.
    * users have no idea which records' values are changed during upgrade and
      are hard to recheck their translations.
    * new terms are highly likely to be correctly translated in the latest po
      files which will be imported during upgrade.
    * the typofix feature can still be remained when the only small diff is the
      text content

Based on the above feature analysis, we use the below new strategy
1. translations can be inherited only if the old source term and the new source
   term share the same HTML/XML structure
2. translations can be inherited only if the old translation term and the new
   source term share the same HTML/XML structure
3. when translations are inherited, MODIFIER_ATTRS will be synchronized with
   the new source term, other attributes will be copied from the source term if
   available.

closes odoo#194181

Signed-off-by: Raphael Collet <rco@odoo.com>
robodoo pushed a commit that referenced this pull request Jan 25, 2025
Before:
The typofix feature treats terms in the old and new values with similar text
content as the same term, migrating the translations of the old term to the new
term.

For example

The old value has the mapping:
'Draft': 'Brouillon'

The new value contains the term:
'<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>'

Since the old term and the new term share the same text content, 'Draft', after
`write`, the new term reuses the old translation of 'Draft'. However, the
translation 'Brouillon' is always visible, unlike its en_US counterpart.

This behavior is acceptable in non-upgrade mode because the user writes the
en_US value and is responsible for verifying translations afterward. However, it
is problematic during upgrades because users cannot easily identify which
records have changed and need to be rechecked.

After:
'state' is removed from MODIFIER_ATTRS since it is not customized by Odoo

The translation inheritance behavior can be described as below
Translations can be inherited after `write` from old terms to new terms which
share the very close text contents
1. when `write` in production mode, text contents for translation terms are more
   important than the HTML/XML structures of them, and the old term translations
   should be remained as much as possible. Because
    * the writing user is responsible to recheck all translations after `write`.
    * it is easier for the writing user to copy technical HTML/XML structures
      than translate text contents for a language they may not know.
    * the feature can also be used as typofix when the only small diff is the
      text content
2. when `write` in upgrade time, the HTML/XML structure is more important than
   the text content, and the new term structure should be remained as much as
   possible. Because
    * HTML/XML structures might be changed a lot after upgrade, which may
      contain behavior relevant diff (e.g. `invisible`), even if text contents
      are not changed.
    * users have no idea which records' values are changed during upgrade and
      are hard to recheck their translations.
    * new terms are highly likely to be correctly translated in the latest po
      files which will be imported during upgrade.
    * the typofix feature can still be remained when the only small diff is the
      text content

Based on the above feature analysis, we use the below new strategy
1. translations can be inherited only if the old source term and the new source
   term share the same HTML/XML structure
2. translations can be inherited only if the old translation term and the new
   source term share the same HTML/XML structure
3. when translations are inherited, MODIFIER_ATTRS will be synchronized with
   the new source term, other attributes will be copied from the source term if
   available.

closes #195079

Forward-port-of: #194181
X-original-commit: 90aa858
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Chong Wang (cwg) <cwg@odoo.com>
fw-bot pushed a commit to odoo-dev/odoo that referenced this pull request Jan 25, 2025
Before:
The typofix feature treats terms in the old and new values with similar text
content as the same term, migrating the translations of the old term to the new
term.

For example

The old value has the mapping:
'Draft': 'Brouillon'

The new value contains the term:
'<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>'

Since the old term and the new term share the same text content, 'Draft', after
`write`, the new term reuses the old translation of 'Draft'. However, the
translation 'Brouillon' is always visible, unlike its en_US counterpart.

This behavior is acceptable in non-upgrade mode because the user writes the
en_US value and is responsible for verifying translations afterward. However, it
is problematic during upgrades because users cannot easily identify which
records have changed and need to be rechecked.

After:
'state' is removed from MODIFIER_ATTRS since it is not customized by Odoo

The translation inheritance behavior can be described as below
Translations can be inherited after `write` from old terms to new terms which
share the very close text contents
1. when `write` in production mode, text contents for translation terms are more
   important than the HTML/XML structures of them, and the old term translations
   should be remained as much as possible. Because
    * the writing user is responsible to recheck all translations after `write`.
    * it is easier for the writing user to copy technical HTML/XML structures
      than translate text contents for a language they may not know.
    * the feature can also be used as typofix when the only small diff is the
      text content
2. when `write` in upgrade time, the HTML/XML structure is more important than
   the text content, and the new term structure should be remained as much as
   possible. Because
    * HTML/XML structures might be changed a lot after upgrade, which may
      contain behavior relevant diff (e.g. `invisible`), even if text contents
      are not changed.
    * users have no idea which records' values are changed during upgrade and
      are hard to recheck their translations.
    * new terms are highly likely to be correctly translated in the latest po
      files which will be imported during upgrade.
    * the typofix feature can still be remained when the only small diff is the
      text content

Based on the above feature analysis, we use the below new strategy
1. translations can be inherited only if the old source term and the new source
   term share the same HTML/XML structure
2. translations can be inherited only if the old translation term and the new
   source term share the same HTML/XML structure
3. when translations are inherited, MODIFIER_ATTRS will be synchronized with
   the new source term, other attributes will be copied from the source term if
   available.

Forward-port-of: odoo#194181
X-original-commit: 1f90957
robodoo pushed a commit that referenced this pull request Jan 25, 2025
Before:
The typofix feature treats terms in the old and new values with similar text
content as the same term, migrating the translations of the old term to the new
term.

For example

The old value has the mapping:
'Draft': 'Brouillon'

The new value contains the term:
'<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>'

Since the old term and the new term share the same text content, 'Draft', after
`write`, the new term reuses the old translation of 'Draft'. However, the
translation 'Brouillon' is always visible, unlike its en_US counterpart.

This behavior is acceptable in non-upgrade mode because the user writes the
en_US value and is responsible for verifying translations afterward. However, it
is problematic during upgrades because users cannot easily identify which
records have changed and need to be rechecked.

After:
'state' is removed from MODIFIER_ATTRS since it is not customized by Odoo

The translation inheritance behavior can be described as below
Translations can be inherited after `write` from old terms to new terms which
share the very close text contents
1. when `write` in production mode, text contents for translation terms are more
   important than the HTML/XML structures of them, and the old term translations
   should be remained as much as possible. Because
    * the writing user is responsible to recheck all translations after `write`.
    * it is easier for the writing user to copy technical HTML/XML structures
      than translate text contents for a language they may not know.
    * the feature can also be used as typofix when the only small diff is the
      text content
2. when `write` in upgrade time, the HTML/XML structure is more important than
   the text content, and the new term structure should be remained as much as
   possible. Because
    * HTML/XML structures might be changed a lot after upgrade, which may
      contain behavior relevant diff (e.g. `invisible`), even if text contents
      are not changed.
    * users have no idea which records' values are changed during upgrade and
      are hard to recheck their translations.
    * new terms are highly likely to be correctly translated in the latest po
      files which will be imported during upgrade.
    * the typofix feature can still be remained when the only small diff is the
      text content

Based on the above feature analysis, we use the below new strategy
1. translations can be inherited only if the old source term and the new source
   term share the same HTML/XML structure
2. translations can be inherited only if the old translation term and the new
   source term share the same HTML/XML structure
3. when translations are inherited, MODIFIER_ATTRS will be synchronized with
   the new source term, other attributes will be copied from the source term if
   available.

closes #195170

Forward-port-of: #194181
X-original-commit: 1f90957
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Chong Wang (cwg) <cwg@odoo.com>
adhoc-cicd-bot pushed a commit to adhoc-cicd/odoo-odoo that referenced this pull request Jan 26, 2025
Before:
The typofix feature treats terms in the old and new values with similar text
content as the same term, migrating the translations of the old term to the new
term.

For example

The old value has the mapping:
'Draft': 'Brouillon'

The new value contains the term:
'<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>'

Since the old term and the new term share the same text content, 'Draft', after
`write`, the new term reuses the old translation of 'Draft'. However, the
translation 'Brouillon' is always visible, unlike its en_US counterpart.

This behavior is acceptable in non-upgrade mode because the user writes the
en_US value and is responsible for verifying translations afterward. However, it
is problematic during upgrades because users cannot easily identify which
records have changed and need to be rechecked.

After:
'state' is removed from MODIFIER_ATTRS since it is not customized by Odoo

The translation inheritance behavior can be described as below
Translations can be inherited after `write` from old terms to new terms which
share the very close text contents
1. when `write` in production mode, text contents for translation terms are more
   important than the HTML/XML structures of them, and the old term translations
   should be remained as much as possible. Because
    * the writing user is responsible to recheck all translations after `write`.
    * it is easier for the writing user to copy technical HTML/XML structures
      than translate text contents for a language they may not know.
    * the feature can also be used as typofix when the only small diff is the
      text content
2. when `write` in upgrade time, the HTML/XML structure is more important than
   the text content, and the new term structure should be remained as much as
   possible. Because
    * HTML/XML structures might be changed a lot after upgrade, which may
      contain behavior relevant diff (e.g. `invisible`), even if text contents
      are not changed.
    * users have no idea which records' values are changed during upgrade and
      are hard to recheck their translations.
    * new terms are highly likely to be correctly translated in the latest po
      files which will be imported during upgrade.
    * the typofix feature can still be remained when the only small diff is the
      text content

Based on the above feature analysis, we use the below new strategy
1. translations can be inherited only if the old source term and the new source
   term share the same HTML/XML structure
2. translations can be inherited only if the old translation term and the new
   source term share the same HTML/XML structure
3. when translations are inherited, MODIFIER_ATTRS will be synchronized with
   the new source term, other attributes will be copied from the source term if
   available.

closes odoo#195055

Forward-port-of: odoo#194181
X-original-commit: 90aa858
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Chong Wang (cwg) <cwg@odoo.com>
adhoc-cicd-bot pushed a commit to adhoc-cicd/odoo-odoo that referenced this pull request Jan 27, 2025
Before:
The typofix feature treats terms in the old and new values with similar text
content as the same term, migrating the translations of the old term to the new
term.

For example

The old value has the mapping:
'Draft': 'Brouillon'

The new value contains the term:
'<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>'

Since the old term and the new term share the same text content, 'Draft', after
`write`, the new term reuses the old translation of 'Draft'. However, the
translation 'Brouillon' is always visible, unlike its en_US counterpart.

This behavior is acceptable in non-upgrade mode because the user writes the
en_US value and is responsible for verifying translations afterward. However, it
is problematic during upgrades because users cannot easily identify which
records have changed and need to be rechecked.

After:
The translation inheritance behavior can be described as below
Translations can be inherited after `write` from old terms to new terms which
share the very close text contents
1. when `write` in production mode, text contents for translation terms are more
   important than the HTML/XML structures of them, and the old term translations
   should be remained as much as possible. Because
    * the writing user is responsible to recheck all translations after `write`.
    * it is easier for the writing user to copy technical HTML/XML structures
      than translate text contents for a language they may not know.
    * the feature can also be used as typofix when the only small diff is the
      text content
2. when `write` in upgrade time, the HTML/XML structure is more important than
   the text content, and the new term structure should be remained as much as
   possible. Because
    * HTML/XML structures might be changed a lot after upgrade, which may
      contain behavior relevant diff (e.g. `invisible`), even if text contents
      are not changed.
    * users have no idea which records' values are changed during upgrade and
      are hard to recheck their translations.
    * new terms are highly likely to be correctly translated in the latest po
      files which will be imported during upgrade.
    * the typofix feature can still be remained when the only small diff is the
      text content

Based on the above feature analysis, we use the below new strategy
1. translations can be inherited only if the old source term and the new source
   term share the same HTML/XML structure
2. translations can be inherited only if the old translation term and the new
   source term share the same HTML/XML structure
3. when translations are inherited, MODIFIER_ATTRS will be synchronized with
   the new source term, other attributes will be copied from the source term if
   available.

closes odoo#194186

Backward-port-of: odoo#194181
Backward-port-of: odoo#150152
Signed-off-by: Raphael Collet <rco@odoo.com>
adhoc-cicd-bot pushed a commit to adhoc-cicd/odoo-odoo that referenced this pull request Jan 27, 2025
Before:
The typofix feature treats terms in the old and new values with similar text
content as the same term, migrating the translations of the old term to the new
term.

For example

The old value has the mapping:
'Draft': 'Brouillon'

The new value contains the term:
'<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>'

Since the old term and the new term share the same text content, 'Draft', after
`write`, the new term reuses the old translation of 'Draft'. However, the
translation 'Brouillon' is always visible, unlike its en_US counterpart.

This behavior is acceptable in non-upgrade mode because the user writes the
en_US value and is responsible for verifying translations afterward. However, it
is problematic during upgrades because users cannot easily identify which
records have changed and need to be rechecked.

After:
The translation inheritance behavior can be described as below
Translations can be inherited after `write` from old terms to new terms which
share the very close text contents
1. when `write` in production mode, text contents for translation terms are more
   important than the HTML/XML structures of them, and the old term translations
   should be remained as much as possible. Because
    * the writing user is responsible to recheck all translations after `write`.
    * it is easier for the writing user to copy technical HTML/XML structures
      than translate text contents for a language they may not know.
    * the feature can also be used as typofix when the only small diff is the
      text content
2. when `write` in upgrade time, the HTML/XML structure is more important than
   the text content, and the new term structure should be remained as much as
   possible. Because
    * HTML/XML structures might be changed a lot after upgrade, which may
      contain behavior relevant diff (e.g. `invisible`), even if text contents
      are not changed.
    * users have no idea which records' values are changed during upgrade and
      are hard to recheck their translations.
    * new terms are highly likely to be correctly translated in the latest po
      files which will be imported during upgrade.
    * the typofix feature can still be remained when the only small diff is the
      text content

Based on the above feature analysis, we use the below new strategy
1. translations can be inherited only if the old source term and the new source
   term share the same HTML/XML structure
2. translations can be inherited only if the old translation term and the new
   source term share the same HTML/XML structure
3. when translations are inherited, MODIFIER_ATTRS will be synchronized with
   the new source term, other attributes will be copied from the source term if
   available.

closes odoo#194186

Backward-port-of: odoo#194181
Backward-port-of: odoo#150152
Signed-off-by: Raphael Collet <rco@odoo.com>
adhoc-cicd-bot pushed a commit to adhoc-cicd/odoo-odoo that referenced this pull request Jan 28, 2025
Before:
The typofix feature treats terms in the old and new values with similar text
content as the same term, migrating the translations of the old term to the new
term.

For example

The old value has the mapping:
'Draft': 'Brouillon'

The new value contains the term:
'<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>'

Since the old term and the new term share the same text content, 'Draft', after
`write`, the new term reuses the old translation of 'Draft'. However, the
translation 'Brouillon' is always visible, unlike its en_US counterpart.

This behavior is acceptable in non-upgrade mode because the user writes the
en_US value and is responsible for verifying translations afterward. However, it
is problematic during upgrades because users cannot easily identify which
records have changed and need to be rechecked.

After:
The translation inheritance behavior can be described as below
Translations can be inherited after `write` from old terms to new terms which
share the very close text contents
1. when `write` in production mode, text contents for translation terms are more
   important than the HTML/XML structures of them, and the old term translations
   should be remained as much as possible. Because
    * the writing user is responsible to recheck all translations after `write`.
    * it is easier for the writing user to copy technical HTML/XML structures
      than translate text contents for a language they may not know.
    * the feature can also be used as typofix when the only small diff is the
      text content
2. when `write` in upgrade time, the HTML/XML structure is more important than
   the text content, and the new term structure should be remained as much as
   possible. Because
    * HTML/XML structures might be changed a lot after upgrade, which may
      contain behavior relevant diff (e.g. `invisible`), even if text contents
      are not changed.
    * users have no idea which records' values are changed during upgrade and
      are hard to recheck their translations.
    * new terms are highly likely to be correctly translated in the latest po
      files which will be imported during upgrade.
    * the typofix feature can still be remained when the only small diff is the
      text content

Based on the above feature analysis, we use the below new strategy
1. translations can be inherited only if the old source term and the new source
   term share the same HTML/XML structure
2. translations can be inherited only if the old translation term and the new
   source term share the same HTML/XML structure
3. when translations are inherited, MODIFIER_ATTRS will be synchronized with
   the new source term, other attributes will be copied from the source term if
   available.

closes odoo#194186

Backward-port-of: odoo#194181
Backward-port-of: odoo#150152
Signed-off-by: Raphael Collet <rco@odoo.com>
adhoc-cicd-bot pushed a commit to adhoc-cicd/odoo-odoo that referenced this pull request Jan 29, 2025
Before:
The typofix feature treats terms in the old and new values with similar text
content as the same term, migrating the translations of the old term to the new
term.

For example

The old value has the mapping:
'Draft': 'Brouillon'

The new value contains the term:
'<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>'

Since the old term and the new term share the same text content, 'Draft', after
`write`, the new term reuses the old translation of 'Draft'. However, the
translation 'Brouillon' is always visible, unlike its en_US counterpart.

This behavior is acceptable in non-upgrade mode because the user writes the
en_US value and is responsible for verifying translations afterward. However, it
is problematic during upgrades because users cannot easily identify which
records have changed and need to be rechecked.

After:
'state' is removed from MODIFIER_ATTRS since it is not customized by Odoo

The translation inheritance behavior can be described as below
Translations can be inherited after `write` from old terms to new terms which
share the very close text contents
1. when `write` in production mode, text contents for translation terms are more
   important than the HTML/XML structures of them, and the old term translations
   should be remained as much as possible. Because
    * the writing user is responsible to recheck all translations after `write`.
    * it is easier for the writing user to copy technical HTML/XML structures
      than translate text contents for a language they may not know.
    * the feature can also be used as typofix when the only small diff is the
      text content
2. when `write` in upgrade time, the HTML/XML structure is more important than
   the text content, and the new term structure should be remained as much as
   possible. Because
    * HTML/XML structures might be changed a lot after upgrade, which may
      contain behavior relevant diff (e.g. `invisible`), even if text contents
      are not changed.
    * users have no idea which records' values are changed during upgrade and
      are hard to recheck their translations.
    * new terms are highly likely to be correctly translated in the latest po
      files which will be imported during upgrade.
    * the typofix feature can still be remained when the only small diff is the
      text content

Based on the above feature analysis, we use the below new strategy
1. translations can be inherited only if the old source term and the new source
   term share the same HTML/XML structure
2. translations can be inherited only if the old translation term and the new
   source term share the same HTML/XML structure
3. when translations are inherited, MODIFIER_ATTRS will be synchronized with
   the new source term, other attributes will be copied from the source term if
   available.

closes odoo#195055

Forward-port-of: odoo#194181
X-original-commit: 90aa858
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Chong Wang (cwg) <cwg@odoo.com>
adhoc-cicd-bot pushed a commit to adhoc-cicd/odoo-odoo that referenced this pull request Jan 29, 2025
Before:
The typofix feature treats terms in the old and new values with similar text
content as the same term, migrating the translations of the old term to the new
term.

For example

The old value has the mapping:
'Draft': 'Brouillon'

The new value contains the term:
'<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>'

Since the old term and the new term share the same text content, 'Draft', after
`write`, the new term reuses the old translation of 'Draft'. However, the
translation 'Brouillon' is always visible, unlike its en_US counterpart.

This behavior is acceptable in non-upgrade mode because the user writes the
en_US value and is responsible for verifying translations afterward. However, it
is problematic during upgrades because users cannot easily identify which
records have changed and need to be rechecked.

After:
'state' is removed from MODIFIER_ATTRS since it is not customized by Odoo

The translation inheritance behavior can be described as below
Translations can be inherited after `write` from old terms to new terms which
share the very close text contents
1. when `write` in production mode, text contents for translation terms are more
   important than the HTML/XML structures of them, and the old term translations
   should be remained as much as possible. Because
    * the writing user is responsible to recheck all translations after `write`.
    * it is easier for the writing user to copy technical HTML/XML structures
      than translate text contents for a language they may not know.
    * the feature can also be used as typofix when the only small diff is the
      text content
2. when `write` in upgrade time, the HTML/XML structure is more important than
   the text content, and the new term structure should be remained as much as
   possible. Because
    * HTML/XML structures might be changed a lot after upgrade, which may
      contain behavior relevant diff (e.g. `invisible`), even if text contents
      are not changed.
    * users have no idea which records' values are changed during upgrade and
      are hard to recheck their translations.
    * new terms are highly likely to be correctly translated in the latest po
      files which will be imported during upgrade.
    * the typofix feature can still be remained when the only small diff is the
      text content

Based on the above feature analysis, we use the below new strategy
1. translations can be inherited only if the old source term and the new source
   term share the same HTML/XML structure
2. translations can be inherited only if the old translation term and the new
   source term share the same HTML/XML structure
3. when translations are inherited, MODIFIER_ATTRS will be synchronized with
   the new source term, other attributes will be copied from the source term if
   available.

closes odoo#195055

Forward-port-of: odoo#194181
X-original-commit: 90aa858
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Chong Wang (cwg) <cwg@odoo.com>
StephaneMangin pushed a commit to camptocamp/odoo that referenced this pull request Feb 6, 2025
Before:
The typofix feature treats terms in the old and new values with similar text
content as the same term, migrating the translations of the old term to the new
term.

For example

The old value has the mapping:
'Draft': 'Brouillon'

The new value contains the term:
'<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>'

Since the old term and the new term share the same text content, 'Draft', after
`write`, the new term reuses the old translation of 'Draft'. However, the
translation 'Brouillon' is always visible, unlike its en_US counterpart.

This behavior is acceptable in non-upgrade mode because the user writes the
en_US value and is responsible for verifying translations afterward. However, it
is problematic during upgrades because users cannot easily identify which
records have changed and need to be rechecked.

After:
'state' is removed from MODIFIER_ATTRS since it is not customized by Odoo

The translation inheritance behavior can be described as below
Translations can be inherited after `write` from old terms to new terms which
share the very close text contents
1. when `write` in production mode, text contents for translation terms are more
   important than the HTML/XML structures of them, and the old term translations
   should be remained as much as possible. Because
    * the writing user is responsible to recheck all translations after `write`.
    * it is easier for the writing user to copy technical HTML/XML structures
      than translate text contents for a language they may not know.
    * the feature can also be used as typofix when the only small diff is the
      text content
2. when `write` in upgrade time, the HTML/XML structure is more important than
   the text content, and the new term structure should be remained as much as
   possible. Because
    * HTML/XML structures might be changed a lot after upgrade, which may
      contain behavior relevant diff (e.g. `invisible`), even if text contents
      are not changed.
    * users have no idea which records' values are changed during upgrade and
      are hard to recheck their translations.
    * new terms are highly likely to be correctly translated in the latest po
      files which will be imported during upgrade.
    * the typofix feature can still be remained when the only small diff is the
      text content

Based on the above feature analysis, we use the below new strategy
1. translations can be inherited only if the old source term and the new source
   term share the same HTML/XML structure
2. translations can be inherited only if the old translation term and the new
   source term share the same HTML/XML structure
3. when translations are inherited, MODIFIER_ATTRS will be synchronized with
   the new source term, other attributes will be copied from the source term if
   available.

closes odoo#195055

Forward-port-of: odoo#194181
X-original-commit: 90aa858
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Chong Wang (cwg) <cwg@odoo.com>
@fw-bot fw-bot deleted the 17.0-disable-upgrade-xml-typofix-cwg branch February 7, 2025 13:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

RD research & development, internal work

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants