-
Couldn't load subscription status.
- Fork 30.2k
[FIX] core: inherit translations better when upgrade #194181
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FIX] core: inherit translations better when upgrade #194181
Conversation
There was a problem hiding this 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.
edd470f to
2bebeb3
Compare
489e8a1 to
e6c8256
Compare
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.
e6c8256 to
cc01f5d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Nice work!
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
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>
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
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>
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
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>
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
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>
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>
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>
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>
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
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>
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>
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>
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>
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>
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>
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>
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>

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', afterwrite, the new term reuses the old translation of 'Draft'. However, thetranslation
'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
writefrom old terms to new terms whichshare the very close text contents
writein production mode, text contents for translation terms are moreimportant than the HTML/XML structures of them, and the old term translations
should be remained as much as possible. Because
write.than translate text contents for a language they may not know.
text content
writein upgrade time, the HTML/XML structure is more important thanthe text content, and the new term structure should be remained as much as
possible. Because
contain behavior relevant diff (e.g.
invisible), even if text contentsare not changed.
are hard to recheck their translations.
files which will be imported during upgrade.
text content
Based on the above feature analysis, we use the below new strategy
term share the same HTML/XML structure
source term share the same HTML/XML structure
the new source term, other attributes will be copied from the source term if
available.