Problem/Motivation
- Only entities which are fieldable (can have configured fields) are currently configurable as translatable. If they only have base fields which are translatable, that is not enough. This makes it impossible to set shortcuts to be translatable.
- Shortcuts do not have a default
Edit
tab to make the translation tab appear. This was manually added in #2085907: Ensure all configuration entities have an Edit/Configure tab by default to others and may be automated later, see #2095117: Menu system should provide a default tab if none exists but that is not going anywhere, so we need to add manually for now. - When shortcuts are displayed in the toolbar, their original language version is used at all times, not their translations.
Solving these would make shortcuts configurable to be translatable and actually translatable.
Proposed resolution
- Fix the code to first try and collect translatable fields (including base fields) and if none exist, then bail with the checkbox, if there was no translatable field. Should not tie to configurable fieldability.
- Add a default edit tab.
- Load a translated version of the shortcut entity appropriate for the toolbar at the time.
- Add tests based on the standard content translation test facility, but...
- This test facility needs updating to not create a configurable field if the entity is not fieldable.
- However let the test provide the fieldName for a base field so the tests are still fully operational (and remove this from menu content tests, where fieldability is supported).
- This uncovered translation permissions not being created because shortcut sets are not marked as bundles of shortcuts (but they are, see Shortcut.php)
Remaining tasks
Review. Commit.
User interface changes
Shortcuts will finally be configurable to be translatable. They will have visible translate tabs that allow translation of shortcuts. Finally shortcuts will appear translated in the toolbar.
API changes
None.
Comment | File | Size | Author |
---|---|---|---|
#36 | interdiff.txt | 1.41 KB | Gábor Hojtsy |
#36 | shortcut-entity-translatable-36.patch | 10.5 KB | Gábor Hojtsy |
#35 | interdiff.txt | 932 bytes | Gábor Hojtsy |
#35 | shortcut-entity-translatable-35.patch | 10.45 KB | Gábor Hojtsy |
#29 | shortcut-entity-translatable-29.patch | 10.53 KB | Gábor Hojtsy |
Comments
Comment #1
Gábor HojtsyUploading an easier to review patch which shows the removed condition commented out (and does not have indentation changes for the removed wrapping condition). And an actual patch for testing that does (but looks like a lot more changes which is just for the indentation).
Comment #2
YesCT CreditAttribution: YesCT commentedah, I see. we should not check if it is fieldable... cause base fields are translatable now. ok
Comment #3
Gábor Hojtsy@YesCT: right, that is the gist of the patch, we try and collect and translatable fields including base fields, and only add the entity bundle level checkbox, if we found any -- instead of inferring that from configurable fieldability which should not be a requirement.
Comment #4
Gábor HojtsyIn fact, instead of adding that workaround, I'm postponing this on #2310475: Admin theme for translation tabs just works for nodes, which now has complete tests and almost committed.
Comment #5
Gábor HojtsyComment #6
Gábor HojtsyNow rerolled without the workaround now that #2310475: Admin theme for translation tabs just works for nodes landed.
Comment #7
Gábor HojtsyRerolled since it did not apply due to a dead code line removed.
Comment #8
Gábor HojtsyNow with a test! Not yet fully passing but resolved a few hair-pulling things:
- ContentTranslationTestBase.php adds a custom field on the entity which obviously cannot be done if its not fieldable, we need to make that conditional, done.
- MenuLinkContentUITest was setting a custom field name, which was useless; it is fieldable so no need to
- Shortcut sets are bundles for shortcuts but this was not defined in the annotation, (automated permissions for translations did not work, so test users could not be created, fun to debug :)
Local fails are now down to the default language titles not properly setting.
Comment #10
Gábor HojtsySo the remaining fails are only due to us using the title base field in the test, so we should not try to force the default value either, since the test wants to control it. As soon as we let the test fill in the title value (since we tell it to use it in $this->fieldName), it is fine. So that's it :) Reviews please.
Comment #11
Gábor HojtsyComment #12
plachThe patch looks great, but I tested it and it seems translations are not rendered properly:
Separate issue?
Comment #13
plachAlso, the edit links in the translation overview page do not lead to the correct translation, but always to the one matching the current language.
Comment #14
Gábor HojtsyYeah the shortcuts did not show up translated and I thought to fix it in another issue, but we can just as well prove it here and integrate it into the test. Works :)
On the links in the translation overview, they are borked for ALL entity types, same problem applies to node articles. I'll submit another issue shortly, I think I have a patch.
Comment #15
plachGreat work, RTBC if green
Comment #17
Gábor HojtsyPatch was beautifully green locally (multiple times). Making the xpath test more robust, so it should not fail on escaped stuff or whitespace getting in the way.
Comment #19
Gábor HojtsySo the full href may be different if the site is in a directory of course. Use a contains() like other tests do.
Comment #21
Gábor HojtsyAll right I'm down to having no idea why this breaks. All prior versions of the patch have been green locally. Duh. Will need a patch testing issue splintered with debug messages :(
Comment #22
Gábor HojtsyDecided to use this issue to figure this out. It should not be that far away #famouslastwords
Comment #24
Gábor HojtsyDuh, looks like all paths requested display the untranslated shortcut / not language dependent path.
Comment #27
Gábor HojtsyLooks like path access checking got stricter in the meantime, now we cannot set a shortcut to the admin page, so translations did not save. We should use a less restricted path in the test, the user path is good one.
Comment #29
Gábor HojtsyNeeded a reroll due to #2224761: Add a generic way to add third party configuration on configuration entities and implement for field configuration.
Comment #30
Gábor HojtsyThis new rerolled patch passes on the simpletest UI locally (139 passes, 0 fails, 0 exceptions, 52 debug messages) but fails miserably on run-tests.sh (49 passes 51 fails 34 exceptions 29 messages). Uhm, now what? Neither reproduces the situation happening on testbot.
Comment #32
plachI am afraid this won't help, but I am seeing lots of failures on HEAD too when running tests via
run-tests.sh
(tests pass in the UI). Maybe ask @berdir?Might this be a OSX issue?
Comment #33
BerdirFrom the HTML output:
You can't use generated paths with drupalGet(). You end up with checkout/checkout (checkout is the subfolder where drupal is installed).
drupalGet() has an options array, just use that: drupalGet('', array('language' => $language).
Comment #34
Gábor HojtsyAll right, because it is a page not found, the language will not be recognised either. Duh. Fixing this up then. Thanks @berdir.
Comment #35
Gábor HojtsyNow uses $language natively on drupalGet(), thanks @berdir for the tip. Still has some debugging code in it which should be removed once/if passes finally. (Passes locally).
Comment #36
Gábor HojtsyAll right, removing debug code. I think this should be ready to go in now :) @plach what do you think?
Comment #37
Gábor HojtsyComment #38
plachLooks (and works) great, thanks!
Comment #39
webchickCommitted and pushed to 8.x. Thanks!
Comment #41
Gábor HojtsyAmazing, so glad this works now :) Not for shortcuts per say, but for the coherence of the system in general.
Comment #42
plachYep, that's awesome :)