Re-roll to 8.x-2.10
Changing that the "data-value" attribute is used instead of "text" resolves the issue with data loss associated with colons.
The patch is only for Ckeditor 5 and does not migrate any old data to the new format.
Are there any plans on updating the 8.x-1.0-version to be Drupal 10-compatible and what is the future for the 1.0-branch?
The issue I have with updating to 8.x-2.0 is that it is using the menu_link-field module. I haven't any documentation for migrating the menu items from menu_ui to menu_link-fields.
If you have an existing site the issue becomes that the menu links created via menu_ui are not shown to the end user, presenting them with an empty menu item field. To the user it seems that the page does not have a menu link item attached to it and it may lead to a user adding a duplicate menu entry to the same content.
There is also no way of updating/removing the old menu item without navigating to "Admin - Structure - Menu - Manage" which is in my case a hurdle as we have large menus and finding correct items in the structure is complicated without the ability to do so in the "edit node"-form.
I used the patch in #202 and noticed that displaing the "Published" status as a column was always displayed as "published" regardless of the actual state (Tested on multilingual Drupal 9.5.9).
The check if an entity is published was done against a FieldItemList instead of the boolean value of said key.
If we are not to test any translations then the patch in #5 should be ok and it has passed testing. We do not need to update the media_library tests as the ui elements (in the testing environment) are unaffected by this change.
Re-roll of patch #22
Adding accidentally stripped space which corrupted the patch in #21.
Updated the patch from #11 according to #16 (skipped #17 and #20 as they introduced a typo in the spellings).
I'm a bit worried that this patch wont pass the testing procedure somehow as the previous test results have failed and that is because the string has been in English in the testing environment. Attached screenshots from my local environment just to verify that the strings are correct and the translation part of the patch works.
If the tests fails with due to asserting the strings, could it be so that the testing environment does not have the dutch or spanish localization strings available? If so, then we cannot test that this string has been translated.
@smustgrave if I have understood things correct the test in media_library will fail when the dialog is patched so it needs updating either way as waitForText('Add or select media') will not be in english when the string is translated.
Attached an updated patch which checks if the ui dialog is translated correctly and waits for the element instead of the dialog title text.
I'm not too familiar with testing but should this test regarding if the translation works be done in the core media_library module instead?
In the core media_library module there is tests regarding if the library translation works as intended, the current translation test has call to waitForText('Add or select media') in both dutch and spanish, by updating them to the correct translated strings the test should fail if the strings are not translated.
Attached a patch regarding proposed change but this should perhaps be moved to a separate issue regarding the media_library module, not ckeditor5.
Tested patch in #3, the translation works now as intended.
I removed the title attribute for said dialog from ckeditor5.ckeditor5.yml as I believe that value is now not used at all, I also simplified the patch a bit.
miikamakarainen → created an issue.