Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-25684

Improved Version Management of Multilingual Content

    Details

    • Epic Name:
      Language Management

      Description

      Currently there is no way to remove translation of an object, using the Admin Interface, without removing the whole object.

        Issue Links

          Issues in Epic

            Activity

            Hide
            Io Sol Inf added a comment -

            Hi.
            Is removing of a translation supported by the API? I cannot find any methods for it...

            Show
            Io Sol Inf added a comment - Hi. Is removing of a translation supported by the API? I cannot find any methods for it...
            Hide
            Andrzej Longosz added a comment -
            Show
            Andrzej Longosz added a comment - Proposed spec for PHP API ( EZP-27417 ) https://github.com/ezsystems/ezpublish-kernel/pull/2001
            Hide
            Andrzej Longosz added a comment -

            As the result of the discussion in the mentioned PR we separated PHP API stories:

            • EZP-27417 - remove the translation from all the Versions
            • EZP-27508 - remove the translation from a single Version and return Content Object Draft.
            Show
            Andrzej Longosz added a comment - As the result of the discussion in the mentioned PR we separated PHP API stories: EZP-27417 - remove the translation from all the Versions EZP-27508 - remove the translation from a single Version and return Content Object Draft.
            Hide
            Damien Pobel (Inactive) added a comment -

            Sylvain Guittard Roland Benedetti I've read carefully the spec.

            I have several questions/remarks in terms of UI. But before that, I just want to point out that API requirements are not ready yet. For the story about completely removing a language we are soon there it seems (EZP-27752) but for the biggest part where we act on versions, according to EZP-27508, this is not even started. Of course, we can start working on the UI but until the API is there, not much will happen in the Repository. For restoring an archived version, I need to check the behavior of the API (and/or available REST API endpoints).

            That said, here are some remarks:

            • given removing a language from a Version or from a Content item is irreversible, shouldn't we ask for a confirmation before proceeding ?
            • it's not mentioned anywhere but I guess after removing a language from a Version, we should reload only the Version tab. But what happen if for whatever reason the operation fails ?
            • after completely removing a language, I guess we refresh the "whole page" ? same question on error handling
            • is it possible to remove the main language of a Content (well the question is both from an API point of view and a user point of view)
            • for the restore archived version feature, when reading the document, I have the impression that after publishing you expect the user to be redirected to the Content but with the Version tab selected, is that the case ?

            In any case, the list of identified tasks seems correct (some technical ones like updating the JavaScript REST client are missing). Can someone please create the corresponding stories with a description and answer(s) to the questions above?

            Show
            Damien Pobel (Inactive) added a comment - Sylvain Guittard Roland Benedetti I've read carefully the spec. I have several questions/remarks in terms of UI. But before that, I just want to point out that API requirements are not ready yet. For the story about completely removing a language we are soon there it seems ( EZP-27752 ) but for the biggest part where we act on versions, according to EZP-27508 , this is not even started. Of course, we can start working on the UI but until the API is there, not much will happen in the Repository. For restoring an archived version, I need to check the behavior of the API (and/or available REST API endpoints). That said, here are some remarks: given removing a language from a Version or from a Content item is irreversible, shouldn't we ask for a confirmation before proceeding ? it's not mentioned anywhere but I guess after removing a language from a Version, we should reload only the Version tab. But what happen if for whatever reason the operation fails ? after completely removing a language, I guess we refresh the "whole page" ? same question on error handling is it possible to remove the main language of a Content (well the question is both from an API point of view and a user point of view) for the restore archived version feature, when reading the document, I have the impression that after publishing you expect the user to be redirected to the Content but with the Version tab selected, is that the case ? In any case, the list of identified tasks seems correct (some technical ones like updating the JavaScript REST client are missing). Can someone please create the corresponding stories with a description and answer(s) to the questions above?
            Hide
            Andrzej Longosz added a comment -

            is it possible to remove the main language of a Content (well the question is both from an API point of view and a user point of view)

            PHP API removeTranslation will throw an exception in this case. Given I don't see any UI related to main language changes, I could do it inside REST endpoint controller. However there is no clear way which language to choose as the main one (I'm thinking about the case when Content Versions in total have at least 3 Translations).

            Show
            Andrzej Longosz added a comment - is it possible to remove the main language of a Content (well the question is both from an API point of view and a user point of view) PHP API removeTranslation will throw an exception in this case. Given I don't see any UI related to main language changes, I could do it inside REST endpoint controller. However there is no clear way which language to choose as the main one (I'm thinking about the case when Content Versions in total have at least 3 Translations).
            Hide
            Roland Benedetti added a comment -

            To [~damien.pobel@ez.no] feedback

            given removing a language from a Version or from a Content item is irreversible, shouldn't we ask for a confirmation before proceeding ?

            Answer is yes for the "remove permanently all versions", it is stated in the scenario (though no mockup has been given, as we should use standard modal confirmation).
            I would say no for the "remove a version" because this is actually reversible (as explained, the remove creates a new draft where the language version is just detached, but previous archived versions still have them). If the user does this, he can then just go back to the previous version and restore it.

            it's not mentioned anywhere but I guess after removing a language from a Version, we should reload only the Version tab. But what happen if for whatever reason the operation fails ?

            Indeed we should reload the Version tab, no strong feeling if this means reloading everything, just the subtabs, all the subtabs, we should do the simplest but the user needs to land on the version view for sure.
            Error handling: we'll need to define the error message. Is it a transaction and can we rollback or is there a chance that it really fails in the middle of something?
            If so we should go back to the original state if we can.

            after completely removing a language, I guess we refresh the "whole page" ? same question on error handling

            removing a language is in the action bar and can happen at many places (from the different subtabs), ideally we reload the whole content view, keep it open on the same tab the user was on.

            is it possible to remove the main language of a Content (well the question is both from an API point of view and a user point of view)

            from a u.i. point of view, it's not possible to remove a language if there is only one. from a u.i. standpoint, there is no concept of main language in eZ Platform, which makes things a bit tricky. I think this imply that we need to define a rule of reassigning the main language in the repository when it might be removed.

            for the restore archived version feature, when reading the document, I have the impression that after publishing you expect the user to be redirected to the Content but with the Version tab selected, is that the case ?

            no, the restore archived version works just like the current "create from draft" feature, except that it lets the user explicitely choose the language (which is totally missleading in current state), so basically, after clicking restore, it opens the edit mode of a new draft for this language.

            Show
            Roland Benedetti added a comment - To [~damien.pobel@ez.no] feedback given removing a language from a Version or from a Content item is irreversible, shouldn't we ask for a confirmation before proceeding ? Answer is yes for the "remove permanently all versions", it is stated in the scenario (though no mockup has been given, as we should use standard modal confirmation). I would say no for the "remove a version" because this is actually reversible (as explained, the remove creates a new draft where the language version is just detached, but previous archived versions still have them). If the user does this, he can then just go back to the previous version and restore it. it's not mentioned anywhere but I guess after removing a language from a Version, we should reload only the Version tab. But what happen if for whatever reason the operation fails ? Indeed we should reload the Version tab, no strong feeling if this means reloading everything, just the subtabs, all the subtabs, we should do the simplest but the user needs to land on the version view for sure. Error handling: we'll need to define the error message. Is it a transaction and can we rollback or is there a chance that it really fails in the middle of something? If so we should go back to the original state if we can. after completely removing a language, I guess we refresh the "whole page" ? same question on error handling removing a language is in the action bar and can happen at many places (from the different subtabs), ideally we reload the whole content view, keep it open on the same tab the user was on. is it possible to remove the main language of a Content (well the question is both from an API point of view and a user point of view) from a u.i. point of view, it's not possible to remove a language if there is only one. from a u.i. standpoint, there is no concept of main language in eZ Platform, which makes things a bit tricky. I think this imply that we need to define a rule of reassigning the main language in the repository when it might be removed. for the restore archived version feature, when reading the document, I have the impression that after publishing you expect the user to be redirected to the Content but with the Version tab selected, is that the case ? no, the restore archived version works just like the current "create from draft" feature, except that it lets the user explicitely choose the language (which is totally missleading in current state), so basically, after clicking restore, it opens the edit mode of a new draft for this language.
            Hide
            Roland Benedetti added a comment -

            to Andrzej Longosz

            PHP API removeTranslation will throw an exception in this case. Given I don't see any UI related to main language changes, I could do it inside REST endpoint controller. However there is no clear way which language to choose as the main one (I'm thinking about the case when Content Versions in total have at least 3 Translations).

            I think that the repository should reassign main language to another language indeed, when it gets to be deleted.
            I think we should just define a rule (and document it for the API), what makes sens to me is the chronological order. Take the oldest language introduced in the content item.

            Show
            Roland Benedetti added a comment - to Andrzej Longosz PHP API removeTranslation will throw an exception in this case. Given I don't see any UI related to main language changes, I could do it inside REST endpoint controller. However there is no clear way which language to choose as the main one (I'm thinking about the case when Content Versions in total have at least 3 Translations). I think that the repository should reassign main language to another language indeed, when it gets to be deleted. I think we should just define a rule (and document it for the API), what makes sens to me is the chronological order. Take the oldest language introduced in the content item.
            Hide
            Roland Benedetti added a comment -

            small note to all followers:
            I have updated the spec doc linked on box.com.
            Added an exemple for the RESTORE function, with clear example of values for the content itself.

            Show
            Roland Benedetti added a comment - small note to all followers: I have updated the spec doc linked on box.com. Added an exemple for the RESTORE function, with clear example of values for the content itself.
            Hide
            Damien Pobel (Inactive) added a comment - - edited

            Sylvain Guittard Roland Benedetti in the document you write:

            in particular, the restore function (e.g. “create content from an archived version”) which is misleading as today.

            I guess here you talk about the following behavior:

            1. Create a Content item in eng-GB
            2. Translate it in fre-FR
            3. Translate it in nor-NO, you now have 3 versions (1 with only eng-GB, 2 with eng-GB and fre-FR, 3 with all the translations)
            4. Restore the version 1

            I guess after that you were expecting to have a version 4 with 3 translations and the eng-GB one corresponding to the initial eng-GB content (ie a kind of merge between version 3 and version 1) but what we have at the moment is a version 4 with only eng-GB ie, the exact same thing as the version 1.

            Indeed, that's a bit confusing for the end user. The thing is, to do that, we use the Create a Draft from a Version REST API method which ignores completely languages (it has the behavior described above). So to make it short, we don't have any REST API call to create a new version as described in the document.

            So André Rømcke Andrzej Longosz, I guess this is a task for you as well. Remain to decide all details around it (HTTP verb, names, behaviors in edge cases, HTTP status code, body, ...)

            Show
            Damien Pobel (Inactive) added a comment - - edited Sylvain Guittard Roland Benedetti in the document you write: in particular, the restore function (e.g. “create content from an archived version”) which is misleading as today. I guess here you talk about the following behavior: Create a Content item in eng-GB Translate it in fre-FR Translate it in nor-NO, you now have 3 versions (1 with only eng-GB, 2 with eng-GB and fre-FR, 3 with all the translations) Restore the version 1 I guess after that you were expecting to have a version 4 with 3 translations and the eng-GB one corresponding to the initial eng-GB content (ie a kind of merge between version 3 and version 1) but what we have at the moment is a version 4 with only eng-GB ie, the exact same thing as the version 1. Indeed, that's a bit confusing for the end user. The thing is, to do that, we use the Create a Draft from a Version REST API method which ignores completely languages (it has the behavior described above). So to make it short, we don't have any REST API call to create a new version as described in the document. So André Rømcke Andrzej Longosz , I guess this is a task for you as well. Remain to decide all details around it (HTTP verb, names, behaviors in edge cases, HTTP status code, body, ...)
            Hide
            Roland Benedetti added a comment -

            Thanks for analysis [~damien.pobel@ez.no]. You guess right,
            We indeed were surprised, as the behavior here was different than Legacy.
            Also surprised that customers didn't complain about it yet but it surely will come...
            Andrzej Longosz can you have a look?
            I guess there is two routes:

            • change the behavior of Create a Draft from a Version (reading the doc. it does not seem to me that the behavior when it comes to languages is really defined), with optionally the addition of parameters allowing to keep other languages attached or not.
            • create a new end point just for that.
              Route 1 seems the best to me.
            Show
            Roland Benedetti added a comment - Thanks for analysis [~damien.pobel@ez.no] . You guess right, We indeed were surprised, as the behavior here was different than Legacy. Also surprised that customers didn't complain about it yet but it surely will come... Andrzej Longosz can you have a look? I guess there is two routes: change the behavior of Create a Draft from a Version (reading the doc. it does not seem to me that the behavior when it comes to languages is really defined), with optionally the addition of parameters allowing to keep other languages attached or not. create a new end point just for that. Route 1 seems the best to me.
            Hide
            André Rømcke added a comment - - edited

            Given the broad title here, do we also intent do change the behavior (introduce possibility for new behavior next to existing for BC) regarding drafts containing all languages to how legacy behaved where it only contained the language being edited until published? Hence possible changes to other languages during publishing workflow won't conflict.

            Asking since if we do, then we probably don't need to change Create a Draft from a Version, but rather look to other parts for changes.

            Show
            André Rømcke added a comment - - edited Given the broad title here, do we also intent do change the behavior (introduce possibility for new behavior next to existing for BC) regarding drafts containing all languages to how legacy behaved where it only contained the language being edited until published? Hence possible changes to other languages during publishing workflow won't conflict. Asking since if we do, then we probably don't need to change Create a Draft from a Version, but rather look to other parts for changes.
            Hide
            Roland Benedetti added a comment - - edited

            Not knowing exactly how the repository works internally, it's hard to answer because the behavior you refer to is not crystal clear.
            What I can say is that in the future, we want to avoid that several language versions are involved in the publishing workflow, to be closer to legacy behavior: 1 version = 1 modified language version.

            André Rømcke : you changed your comment and it makes the question clearer
            I think your recommendation is probably a good way to go, but there might be some side effects for existing users. On the U.I. side, the language switcher in Edit mode is buggy and does not allow to publish several versions anyway (if I am not wrong), so here at least we would have no problem and can change the behavior. Do you think the API might be used by other part of the software or by some customers?

            Show
            Roland Benedetti added a comment - - edited Not knowing exactly how the repository works internally, it's hard to answer because the behavior you refer to is not crystal clear. What I can say is that in the future, we want to avoid that several language versions are involved in the publishing workflow, to be closer to legacy behavior: 1 version = 1 modified language version. André Rømcke : you changed your comment and it makes the question clearer I think your recommendation is probably a good way to go, but there might be some side effects for existing users. On the U.I. side, the language switcher in Edit mode is buggy and does not allow to publish several versions anyway (if I am not wrong), so here at least we would have no problem and can change the behavior. Do you think the API might be used by other part of the software or by some customers?
            Hide
            Andrzej Longosz added a comment -
            1. Create a Content item in eng-GB
            2. Translate it in fre-FR
            3. Translate it in nor-NO, you now have 3 versions (1 with only eng-GB, 2 with eng-GB and fre-FR, 3 with all the translations)
            4. Restore the version 1

            I guess after that you were expecting to have a version 4 with 3 translations and the eng-GB one corresponding to the initial eng-GB content (ie a kind of merge between version 3 and version 1) but what we have at the moment is a version 4 with only eng-GB ie, the exact same thing as the version 1.

            I guess there is two routes:

            • change the behavior of Create a Draft from a Version (reading the doc. it does not seem to me that the behavior when it comes to languages is really defined), with optionally the addition of parameters allowing to keep other languages attached or not.
            • create a new end point just for that.
              Route 1 seems the best to me.

            Based on what I've seen in the Spec doc on box, the simplest thing to implement is to create separate endpoint for restore which would create new version as described - with merged languages. IMHO Create Version from Draft should just do what it's name suggests it does - creating version from Draft
            Having said that, it's possible to extend Create Version from Draft to optionally filter specific languages of existing source Version without introducing BC break.
            But what we should aim here for is to change what can be saved into the created Draft allowing more flexible Translation manipulation, see below:

            What I can say is that in the future, we want to avoid that several language versions are involved in the publishing workflow, to be closer to legacy behavior: 1 version = 1 modified language version.

            I actually wouldn't do it like that. PHP API offers modification of fields in all languages within the scope of one Draft and I was surprised that you're e.g. not able to create all translations in Version 1 via PlatformUI. The behavior of 1 version = modified language clearly has the advantage to restore and merge proper translations in the future, right? However please note that we limit number of archived Versions (by default to 5) because they inflate database indices. That's why I'm not a big fan of what you're proposing. I prefer PlatformUI conforming to PHP API's current behavior which is flexible manipulation of Translations within single Draft.
            But well... I'm not an editor, it's just my expectations if I were the one

            Show
            Andrzej Longosz added a comment - Create a Content item in eng-GB Translate it in fre-FR Translate it in nor-NO, you now have 3 versions (1 with only eng-GB, 2 with eng-GB and fre-FR, 3 with all the translations) Restore the version 1 I guess after that you were expecting to have a version 4 with 3 translations and the eng-GB one corresponding to the initial eng-GB content (ie a kind of merge between version 3 and version 1) but what we have at the moment is a version 4 with only eng-GB ie, the exact same thing as the version 1. I guess there is two routes: change the behavior of Create a Draft from a Version (reading the doc. it does not seem to me that the behavior when it comes to languages is really defined), with optionally the addition of parameters allowing to keep other languages attached or not. create a new end point just for that. Route 1 seems the best to me. Based on what I've seen in the Spec doc on box, the simplest thing to implement is to create separate endpoint for restore which would create new version as described - with merged languages. IMHO Create Version from Draft should just do what it's name suggests it does - creating version from Draft Having said that, it's possible to extend Create Version from Draft to optionally filter specific languages of existing source Version without introducing BC break. But what we should aim here for is to change what can be saved into the created Draft allowing more flexible Translation manipulation, see below: What I can say is that in the future, we want to avoid that several language versions are involved in the publishing workflow, to be closer to legacy behavior: 1 version = 1 modified language version. I actually wouldn't do it like that. PHP API offers modification of fields in all languages within the scope of one Draft and I was surprised that you're e.g. not able to create all translations in Version 1 via PlatformUI. The behavior of 1 version = modified language clearly has the advantage to restore and merge proper translations in the future, right? However please note that we limit number of archived Versions (by default to 5) because they inflate database indices. That's why I'm not a big fan of what you're proposing. I prefer PlatformUI conforming to PHP API's current behavior which is flexible manipulation of Translations within single Draft. But well... I'm not an editor, it's just my expectations if I were the one
            Hide
            Yannick Roger (Inactive) added a comment -

            Andrzej Longosz I agree with you with the BC concern.

            I prefer PlatformUI conforming to PHP API's current behavior which is flexible manipulation of Translations within single Draft.

            We need to be careful not to put too much logic in the UI. For the dev XP it is better to have more API options to manipulate draft. Also, it could also be used in v2/v2.5.

            Show
            Yannick Roger (Inactive) added a comment - Andrzej Longosz I agree with you with the BC concern. I prefer PlatformUI conforming to PHP API's current behavior which is flexible manipulation of Translations within single Draft. We need to be careful not to put too much logic in the UI. For the dev XP it is better to have more API options to manipulate draft. Also, it could also be used in v2/v2.5.
            Hide
            Roland Benedetti added a comment -

            I actually wouldn't do it like that. PHP API offers modification of fields in all languages within the scope of one Draft and I was surprised that you're e.g. not able to create all translations in Version 1 via PlatformUI.

            Indeed, the language switcher in Edit mode "should" allow this, but it's loosing the edit from one language to another and in the end keeping only the latest one used by the editor. I see your point but we can see that it introduced complexity and created issues that were not really required. For now we keep the language switcher in Edit mode as it's the only way to create a content item in a language different than the main language, but otherwise, we'd like to remove it to go to a behavior more similar to legacy (with the improvements listed in this Epic).

            However please note that we limit number of archived Versions (by default to 5) because they inflate database indices. That's why I'm not a big fan of what you're proposing.

            I see your point. We probably should increase this default value to 10.

            I don't want to introduce too much issues with changes, I see your feedback on editing multiple languages at the same time, but we saw that we didn't do it well. I'd rather keep this as an option for version 3 and play it safe with version 2 and 1.12+.

            Show
            Roland Benedetti added a comment - I actually wouldn't do it like that. PHP API offers modification of fields in all languages within the scope of one Draft and I was surprised that you're e.g. not able to create all translations in Version 1 via PlatformUI. Indeed, the language switcher in Edit mode "should" allow this, but it's loosing the edit from one language to another and in the end keeping only the latest one used by the editor. I see your point but we can see that it introduced complexity and created issues that were not really required. For now we keep the language switcher in Edit mode as it's the only way to create a content item in a language different than the main language, but otherwise, we'd like to remove it to go to a behavior more similar to legacy (with the improvements listed in this Epic). However please note that we limit number of archived Versions (by default to 5) because they inflate database indices. That's why I'm not a big fan of what you're proposing. I see your point. We probably should increase this default value to 10. I don't want to introduce too much issues with changes, I see your feedback on editing multiple languages at the same time, but we saw that we didn't do it well. I'd rather keep this as an option for version 3 and play it safe with version 2 and 1.12+.

              People

              • Assignee:
                Unassigned
                Reporter:
                Joaquim Cavalleri (Inactive)
              • Votes:
                4 Vote for this issue
                Watchers:
                17 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: