If you have the Content Translation (and dependencies) module turned on, and more than one language on the site, and you go to the Translations page for a node where the UI is in English (like node/1/translations) and click "Add" button to add a Spanish translation, you get to a page like
example.com/es/node/1/translations/add/en/es
Which is to say, it is a page with the UI changed to Spanish, and all the labels and text in Spanish, that lets you enter the Spanish translation. If I manually remove the first "es/" from the URL so that I'm at
example.com/node/1/translations/add/en/es
I am able to enter the translation, with the UI still remaining in English.
On the other hand, if you go to a similar page that lists translations of a view, such as admin/structure/views/view/recipes/translate [where the machine name of my view is "recipes"], and click the very similar looking "Add" button there to add a Spanish translation, it takes you to a page like
example.com/admin/structure/views/view/recipes/translate/es/add
which has the UI in English.
These two are inconsistent.
I think that the UI should stay in English for both, so I filed this issue in the content translation module.
Two reasons:
a) If I had the admin UI in English, and I click an "Add" button whose label is in English, I should not be pushed into having the UI in Spanish. It is very jarring.
b) It is very common for site editors or site owners who want to provide their site in a foreign language, to not necessarily be able to read that language. So, they provide the text of the page(s) to be translated to an agency or company translator, and then they get the translation back in a spreadsheet or Word document. Then the owner/admin/editor has to enter the translations. They might be OK if the site is being translated into Spanish and they are English speakers -- they could maybe figure out what goes where. But if it's being translated into Chinese for instance... not so much.
Therefore, the proposed resolution is to change the target URL of the "Add" translation button, for content translation, so that it leaves the UI in the language that was in use when the button was clicked.
Decide if the proposed resolution is correct. Make a patch.
The UI will remain in the language it was in, when translating content.
None.
None.
Closed: outdated
11.0 🔥
(Drupal 8 Multilingual Initiative) is the tag used by the multilingual initiative to mark core issues (and some contributed module issues). For versions other than Drupal 8, use the i18n (Internationalization) tag on issues which involve or affect multilingual / multinational support. That is preferred over Translation.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
I tested this on Drupal 11, umami install today. Using the steps in the issue summary I was not able to reproduce the problem. That is, the UI stayed in English for both cases.
Therefor I am closing this as outdated. If this is incorrect, re-open and add a comment.