Add `language` where arg to `menus`

[esamattis]

So we could do this

{
  menus(where: {location: FOOTER, language: EN}) {
    nodes {
      slug
      name
    }
  }
}

---

Note! If you want to get menu items in a specific language for a given location you can use menuItems which is used most of the time used when building menus for the frontend.

{
  menuItems(where: {location: FOOTER, language: EN}) {
    nodes {
      label
      url
    }
  }
}

[SilencerWeb]

It would be a very nice and useful feature

[esamattis]

Menus themselves are not translateable so this feature request is invalid.

See this comment:

https://github.com/valu-digital/wp-graphql-polylang/issues/33#issuecomment-703633500

[esamattis]

Actually, menus could be filtered by the location and the location language.

[sven-ra]

Currently I still have to select the language and location parameter. Funnily the language has to be my default language otherwise It will always show me the default PRIMARY location. Is this happening to someone else as well?

[esamattis]

I don't quite follow. Can you provide the query you are using, what results you get and what did you expect getting?

---

But here's some background how the locations work internally in WP and Polylang which might clear things a bit.

When you register a menu location named PRIMARY and then enable Polylang and add three languages: EN, EE, FI and set EN as the default language. Polylang will then assume that the PRIMARY is the location for the default language EN. Then it will create additional locations dynamically based on the PRIMARY location for the other languages. Those will be PRIMARY___EE and PRIMARY___FI.

This means that when you query menu items without the language where arg using the PRIMARY location you will get the menu items from the default language. But when you add the language where arg wp-graphql-polylang just converts it to corresponding translated location.

Example:

menuItems(where: {location: PRIMARY, language: EE})

is the same as

menuItems(where: {location: PRIMARY___EE})

But if you do

menuItems(where: {location: PRIMARY, language: EN})

It's just

menuItems(where: {location: PRIMARY})

because EN was the default language.

---

This means with the menus field you can use the PRIMARY___* locations as a workaround until we have proper language where arg support in menus.

Btw, may I ask what's you use case for the menus field you cannot do with menuItems? I've mainly seen menus useful for reimplementing the WP menu builder.

---

But there's another discussion to had here too. Should the query without the language defined (ex. where: {location: PRIMARY}) return the menus / menu items from all languages and not the default. The current behaviour is inconsistent with how other fields (posts, terms) work in wp-graphql-polylang.

---

And last thing: I consider the PRIMARY___* locations to be internal for Polylang and might remove them from the graphql api completely once we have all the required language where args in place.

[sven-ra]

EDIT I just had some errors in my syntax.

---

But there's another discussion to had here too. Should the query without the language defined (ex. where: {location: PRIMARY}) return the menus / menu items from all languages and not the default. The current behaviour is inconsistent with how other fields (posts, terms) work in wp-graphql-polylang.

Then again I guess it would be inconsistent on how WP and Polylang work right now. Since it does not query all the menu items from all languages right now?

And last thing: I consider the PRIMARY___* locations to be internal for Polylang and might remove them from the graphql api completely once we have all the required language where args in place.

I guess the only error I can see is that it can break when somebody defines their own menu location namespaces. Like for example MENU_ENG and MENU_EST instead of PRIMARY and PRIMARY___EN. I am not sure how to deal with this since this is an edge case.

---

Thanks a lot for the plugin and a quick response!