Follow up for #1831530: Entity translation UI in core (part 2)
Problem/Motivation
Gabor was working with Michael and found error when tried to change the ui language by changing the language code in the url
Proposed resolution
none yet.
Remaining tasks
reproduce bug and give steps to do it
User interface changes
none.
API changes
none.
Comments
Comment #1
plachYes, at the moment creating a translation relies on the current content language. If both UI and content language are depending only on urls you cannot have independent languages. This should be fixed by #1810394: Site configuration with domain based language negotiation results in redirecting authenticated users to a different domain when accessing a content entity route for translation language different from the interface language.
Comment #2
plachComment #3
Gábor HojtsyComment #4
plachMarking as a duplicate of #1833196: could not have interface in language A and create a translation from language B to language C.
Comment #5
plachSorry, changed my mind: we need to add some test coverage for this use case here.
Comment #6
klonos...besides, you cannot possibly mark an issue as being a duplicate of itself ;)
Comment #7
mgiffordComment #8
YesCT CreditAttribution: YesCT commented@mgifford as mentioned in #6 .. that is THIS issue number.
Comment #9
mgifford@YesCT - well, it's good to know that I'm not the only one who has made this mistake. I've made it more than once and I do apologize for that. As with @plach - I'm sure it was just a cut & paste error.
Why d.o allows you to select Related Issue A when you are in issue A is another problem. Not sure if there's a d.o issue for that bug already. It's pretty easy when reviewing a lot of issues that have been postponed, to copy/paste the wrong value in. As you've seen some of the ones where I've done this have been a mistake, but fortunately, this is a minority of the hundred or so issues I reviewed over the last week, looking to see if I could build a stronger relationship about the issues which were postponed and what issue they were postponed on. In many instances I could just mark the issue active or bump the follow-up issue. Most didn't have a semantic relationship well established in the Related Issues.
So ya #1833196: could not have interface in language A and create a translation from language B to language C is this number, and by reviewing the comments a little, @patch probably meant #1810394: Site configuration with domain based language negotiation results in redirecting authenticated users to a different domain when accessing a content entity route for translation language different from the interface language. It's also a follow-up for another issue that isn't marked as a related issue.... I'm correcting the issues in the Related issue box.
EDIT: Oh ya, forgot to mention the importance of doing this. In d.o it's seems like we've gotten into the habit of ignoring postponed items. There are just too many items that haven't been and there's no way to clearly un-postpone an issue based on something else in a semantic way. Without building that semantic relationship to an active item it is just far too easy for an issue to become forgotten. Making them Related issues is an important reminder from the active issues where people are actually looking.
Added: #2350895: Related issues field should not allow you to put in current issue #
Comment #13
plachI believe this use case was addressed by #1810394: Site configuration with domain based language negotiation results in redirecting authenticated users to a different domain when accessing a content entity route for translation language different from the interface language.