Activity

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+.

Roland Benedetti
added a comment - 12/Sep/17 3:26 PM 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+.

Yannick Roger (Inactive)
added a comment - 12/Sep/17 10:53 AM 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.

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

Andrzej Longosz
added a comment - 12/Sep/17 10:31 AM
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

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?

Roland Benedetti
added a comment - 11/Sep/17 6:03 PM - 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?

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.

André Rømcke
added a comment - 11/Sep/17 5:42 PM - 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.