Spin-off from #2256497-15: [meta] Menu Links - New Plan for the Homestretch.
In D7, the 'title' defined in hook_menu() was both the default route title and the default link title. Because of that, _menu_item_localize() could compare $item['link_title']
with $item['title']
to determine whether the link title has been customized, and if not, translate it with t() as is appropriate for all strings that come from code.
In D8, route title and link title are more decoupled, so _menu_item_localize() only checks $item['customized']
, but that can return TRUE if other properties (e.g., weight) are customized even if title isn't. That code has a @todo linking to #2193777: Menu link translations need to work with content translation, shipped translations need to be compatible; however, per #2256497-28: [meta] Menu Links - New Plan for the Homestretch, fully supporting menu link translation isn't a release blocker for D8, but fixing the regression related to default link titles is, so opening this issue for just that scope.
Postponing for now on #2256521: [META] New plan, Phase 2: Implement menu links as plugins, including static admin links and views, and custom links with menu_link_content entity, all managed via menu_ui module, since if that lands, it will fix this problem in a cleaner way, but if that issue doesn't land quickly enough (up to core maintainers to decide when that is), we can unpostpone this more targeted issue.
Comment | File | Size | Author |
---|---|---|---|
#1 | menu-link-translate-default-title.patch | 1.12 KB | effulgentsia |
Comments
Comment #1
effulgentsia CreditAttribution: effulgentsia commentedUploading a terrible patch, but one that fixes the regression, to demonstrate that it is possible to do with relatively little impact. Better solutions, such as adding a 'default_title' column to {menu_links}, are also possible.
Comment #2
dawehnerIt is so sad to see that we waste time on workarounds, even we do have a proper solution. It has to feel bad if you waste your personal time on that.
This will fail, because there might be external paths, and so no route on the menu link.
Comment #3
pwolanin CreditAttribution: pwolanin commentedThis patch is also just incorrect. There is no connection between the route title and the link title except by chance.
Comment #4
catchYes just applying the 7.x pattern won't work here. The router table in 7.x used to hold the default menu link title, now it holds the route title which is independent.
The default menu link title then, is only available from the actual default menu link YAML files. Without adding an extra property to menu links (either 'original title', or 'title customized' or similar - neither of which are clean at all), I don't see a way to fix this with HEAD as it currently is.
Comment #5
Gábor HojtsyYeah we would need to go back and read the YAML each time (not performant) or store some part of it (not nice) to do this.
Comment #6
catchBetween not performant (and also not nice), and not nice, I'd go for not-nice. That will require a schema change and potentially upgrade path unless someone comes up with a third option, so bumping to beta blocker.
Comment #7
effulgentsia CreditAttribution: effulgentsia commentedUpdated summary to reflect the implementation issue, rather than the meta issue, this is postponed on.
Counting that as a 0.5 for the postponed number in the title, since there's two possibilities:
- if that issue is committed, there will be nothing left to do here and it can be closed
- if that issue is won't fixed, this will need to be unpostponed and fixed
Comment #8
effulgentsia CreditAttribution: effulgentsia commentedSee #2256521-77: [META] New plan, Phase 2: Implement menu links as plugins, including static admin links and views, and custom links with menu_link_content entity, all managed via menu_ui module.