Add langcode

Here's a revised patch against the latest version of the module

Here is a better version which actually seems to work correctly and is compatible with latest version.

Rerolled against latest dev

This feature actually paves way to fix a bug, which is that there are a couple broken bits of cache when using menu item content:

1. The JSON:API normalisation cache uses the language of the ResourceObject as part of it's cache key, resulting in normalisation getting cached incorrectly for language specific requests including translated menu item content.
2. The cacheability doesn't vary enough for the language content. Adding a cacheable dependency on the content (which will also resolve cache tags etc) fixes that.

As such, have updated the patch and updated the category/priority of this issue!

Looks good to me, but would be great to add tests for this because I don't want it to break again in the future, and as someone with the luxury of only working on single language sites, i18n can sometimes be an afterthought.

Switched to needs work pending tests.

Have also added a new patch that fixes some indentation and an error when a menu item is not translatable.

In terms of items we need to test this with:

• Menu is/is not translatable
• Item is/is not a MenuLinkContent

Test should validate:

• langcode only included on output for MenuLinkContent on translatable menus
• Cacheability is correct in all scenarios
• No errors for non-translatable menu links (the bug I've just fixed)

Hello,

With this addition of "langcode" would it be possible to add the possibility of filtering in the API with ?filter[langcode] for example.

I think that's worth adding for sure, as multi-lingual sites would want that right?

Hello larowlan,

That's right, we have several multilingual projects and this would be to display language-specific menu items.

I'm assuming patch from #22 is the latest work and https://git.drupalcode.org/project/jsonapi_menu_items/-/merge_requests/7 is outdated?

Yes, i think so. We're running that patch in prod and it is working nicely.

✨ Add support for the Menu Item Extras module Needs review has logic for fetching the entity for menu_link_content, which is what this MR and patch are also adding. It's also using `getTranslationFromContext`. The only difference is that this adds langcode

So I think the fix in will fix this, causing this issue to just add the langcode property.

mglaman → changed the visibility of the branch 1.2.x to hidden.

I've opened https://git.drupalcode.org/project/jsonapi_menu_items/-/merge_requests/16 which is the essence of #22. The base field for the langcode field is allowed and the link's language is passed to the resource object.

I've fixed the tests with the new "langcode" attribute. It only appears when "provider" is "menu_link_content". Is this the desired behaviour or a bug?

Still "Needs work" because new tests in a multi-language setup should be added, right?

- Tests pass for phpunit (previous minor) !!!

- Test failures in phpunit are unrelated to this issue (token added to logout links in https://www.drupal.org/node/2822514 → ).

- Test failures in phpunit (previous minor) seem related to php 7.4 . An up to date project pipeline could be triggered to be certain if the same failures happen on the current 1.2.x or just on this branch.

Update the patch with version 1.2.6

Hope this gets solved. using this module with a ReactJS frontend really requires a langcode attribute.

Marking needs review, thanks for fixing the tests @budalokko. https://git.drupalcode.org/project/jsonapi_menu_items/-/merge_requests/16 seems good, but extra test coverage would be great

alexpott → changed the visibility of the branch feature/3192576-langcode to hidden.

Been using this on a production site for a while. Used AI (Claude) to add a test around menu link content translations so we've got some more explicit functionality testing in place.

Marking this as RTBC - we've got test coverage - I've not made any functional changes to this patch and it has been running on a production site I'm involved with a for a year - since #22.

Automatically closed - issue fixed for 2 weeks with no activity.