We never "translate" frontend menu items: we create different menu items per content language, therefore use different Titles depending on the language to display + specific menu modules per content language. + evidently those set to ALL languages.

To use such a feature in back-end (admin menu module set to a specific language for each installed languages (not only published Content Languages), and all menu items having an equivalent per language installed), we would need a new system plugin specifically aimed at back-end as the feature would be useful for mono AND multilingual sites. In admin we are only concerned by the UI, not the contents. We must not forget that a monolanguage site may propose various languages for the UI, which users can choose from.

Taking into account, among other considerations, the proposed PR for 4.0 #17086 , we would also need a specific Language field displaying installed languages and not content languages.

Forgot: In any case, in back-end, associations are useless.

Seems a great idea to me and will make translating the admin ui when using custom admin menus much quicker and easier to keep identical

If it helps, a bit of background/use case:

As an administrator, I created my custom menu items in the back-end to tailor the experience for my multilingual customers.

As a user, when I logged in to the back-end with a different language, I am seeing half my administrator portal in my native language, and half in whatever language the custom menu was created.

As an administrator, I would expect the menu creation to be done in the same way as I manage my custom menu items in the front-end, but I quickly noticed that it wasn't possible. Sure, as a workaround we came up with you could (possibly) use a language string and translate the string, but that is a pretty poor user experience for our administrators.

It would make sense, I think, from an administrator's perspective to have the ability to manage menus in the back-end in the same way as the front-end when using a custom menu. I would expect to be able to replicate them in the second language in the same way that we do in the front-end, and associate them accordingly, creating a module for each language - unless there's a better way!

I understood what you meant. ?
I am trying to figure the easiest way to do that.
I don't think it is necessary to create associations. Setting the language for admin menu items and admin menu modules should be enough. We just need to use different titles/aliases depending on languages. Defining associations could be overkill and com_associations is not designed for that as it is now. Batch Copy while changing language would do the work.
The switch would be automatic when the admin language is changed, i.e. the custom menu module would be displayed.

I see it this way:

1. A system plugin (adminlanguagefilter.php) and a new method to check if it is enabled.
   JLanguageMultilang::isAdminEnabled
2. A new field type a bit similar to the Language type but using All instead of Default.
   protected $type = 'AdminLanguage';
3. Adding this field to the admin menu modules
4. Adding this field to the admin menu items
5. Using the conditional JLanguageMultilang::isAdminEnabled would let query the correct menu modules and menu items.

@RCheesley
Ruth, I am now working on it.
No need for a new system plugin: we can add a parameter in com_menus Options.
No need either for JLanguageMultilang::isAdminEnabled as checking the new param is fine.
No need for new language field either. We can modify the client of the language field.

I get now custom menus depending on admin language fine here. Just some stuff to finalise.

@infograf768 great to hear it's not so complicated as first thought by the sounds of it! Thanks for looking into it!

@RCheesley
This is what I get here for the moment.

Added a new parameter in Menus Options.

I have created 3 custom admin menus. French, English and one for ALL

In each of them the same language is assigned to all admin menu items. Exemple here for French.

Batch now works for admin menus.

Therefore, when switching languages in back-end, the menu which items are set to ALL always display + the menu which items are set to the language in use.
I left in this capture the default Admin Menu.

The admin menu modules did not need to be tagged to a specific language.
But, as you could see, the patch is incomplete in the sense that it does not get rid of the warning for the custom admin menus where items are tagged to another language, although they do contain the correct necessary items.

Here is my .diff

admin_lang_custom_menus.diff.zip

@izharaazmi
Could you look into this to try to solve the last issue?

The last issue has nothing to do with language thing. That is because of the fact that the two module instances have no idea about each other and they only look at their own contents. Hence the message. I am thinking over it and would try to come up with a solution.

@izharaazmi
Thanks. Please keep me posted.

@izharaazmi

The last issue has nothing to do with language thing.

In fact, it may. What happens is that I do not get the warning for the custom admin menu where the items are tagged to ALL, but only for the menus which items are tagged to another language (not ALL) than the one used in the UI.
As you can see in the screen capture above, when I switch to French, the warning concerns only the English admin menu.

@izharaazmi
I found another simpler solution dealing only with modules language and it solves the issue.
Will make PR.

I was with the same kind of solution, but I found your patch more elegant.
:)
Waiting for your PR.

Did you also manage to the multiple module instance 'check' issue?

By dealing only with the mod_menu admin language (and not at all with the admin menu items language) I solve all issues, including the check.

Please test #17215