CKEditor translates its user interface even if interface translation is turned off

I couldn't reproduce this as explained.

I could only reproduce this when I enabled interface translation and switched the UI language to something other than English.

Even with UI translation on, I was getting an english version of ckeditor when my UI was in english (/en/* path).
The ckeditor was changing language when I was under some other language path (/es or /el).

Either this got fixed since August, or I failed to reproduce it and got the expected behavior!

I can confirm the bug even with "interface translation uninstalled/disabled.

When clicking the 'edit' link on a translation you are being guided to a path like:
example.com/en/node/7/edit
example.com/es/node/7/edit
example.com/el/node/7/edit
And ckeditor takes the language from the corrensponding path.

Instead, the correct path (which exists and works, it was easy to guess) should be:
example.com/en/node/7/translations/edit/el
example.com/en/node/7/translations/edit/es

NOTE: on the above links the breadcrumb doesn't work properly.

File ContentTranslationRouteSubscriber.php:109 in /core/modules/content_translation/src/Routing
is correct. For some reason it seems like Drupal doesn't take this into account.

Delete Routing, starting at line 135 on the same file, works fine.

UPDATE:
by the power of greyskull, eerrr grep I mean, I found that the routing that prevails is located at
modules/node/node.routing.yml:9

I'm kinda spamming this topic, sorry, but it has some fun trying to understand all these new D8 routing and yml stuff :)

You're not spamming at all, thanks for your awesome detective work! :)

Well, I could use a hint on where to look next. This one seems tricky.

I mean, "all we need to do" is alter the edit button to point to a different url if translations are enabled.
It could be silly easy, I just don't get how I can do something like that. Todays sessions helped a bit with the new routing systems though.

Found it!
Attached patch (marked v1) solves the problem and points the user to the correct url for translations.
Please test and provide feedback.
Please consider v1 of the patch for the current issue and not v2 below.

However, it doesn't solve another problem I found:
If you have interface translation enabled, when clicking to edit the original language of the node you are swapped to that language for the interface.
I am submitting a second patch (marked v2) that actually solves this problem but makes the assumption that we address the original content as a translation too.
I suggest a new issue is made for the new problem since it is a bit irrelevant from the current issue. That is unless you find the attached patch acceptable :)

Perhaps the attached approach makes more sense.

The problem originally originated by the fact that the user had right to edit the original node, so the code was never executing the elseif part.
My first patch seperated the elseif, thus if the entity is a translation both ifs are executed and the second one overrides the first.

The new patch actually checks if the entity is the original piece of content, and if not then the elseif part is being executed.

ps: if promise I won't post another patch till the sun rises

Oh... I need to checkout out tests on D8 too

@bserem: awesome work! :) Thank you!

I think Gábor or somebody else from the D8MI team should review this. The patch in #10 is the one to be reviewed.

Back to NW to fix the tests.

Can we get an updated issue summary first? What worked and did not work at different times is mixed in the summary. Its hard to tell what is the scope of the fix here?! I can review once we get an updated summary of the problem.

@Gabor: comment #5 properly illustrates the issue:

I can confirm the bug even with "interface translation uninstalled/disabled.

When clicking the 'edit' link on a translation you are being guided to a path like:
example.com/en/node/7/edit
example.com/es/node/7/edit
example.com/el/node/7/edit
And ckeditor takes the language from the corrensponding path.

Instead, the correct path (which exists and works, it was easy to guess) should be:
example.com/en/node/7/translations/edit/el
example.com/en/node/7/translations/edit/es

The fix tries to send you to the correct path, as described above.
The patch fails testing because the testing mechanism also needs to be updated (how? I wonder)

attempt at issue summary

Issue confirmed on alpha 14 and 15, but seems ok on beta 2

@no_angel: so looks like part of this report does not apply anymore. What applies still of the bugs mentioned?

The patch was not against beta3.
@Charles, can you try patching on git and see if it works?

Also, in order for the patch to pass testing, the test functions need to be updated to (which I'm having difficulties to do).

Your source is here: https://www.drupal.org/patch/apply
and for all things patch: drupal.org/patch

In general, the easiest way is to use: patch -p1 < file.patch
but if you are to spend time with Drupal then if makes sense to invest into the basics of git (you won't learn everything in the first day, but it is good to know where/what to search for).

If you need anything else please do not hesitate (you can also find me on irc)

Even simpler to test the patch: use simplytest.me. Use this link: http://simplytest.me/project/drupal/8.0.x?patch[]=https://www.drupal.org...

@Wim Leers

http://simplytest.me/project/drupal/8.0.x?patch[]=https://www.drupal.org...

> "An error occurred while patching the project"

This is actually a content_translation issue, which explains much of the confusion here.

Re-uploading the patch in #10, but rerolled against HEAD. Now you will be able to test using simplytest.me, via this link: http://simplytest.me/project/drupal/8.0.x?patch[]=https://www.drupal.org....

How does fixing a link solve interface elements translated?

This issue desperately needs an issue summary update, it's almost impossible to understand what the exact problem is, and how the patch solves the problem.

@Gabor I've already replied that to you in #5 and #18.

Drupal calls the wrong link, which displays translated interface elements. The correct links exists inside Drupal and if you call you get the correct translation.

All right, despite us repeatedly asking to please update the summary with current information, that did not seem to get anyone looking into that. So I went ahead and set up a D8 dev site to look into this and I think the complete bug report is entirely misguided. When you go add a Spanish translation or edit a Spanish translation, you get to a Spanish page. The URL starts with /es/... Its a Spanish page. The bug is that everything else is not Spanish not that the CK controls are Spanish. Once you also import Drupal translations for Spanish (because there is a hiccup in the automated download, I downloaded manually from https://localize.drupal.org/translate/languages/es and imported in Drupal), you get the whole page nicely in Spanish as indicated by the URL it should be:

Sounds like this bug is "There are Spanish things displayed on a Spanish page" or if you did not expect it to be a Spanish page then "I did not expect this *page* to be Spanish", not that some CK buttons are Spanish or not.

Updated the issue summary and retitled.

Note that there is an administration language setting in Drupal 8 that you can enable for users to stick to English which will override whatever default content translation things it sets, so this issue is merely about what defaults should content translation set.

Once again you do not get the problem.
As I have explained: the problem happens without enabling interface translation.
When you go to translate a node (content translation) you get translated elements on CKeditor and only there

In the above image, nothing should be in greek (or spanish) but in english.

Does it make sense now?
I had nothing to update to the summary because I've explained the problem both in #5 and #18. Also, the original author had explained it pretty well (at least I understood what he meant).

On this image, check the url. After simplytest.me you get a /el but you should get a /en.
Interface translation is not enabled.

@bserem: the part the URL you squared indicates the source language of the translation. If you would be translating to Greek from Spanish, then that part of the URL would be 'es'. That part of the URL is not indicative of what language the page should be displayed in. The part of the URL indicative of what language to display the page in is the first part, in your case /el/ after the domain.

We can also repurpose this issue to say CKEditor should not translate its interface when the interface translation module is not enabled, even if the URL indicates a different language. Then the proposed patch is not dealing with the problem. I retitled and updated the issue to deal with that the patch tries to achieve but we can go the other way around as well.

So the actual problem is that CKEditor is translated as if interface translation is enabled, even when interface translation is disabled?

All right then, let's retitle and repurpose this again. The goal of you doing this was to make it represent your opinion but we can play "Does Gábor get it" as well. Updated the summary again with the attached screenshot. No content translation module required to reproduce the bug, so the patch is not related to the problem, therefore setting to active. Needs patch then.

Proposed fix. Needs tests.

Patch makes total sense.

Charles Belov, bserem: please test this patch!

Patch #41 gives the correct interface language but creates a path like example.com/[wrong-language-code]/node/1/translations/add/[source-lang]/[target-lang].
The first language code shouldn't be there in the first place I suppose.

As for the patch in #10, I never said it was correct. It was just my attempt to fix the problem.

@Charles Belov: @bserem said to ignore the interface translation problem and focus on ckeditor instead. If we focus on CKEditor then the same problem applies to /es/node/add/page and does not require content translation, which makes for an easier to reproduce recipe for the bug, much less steps, you don't even need content translation module enabled.

If you prefer to administer the site in a certain language, then see #36 on how to set it up.

We can keep your extended steps list in the summary but just enabling language module and adding a language on the standard install is perfectly enough to reproduce the CKEditor bug that #41 is fixing, so the rest just serves to mislead people. Unless of course you want to solve a different bug, which I assumed from the prior patch but been informed by @bserem that would not be the case.

The test would look something like this plus-minus some container rebuilding or service resetting, we'll see.

Should save config of course. Also adding some phpdoc.

Fixed the locale table fail and properly resetting the language manager and the ckeditor plugin. Passes locally.

Looks great, thank you!

Just one problem in the comments and one nitpick. After that, this is RTBC.

1. +++ b/core/modules/ckeditor/src/Tests/CKEditorTest.php
   @@ -368,6 +368,10 @@ function testLanguages() {
   +    // No locale module, so even though languages are enabled, CK should still
   
   @@ -377,11 +381,38 @@ function testJSTranslation() {
   +    // With locale module, CK should not adhere to the language selected.
   

   s/CK/CKEditor/

2. +++ b/core/modules/ckeditor/src/Tests/CKEditorTest.php
   @@ -377,11 +381,38 @@ function testJSTranslation() {
   +    $editor = entity_load('editor', 'filtered_html');
   

   s/entity_load/Editor::load/

Fixed those. I copied the entity_load() from other parts of this file. I fixed it now at one more place which was in scope of the changes, but not in the remaining places that would be unrelated.

Looks great, thanks!

@Charles Belov: while you opened the issue, @bserem actually posted more on the issue than you. To fix a problem, we first need to define what it is. Looks like we arrived at the problem that CKEditor displays translated even if interface translation should not even happen on the site and have a fix with tests to ensure that is fixed and will not reoccur. Given your use case is you are not going to enable the interface translation module as far as I understand, this should completely fix your problem.

If you happen to enable the interface translation module later and still want to force certain preferred administration languages, see comment #36 where I explain where does Drupal provide that feature built into Drupal 8 (that feature is not enabled by default).

Now let's get this in with a core committer :)

The last patch, like the previous one, solves the issue with the CKEditor elements being translated. It doesn't solve the issue with the paths of the translation page which are like:
http://s61aed9511db1e2b.s3.simplytest.me/af/node/1/translations/add/en/af

One would expect a path like:
http://s61aed9511db1e2b.s3.simplytest.me/node/1/translations/add/en/af
since interface translation is not enabled, right?
This link works, but you are directed to this when you click to add a translation.
It is not critical and I don't even know if it is an issue or something that changes with D8.

As for why the issue took a turn, when I started with it, I couldn't reproduce the problem (first comments) but it was clear that there was a problem with translated elements.

@bserem: when I clarified the problem in #34-#36 to articulate your path problem you said in #37 that I did not get the problem and we should focus on solving this without interface translation when regardless of what path prefix you use, nothing will be translated on the screen (after CKEditor is fixed thanks to this patch). So we focused on that one. It does not matter without interface translation what the path prefix is. We changed course back to the CKEditor problem because you asked for that exactly.

Two random fails, entity query again (please review #2397297: EntityQueryTest::testCaseSensitivity() can fail randomly) and a weird twig template fatal error...

Updated with beta evaluation in hopes that it would help get it committed :)

This patch fixes the bug outline in the issue summary - if there are other bugs let's open new issues and reference this one. Thanks.

Committed bb03d39 and pushed to 8.0.x. Thanks!

Thanks for adding the beta evaluation to the issue summary.

Superb, thanks!

Hello guys! I know the issue is fixed, but it's the closest issue I found to my problem.

Here's the problem:
To translate block titles I had to turn on Configuration Translation that requires Interface Translation.
When editing Chinese translation CKEditor becomes in Chinese though I don't want it to be translated (other UI is still English).
I didn't find settings to turn it off. Could somebody please help me?

Thank you!