[xwiki-devs] [BackwardCompatibility] Breakage in translations for Copy/Rename/Move
Hi devs, The story ======== 1) We introduced some new translations keys in https://github.com/xwiki/xwiki-platform/commit/5c50e2e88bb7cf592c1ecedcf0f34... That was done in XWIKI-12431 (Adapt the "rename" action for nested documents), i.e. in 7.2M3 2) We modified the keys in https://github.com/xwiki/xwiki-platform/commit/12ec17d1c486935162581d47bbf10... That was done in XWIKI-13067 ("Rename: Change the label to make it clear that both links and backlinks are updated or have 2 separate options”), i.e. in XWiki 8.0-rc-1, 7.4.3 3) The consequence is that all translations got broken, resulting in problems such as http://jira.xwiki.org/browse/XINFRA-219. However this issue reports the issue only for French but it’s likely that it broke the translations for other languages. The learnings =========== 1) We must never change the format of existing translation keys. This is the equivalent of breaking an API. Instead we need to go through deprecation of existing keys and introduction of new keys, even though it’s a pain. http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTranslat... would probably benefit from additional explanations too. 2) We would need a tool in the quality profile of our build/CI that would break the build if someone changes the format of a translation.Easiest would be a tool that compares the English translations on master vs the last released version and breaks if there’s a difference in parameter (i.e. {N} syntax). 3) We need to decide if A) we keep the current change done in XWIKI-13067 or B) revert them and revert/adapt the changes already brought to some translations keys (as it was done for FR). For this we need to evaluate the extent of the damage. Any volunteer for 3)? :) Thanks -Vincent
On Thu, Dec 8, 2016 at 1:46 PM, Vincent Massol <[email protected]> wrote:
Hi devs,
The story ========
1) We introduced some new translations keys in https://github.com/xwiki/xwiki-platform/commit/5c50e2e88bb7cf592c1ecedcf0f34...
That was done in XWIKI-12431 (Adapt the "rename" action for nested documents), i.e. in 7.2M3
2) We modified the keys in https://github.com/xwiki/xwiki-platform/commit/12ec17d1c486935162581d47bbf10...
That was done in XWIKI-13067 ("Rename: Change the label to make it clear that both links and backlinks are updated or have 2 separate options”), i.e. in XWiki 8.0-rc-1, 7.4.3
3) The consequence is that all translations got broken, resulting in problems such as http://jira.xwiki.org/browse/XINFRA-219. However this issue reports the issue only for French but it’s likely that it broke the translations for other languages.
The learnings ===========
1) We must never change the format of existing translation keys. This is the equivalent of breaking an API. Instead we need to go through deprecation of existing keys and introduction of new keys, even though it’s a pain. http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTranslat... would probably benefit from additional explanations too.
Well this is not really new and it's already our rule.
2) We would need a tool in the quality profile of our build/CI that would break the build if someone changes the format of a translation.Easiest would be a tool that compares the English translations on master vs the last released version and breaks if there’s a difference in parameter (i.e. {N} syntax).
3) We need to decide if A) we keep the current change done in XWIKI-13067 or B) revert them and revert/adapt the changes already brought to some translations keys (as it was done for FR). For this we need to evaluate the extent of the damage.
Any volunteer for 3)? :)
Thanks -Vincent
-- Thomas Mortagne
On 8 Dec 2016, at 14:01, Thomas Mortagne <[email protected]> wrote:
On Thu, Dec 8, 2016 at 1:46 PM, Vincent Massol <[email protected]> wrote:
Hi devs,
The story ========
1) We introduced some new translations keys in https://github.com/xwiki/xwiki-platform/commit/5c50e2e88bb7cf592c1ecedcf0f34...
That was done in XWIKI-12431 (Adapt the "rename" action for nested documents), i.e. in 7.2M3
2) We modified the keys in https://github.com/xwiki/xwiki-platform/commit/12ec17d1c486935162581d47bbf10...
That was done in XWIKI-13067 ("Rename: Change the label to make it clear that both links and backlinks are updated or have 2 separate options”), i.e. in XWiki 8.0-rc-1, 7.4.3
3) The consequence is that all translations got broken, resulting in problems such as http://jira.xwiki.org/browse/XINFRA-219. However this issue reports the issue only for French but it’s likely that it broke the translations for other languages.
The learnings ===========
1) We must never change the format of existing translation keys. This is the equivalent of breaking an API. Instead we need to go through deprecation of existing keys and introduction of new keys, even though it’s a pain. http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTranslat... would probably benefit from additional explanations too.
Well this is not really new and it's already our rule.
That’s precisely my point! It’s our rule but it’s not documented. Thanks -Vincent
2) We would need a tool in the quality profile of our build/CI that would break the build if someone changes the format of a translation.Easiest would be a tool that compares the English translations on master vs the last released version and breaks if there’s a difference in parameter (i.e. {N} syntax).
3) We need to decide if A) we keep the current change done in XWIKI-13067 or B) revert them and revert/adapt the changes already brought to some translations keys (as it was done for FR). For this we need to evaluate the extent of the damage.
Any volunteer for 3)? :)
Thanks -Vincent
-- Thomas Mortagne
On Thu, Dec 8, 2016 at 2:03 PM, Vincent Massol <[email protected]> wrote:
On 8 Dec 2016, at 14:01, Thomas Mortagne <[email protected]> wrote:
On Thu, Dec 8, 2016 at 1:46 PM, Vincent Massol <[email protected]> wrote:
Hi devs,
The story ========
1) We introduced some new translations keys in https://github.com/xwiki/xwiki-platform/commit/5c50e2e88bb7cf592c1ecedcf0f34...
That was done in XWIKI-12431 (Adapt the "rename" action for nested documents), i.e. in 7.2M3
2) We modified the keys in https://github.com/xwiki/xwiki-platform/commit/12ec17d1c486935162581d47bbf10...
That was done in XWIKI-13067 ("Rename: Change the label to make it clear that both links and backlinks are updated or have 2 separate options”), i.e. in XWiki 8.0-rc-1, 7.4.3
3) The consequence is that all translations got broken, resulting in problems such as http://jira.xwiki.org/browse/XINFRA-219. However this issue reports the issue only for French but it’s likely that it broke the translations for other languages.
The learnings ===========
1) We must never change the format of existing translation keys. This is the equivalent of breaking an API. Instead we need to go through deprecation of existing keys and introduction of new keys, even though it’s a pain. http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTranslat... would probably benefit from additional explanations too.
Well this is not really new and it's already our rule.
That’s precisely my point! It’s our rule but it’s not documented.
It's possible it's documented only in ApplicationResource.properties file yes. I guess we forgot to document it when http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTranslat... section was created.
Thanks -Vincent
2) We would need a tool in the quality profile of our build/CI that would break the build if someone changes the format of a translation.Easiest would be a tool that compares the English translations on master vs the last released version and breaks if there’s a difference in parameter (i.e. {N} syntax).
3) We need to decide if A) we keep the current change done in XWIKI-13067 or B) revert them and revert/adapt the changes already brought to some translations keys (as it was done for FR). For this we need to evaluate the extent of the damage.
Any volunteer for 3)? :)
Thanks -Vincent
-- Thomas Mortagne
-- Thomas Mortagne
This has been there for a loooong time: http://dev.xwiki.org/xwiki/bin/Community/L10N+Conventions#HUpdatingtranslati... On 12/08/2016 07:46 AM, Vincent Massol wrote:
Hi devs,
The story ========
1) We introduced some new translations keys in https://github.com/xwiki/xwiki-platform/commit/5c50e2e88bb7cf592c1ecedcf0f34...
That was done in XWIKI-12431 (Adapt the "rename" action for nested documents), i.e. in 7.2M3
2) We modified the keys in https://github.com/xwiki/xwiki-platform/commit/12ec17d1c486935162581d47bbf10...
That was done in XWIKI-13067 ("Rename: Change the label to make it clear that both links and backlinks are updated or have 2 separate options”), i.e. in XWiki 8.0-rc-1, 7.4.3
3) The consequence is that all translations got broken, resulting in problems such as http://jira.xwiki.org/browse/XINFRA-219. However this issue reports the issue only for French but it’s likely that it broke the translations for other languages.
The learnings ===========
1) We must never change the format of existing translation keys. This is the equivalent of breaking an API. Instead we need to go through deprecation of existing keys and introduction of new keys, even though it’s a pain. http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HTranslat... would probably benefit from additional explanations too.
2) We would need a tool in the quality profile of our build/CI that would break the build if someone changes the format of a translation.Easiest would be a tool that compares the English translations on master vs the last released version and breaks if there’s a difference in parameter (i.e. {N} syntax).
3) We need to decide if A) we keep the current change done in XWIKI-13067 or B) revert them and revert/adapt the changes already brought to some translations keys (as it was done for FR). For this we need to evaluate the extent of the damage.
Any volunteer for 3)? :)
Thanks -Vincent
-- Sergiu Dumitriu http://purl.org/net/sergiu
Hi, Now, I`m not sure of all the details, but what I remember is that they were a handful of keys that were recently introduced (Nested Spaces work) and deprecating them did not seem very justified at the time. I considered that we would start dragging them along when they were too young to have been used. I had fixed the FR and NL translations (only ones existing) on l10n.xwiki.org for the rename action, however I did seem to have missed the copy action [1]. The screenshot [2] from the rename action does not really look like the same thing. It seems to be a bad choice of accented characters that needs to be replaced with something standard, something that can happen in any translation and that is not particularly related to the change of the EN key`s value. I am perfectly aware of the general rule and I agree with it. AFAICT, the only affected languages were FR and NL. IMO, the solution is to fix the l10n translations for those languages and include them in the next release of 7.x, 8.x and 9.x. For the supported branches (other than master), if we don`t want to update the translations during the release, we could manually commit the changes in the translation files on git, for the affected keys. Reverting does not make much sense, IMO, since it implies the same, if not more, amount of work to get to a state that still has the original jira issue's problem. WDYT? Thanks, Eduard ---------- [1] http://jira.xwiki.org/secure/attachment/33274/FrTransCopier.jpg [2] http://jira.xwiki.org/secure/attachment/33273/FrTranslationIssue.jpg On Thu, Dec 8, 2016 at 5:03 PM, Sergiu Dumitriu <[email protected]> wrote:
This has been there for a loooong time: http://dev.xwiki.org/xwiki/bin/Community/L10N+Conventions# HUpdatingtranslations
On 12/08/2016 07:46 AM, Vincent Massol wrote:
Hi devs,
The story ========
1) We introduced some new translations keys in https://github.com/xwiki/ xwiki-platform/commit/5c50e2e88bb7cf592c1ecedcf0f34781e1fbc81f#diff- fffbf37334c4d7a178b13f4ccc313f86R746
That was done in XWIKI-12431 (Adapt the "rename" action for nested documents), i.e. in 7.2M3
2) We modified the keys in https://github.com/xwiki/ xwiki-platform/commit/12ec17d1c486935162581d47bbf1077693c401e6
That was done in XWIKI-13067 ("Rename: Change the label to make it clear that both links and backlinks are updated or have 2 separate options”), i.e. in XWiki 8.0-rc-1, 7.4.3
3) The consequence is that all translations got broken, resulting in problems such as http://jira.xwiki.org/browse/XINFRA-219. However this issue reports the issue only for French but it’s likely that it broke the translations for other languages.
The learnings ===========
1) We must never change the format of existing translation keys. This is the equivalent of breaking an API. Instead we need to go through deprecation of existing keys and introduction of new keys, even though it’s a pain. http://dev.xwiki.org/xwiki/bin/view/Community/ DevelopmentPractices#HTranslationBestPractices would probably benefit from additional explanations too.
2) We would need a tool in the quality profile of our build/CI that would break the build if someone changes the format of a translation.Easiest would be a tool that compares the English translations on master vs the last released version and breaks if there’s a difference in parameter (i.e. {N} syntax).
3) We need to decide if A) we keep the current change done in XWIKI-13067 or B) revert them and revert/adapt the changes already brought to some translations keys (as it was done for FR). For this we need to evaluate the extent of the damage.
Any volunteer for 3)? :)
Thanks -Vincent
-- Sergiu Dumitriu http://purl.org/net/sergiu
Hi Edy,
On 8 Dec 2016, at 21:13, Eduard Moraru <[email protected]> wrote:
Hi,
Now, I`m not sure of all the details, but what I remember is that they were a handful of keys that were recently introduced (Nested Spaces work) and deprecating them did not seem very justified at the time.
Well apparently they were quite spaced out from XWiki 7.2M3 to 7.4.3/8.0RC1.
I considered that we would start dragging them along when they were too young to have been used.
I had fixed the FR and NL translations (only ones existing) on l10n.xwiki.org for the rename action, however I did seem to have missed the copy action [1].
Actually I spent some hours fixing the FR translations some week(s) ago as they were broken in the same way as the copy action is now (I’m fixing that, spent some time today to fix stuff on l10n this morning and then got stopped by other things but I’m planning to finish fixing the FR translations). Somehow I introduced some errors when I fixed the FR translations back then, by using the unicode escapes instead of accented characters and this resulted in [2] (which I have fixed this morning). But I didn’t check the other translations. I’ll leave that to you if you’re ok.
The screenshot [2] from the rename action does not really look like the same thing. It seems to be a bad choice of accented characters that needs to be replaced with something standard, something that can happen in any translation and that is not particularly related to the change of the EN key`s value.
I am perfectly aware of the general rule and I agree with it.
AFAICT, the only affected languages were FR and NL.
Could you check that? Note that I had to fix the FR translations a while back to remove the CHOICE constructs since that was not leading to good results in French. I don’t remember the details though.
IMO, the solution is to fix the l10n translations for those languages and include them in the next release of 7.x, 8.x and 9.x. For the supported branches (other than master), if we don`t want to update the translations during the release, we could manually commit the changes in the translation files on git, for the affected keys. Reverting does not make much sense, IMO, since it implies the same, if not more, amount of work to get to a state that still has the original jira issue's problem.
WDYT?
Sure, fine with me if you can handle the non-FR translations and the branches. Thanks! -Vincent
Thanks, Eduard
---------- [1] http://jira.xwiki.org/secure/attachment/33274/FrTransCopier.jpg [2] http://jira.xwiki.org/secure/attachment/33273/FrTranslationIssue.jpg
On Thu, Dec 8, 2016 at 5:03 PM, Sergiu Dumitriu <[email protected]> wrote:
This has been there for a loooong time: http://dev.xwiki.org/xwiki/bin/Community/L10N+Conventions# HUpdatingtranslations
On 12/08/2016 07:46 AM, Vincent Massol wrote:
Hi devs,
The story ========
1) We introduced some new translations keys in https://github.com/xwiki/ xwiki-platform/commit/5c50e2e88bb7cf592c1ecedcf0f34781e1fbc81f#diff- fffbf37334c4d7a178b13f4ccc313f86R746
That was done in XWIKI-12431 (Adapt the "rename" action for nested documents), i.e. in 7.2M3
2) We modified the keys in https://github.com/xwiki/ xwiki-platform/commit/12ec17d1c486935162581d47bbf1077693c401e6
That was done in XWIKI-13067 ("Rename: Change the label to make it clear that both links and backlinks are updated or have 2 separate options”), i.e. in XWiki 8.0-rc-1, 7.4.3
3) The consequence is that all translations got broken, resulting in problems such as http://jira.xwiki.org/browse/XINFRA-219. However this issue reports the issue only for French but it’s likely that it broke the translations for other languages.
The learnings ===========
1) We must never change the format of existing translation keys. This is the equivalent of breaking an API. Instead we need to go through deprecation of existing keys and introduction of new keys, even though it’s a pain. http://dev.xwiki.org/xwiki/bin/view/Community/ DevelopmentPractices#HTranslationBestPractices would probably benefit from additional explanations too.
2) We would need a tool in the quality profile of our build/CI that would break the build if someone changes the format of a translation.Easiest would be a tool that compares the English translations on master vs the last released version and breaks if there’s a difference in parameter (i.e. {N} syntax).
3) We need to decide if A) we keep the current change done in XWIKI-13067 or B) revert them and revert/adapt the changes already brought to some translations keys (as it was done for FR). For this we need to evaluate the extent of the damage.
Any volunteer for 3)? :)
Thanks -Vincent
FYI I’ve now fixed the FR translations and closed http://jira.xwiki.org/browse/XINFRA-219 Thanks -Vincent
On 8 Dec 2016, at 22:36, Vincent Massol <[email protected]> wrote:
Hi Edy,
On 8 Dec 2016, at 21:13, Eduard Moraru <[email protected]> wrote:
Hi,
Now, I`m not sure of all the details, but what I remember is that they were a handful of keys that were recently introduced (Nested Spaces work) and deprecating them did not seem very justified at the time.
Well apparently they were quite spaced out from XWiki 7.2M3 to 7.4.3/8.0RC1.
I considered that we would start dragging them along when they were too young to have been used.
I had fixed the FR and NL translations (only ones existing) on l10n.xwiki.org for the rename action, however I did seem to have missed the copy action [1].
Actually I spent some hours fixing the FR translations some week(s) ago as they were broken in the same way as the copy action is now (I’m fixing that, spent some time today to fix stuff on l10n this morning and then got stopped by other things but I’m planning to finish fixing the FR translations).
Somehow I introduced some errors when I fixed the FR translations back then, by using the unicode escapes instead of accented characters and this resulted in [2] (which I have fixed this morning).
But I didn’t check the other translations. I’ll leave that to you if you’re ok.
The screenshot [2] from the rename action does not really look like the same thing. It seems to be a bad choice of accented characters that needs to be replaced with something standard, something that can happen in any translation and that is not particularly related to the change of the EN key`s value.
I am perfectly aware of the general rule and I agree with it.
AFAICT, the only affected languages were FR and NL.
Could you check that? Note that I had to fix the FR translations a while back to remove the CHOICE constructs since that was not leading to good results in French. I don’t remember the details though.
IMO, the solution is to fix the l10n translations for those languages and include them in the next release of 7.x, 8.x and 9.x. For the supported branches (other than master), if we don`t want to update the translations during the release, we could manually commit the changes in the translation files on git, for the affected keys. Reverting does not make much sense, IMO, since it implies the same, if not more, amount of work to get to a state that still has the original jira issue's problem.
WDYT?
Sure, fine with me if you can handle the non-FR translations and the branches.
Thanks! -Vincent
Thanks, Eduard
---------- [1] http://jira.xwiki.org/secure/attachment/33274/FrTransCopier.jpg [2] http://jira.xwiki.org/secure/attachment/33273/FrTranslationIssue.jpg
On Thu, Dec 8, 2016 at 5:03 PM, Sergiu Dumitriu <[email protected]> wrote:
This has been there for a loooong time: http://dev.xwiki.org/xwiki/bin/Community/L10N+Conventions# HUpdatingtranslations
On 12/08/2016 07:46 AM, Vincent Massol wrote:
Hi devs,
The story ========
1) We introduced some new translations keys in https://github.com/xwiki/ xwiki-platform/commit/5c50e2e88bb7cf592c1ecedcf0f34781e1fbc81f#diff- fffbf37334c4d7a178b13f4ccc313f86R746
That was done in XWIKI-12431 (Adapt the "rename" action for nested documents), i.e. in 7.2M3
2) We modified the keys in https://github.com/xwiki/ xwiki-platform/commit/12ec17d1c486935162581d47bbf1077693c401e6
That was done in XWIKI-13067 ("Rename: Change the label to make it clear that both links and backlinks are updated or have 2 separate options”), i.e. in XWiki 8.0-rc-1, 7.4.3
3) The consequence is that all translations got broken, resulting in problems such as http://jira.xwiki.org/browse/XINFRA-219. However this issue reports the issue only for French but it’s likely that it broke the translations for other languages.
The learnings ===========
1) We must never change the format of existing translation keys. This is the equivalent of breaking an API. Instead we need to go through deprecation of existing keys and introduction of new keys, even though it’s a pain. http://dev.xwiki.org/xwiki/bin/view/Community/ DevelopmentPractices#HTranslationBestPractices would probably benefit from additional explanations too.
2) We would need a tool in the quality profile of our build/CI that would break the build if someone changes the format of a translation.Easiest would be a tool that compares the English translations on master vs the last released version and breaks if there’s a difference in parameter (i.e. {N} syntax).
3) We need to decide if A) we keep the current change done in XWIKI-13067 or B) revert them and revert/adapt the changes already brought to some translations keys (as it was done for FR). For this we need to evaluate the extent of the damage.
Any volunteer for 3)? :)
Thanks -Vincent
On Thu, Dec 8, 2016 at 11:36 PM, Vincent Massol <[email protected]> wrote:
Hi Edy,
On 8 Dec 2016, at 21:13, Eduard Moraru <[email protected]> wrote:
Hi,
Now, I`m not sure of all the details, but what I remember is that they were a handful of keys that were recently introduced (Nested Spaces work) and deprecating them did not seem very justified at the time.
Well apparently they were quite spaced out from XWiki 7.2M3 to 7.4.3/8.0RC1.
I considered that we would start dragging them along when they were too young to have been used.
I had fixed the FR and NL translations (only ones existing) on l10n.xwiki.org for the rename action, however I did seem to have missed the copy action [1].
Actually I spent some hours fixing the FR translations some week(s) ago as they were broken in the same way as the copy action is now (I’m fixing that, spent some time today to fix stuff on l10n this morning and then got stopped by other things but I’m planning to finish fixing the FR translations).
Somehow I introduced some errors when I fixed the FR translations back then, by using the unicode escapes instead of accented characters and this resulted in [2] (which I have fixed this morning).
But I didn’t check the other translations. I’ll leave that to you if you’re ok.
The screenshot [2] from the rename action does not really look like the same thing. It seems to be a bad choice of accented characters that needs to be replaced with something standard, something that can happen in any translation and that is not particularly related to the change of the EN key`s value.
I am perfectly aware of the general rule and I agree with it.
AFAICT, the only affected languages were FR and NL.
Could you check that? Note that I had to fix the FR translations a while back to remove the CHOICE constructs since that was not leading to good results in French. I don’t remember the details though.
IMO, the solution is to fix the l10n translations for those languages and include them in the next release of 7.x, 8.x and 9.x. For the supported branches (other than master), if we don`t want to update the translations during the release, we could manually commit the changes in the translation files on git, for the affected keys. Reverting does not make much sense, IMO, since it implies the same, if not more, amount of work to get to a state that still has the original jira issue's problem.
WDYT?
Sure, fine with me if you can handle the non-FR translations and the branches.
I`ll try to make some time next week to review the affected languages and commit the fixes on the branches. Thanks and sorry for the inconvenience. -Eduard
Thanks! -Vincent
Thanks, Eduard
---------- [1] http://jira.xwiki.org/secure/attachment/33274/FrTransCopier.jpg [2] http://jira.xwiki.org/secure/attachment/33273/FrTranslationIssue.jpg
On Thu, Dec 8, 2016 at 5:03 PM, Sergiu Dumitriu <[email protected]> wrote:
This has been there for a loooong time: http://dev.xwiki.org/xwiki/bin/Community/L10N+Conventions# HUpdatingtranslations
On 12/08/2016 07:46 AM, Vincent Massol wrote:
Hi devs,
The story ========
1) We introduced some new translations keys in https://github.com/xwiki/ xwiki-platform/commit/5c50e2e88bb7cf592c1ecedcf0f34781e1fbc81f#diff- fffbf37334c4d7a178b13f4ccc313f86R746
That was done in XWIKI-12431 (Adapt the "rename" action for nested documents), i.e. in 7.2M3
2) We modified the keys in https://github.com/xwiki/ xwiki-platform/commit/12ec17d1c486935162581d47bbf1077693c401e6
That was done in XWIKI-13067 ("Rename: Change the label to make it clear that both links and backlinks are updated or have 2 separate options”), i.e. in XWiki 8.0-rc-1, 7.4.3
3) The consequence is that all translations got broken, resulting in problems such as http://jira.xwiki.org/browse/XINFRA-219. However this issue reports the issue only for French but it’s likely that it broke the translations for other languages.
The learnings ===========
1) We must never change the format of existing translation keys. This is the equivalent of breaking an API. Instead we need to go through deprecation of existing keys and introduction of new keys, even though it’s a pain. http://dev.xwiki.org/xwiki/bin/view/Community/ DevelopmentPractices#HTranslationBestPractices would probably benefit from additional explanations too.
2) We would need a tool in the quality profile of our build/CI that would break the build if someone changes the format of a translation.Easiest would be a tool that compares the English translations on master vs the last released version and breaks if there’s a difference in parameter (i.e. {N} syntax).
3) We need to decide if A) we keep the current change done in XWIKI-13067 or B) revert them and revert/adapt the changes already brought to some translations keys (as it was done for FR). For this we need to evaluate the extent of the damage.
Any volunteer for 3)? :)
Thanks -Vincent
Fixed on l10n and committed the changes on: - master: https://github.com/xwiki/xwiki-platform/commit/db3aeddd4d3ff2d701fd229e366de... - 8.4.x: https://github.com/xwiki/xwiki-platform/commit/852129096672d5d9b231d2a0012e9... - 7.4.x: https://github.com/xwiki/xwiki-platform/commit/a67736e87e306b1c76d775469a048... On Fri, Dec 9, 2016 at 3:23 PM, Eduard Moraru <[email protected]> wrote:
On Thu, Dec 8, 2016 at 11:36 PM, Vincent Massol <[email protected]> wrote:
Hi Edy,
On 8 Dec 2016, at 21:13, Eduard Moraru <[email protected]> wrote:
Hi,
Now, I`m not sure of all the details, but what I remember is that they were a handful of keys that were recently introduced (Nested Spaces work) and deprecating them did not seem very justified at the time.
Well apparently they were quite spaced out from XWiki 7.2M3 to 7.4.3/8.0RC1.
I considered that we would start dragging them along when they were too young to have been used.
I had fixed the FR and NL translations (only ones existing) on l10n.xwiki.org for the rename action, however I did seem to have missed the copy action [1].
Actually I spent some hours fixing the FR translations some week(s) ago as they were broken in the same way as the copy action is now (I’m fixing that, spent some time today to fix stuff on l10n this morning and then got stopped by other things but I’m planning to finish fixing the FR translations).
Somehow I introduced some errors when I fixed the FR translations back then, by using the unicode escapes instead of accented characters and this resulted in [2] (which I have fixed this morning).
But I didn’t check the other translations. I’ll leave that to you if you’re ok.
The screenshot [2] from the rename action does not really look like the same thing. It seems to be a bad choice of accented characters that needs to be replaced with something standard, something that can happen in any translation and that is not particularly related to the change of the EN key`s value.
I am perfectly aware of the general rule and I agree with it.
AFAICT, the only affected languages were FR and NL.
Could you check that? Note that I had to fix the FR translations a while back to remove the CHOICE constructs since that was not leading to good results in French. I don’t remember the details though.
IMO, the solution is to fix the l10n translations for those languages and include them in the next release of 7.x, 8.x and 9.x. For the supported branches (other than master), if we don`t want to update the translations during the release, we could manually commit the changes in the translation files on git, for the affected keys. Reverting does not make much sense, IMO, since it implies the same, if not more, amount of work to get to a state that still has the original jira issue's problem.
WDYT?
Sure, fine with me if you can handle the non-FR translations and the branches.
I`ll try to make some time next week to review the affected languages and commit the fixes on the branches.
Thanks and sorry for the inconvenience.
-Eduard
Thanks! -Vincent
Thanks, Eduard
---------- [1] http://jira.xwiki.org/secure/attachment/33274/FrTransCopier.jpg [2] http://jira.xwiki.org/secure/attachment/33273/FrTranslationI ssue.jpg
On Thu, Dec 8, 2016 at 5:03 PM, Sergiu Dumitriu <[email protected]> wrote:
This has been there for a loooong time: http://dev.xwiki.org/xwiki/bin/Community/L10N+Conventions# HUpdatingtranslations
On 12/08/2016 07:46 AM, Vincent Massol wrote:
Hi devs,
The story ========
1) We introduced some new translations keys in https://github.com/xwiki/ xwiki-platform/commit/5c50e2e88bb7cf592c1ecedcf0f34781e1fbc81f#diff- fffbf37334c4d7a178b13f4ccc313f86R746
That was done in XWIKI-12431 (Adapt the "rename" action for nested documents), i.e. in 7.2M3
2) We modified the keys in https://github.com/xwiki/ xwiki-platform/commit/12ec17d1c486935162581d47bbf1077693c401e6
That was done in XWIKI-13067 ("Rename: Change the label to make it clear that both links and backlinks are updated or have 2 separate options”), i.e. in XWiki 8.0-rc-1, 7.4.3
3) The consequence is that all translations got broken, resulting in problems such as http://jira.xwiki.org/browse/XINFRA-219. However this issue reports the issue only for French but it’s likely that it broke the translations for other languages.
The learnings ===========
1) We must never change the format of existing translation keys. This is the equivalent of breaking an API. Instead we need to go through deprecation of existing keys and introduction of new keys, even though it’s a pain. http://dev.xwiki.org/xwiki/bin/view/Community/ DevelopmentPractices#HTranslationBestPractices would probably benefit from additional explanations too.
2) We would need a tool in the quality profile of our build/CI that would break the build if someone changes the format of a translation.Easiest would be a tool that compares the English translations on master vs the last released version and breaks if there’s a difference in parameter (i.e. {N} syntax).
3) We need to decide if A) we keep the current change done in XWIKI-13067 or B) revert them and revert/adapt the changes already brought to some translations keys (as it was done for FR). For this we need to evaluate the extent of the damage.
Any volunteer for 3)? :)
Thanks -Vincent
participants (4)
-
Eduard Moraru -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol