Problem/Motivation
As an ordinary user of the module, the word "Type" doesn't convey meaning to me, such as these instances in the GUI:
- Export Types
- Import Types
- Add Export Type
- Create new import type
Steps to reproduce
Using the module and wonder what a "Type" is ...
Proposed resolution
Use "Menu" instead of "Type".
Before and after:
Menu Migration
Now:

Proposal:

Export list
Now:

Proposal:

Add Export
Now:

Proposal:

Remaining tasks
Now:
- Update the UI
- Update the README file
After next release, via #3486374: Update documentation, using Menu instead of Type:
- Update the Documentation text, using the same name and id for export and import
- Update the Documentation screenshots
| Comment | File | Size | Author |
|---|
Issue fork menu_migration-3486358
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
ressaI can create an MR, but will wait for feedback before proceeding, because "Type" is present many places :)
Comment #3
bbu23I have to admit it sounds much better 😁
You have the green light, I like how it sounds and it makes total sense. To think about it, I had a bit of troubles finding names for that I think I just went with the actual name of the entity type. So, please proceed, and then we need to update README as well, and when I do the release we need to update the Documentation, and with occasion update the screenshots for the other feedback as well from the Documentation (the one you mentioned about the IDs naming).
Thank you
Comment #4
ressaGreat, I really appreciate your openness to changes :)
While creating the issue, my mind also glazed over a few times, having to juggle the different concepts ... which made me realize that while actually coding it, something similar probably was taking place. Naming things are difficult!
But let's keep using "type" in the code, and only update the UI and README, right?
And then doing the documentation when that's in place is a great plan, and I have added it in the Issue Summary.
Comment #5
ressaI created a child issue #3486374: Update documentation, using Menu instead of Type.
Comment #6
ressaComment #7
bbu23Hahah, yes the naming sometimes can be the harder part!
Sure, sounds like a plan! Thank you!
Comment #8
ressaComment #9
ressaI had a look at it, and it may be a pretty big task ... Below (see section "1. UI occurrences ...") public facing strings in the UI, which need to be updated are listed.
I also include the occurrences of "type" which probably don't need to be updated in section 2 and 3, since they are code, and not exposed via the GUI or Drush. (There are some comments in section 3 also ...)
The strings and files which need to be updated include permissions, since they are exposed in the GUI. I guess this would mean update hooks are also needed?
Perhaps this is too much work, for too little gain? We could set this to Postponed, so that anyone who feels like it in the future, can take a stab at it :)
UI occurrences where "type" could be updated
Code comments occurrences of "type"
Code and code comment occurrences of "type"
Comment #10
bbu23Thank you for your analysis, but I wouldn't go that far. I don't want to change what a user cannot see.
But I do agree with the naming in the UI, now I will review this and take a decision.
Comment #11
bbu23Comment #12
ressaI agree with that, and also what I tried to say ... sorry if I did not express myself clearly.
I do not propose to update code or code comments (#2 and #3 -- as I wrote "...which probably don't need to be updated"), but only strings which the user can see through the GUI or Drush, which is section #1, "1. UI occurrences where "type" could be updated".
From what I can tell, all the 103 lines of code under section #1 can be exposed to the user. Or maybe I am missing something ...
But maybe that is doable after all?
I do think switching from "type" to "menu" would be an improvement, and more user friendly. But it all comes down to how big an effort it takes ... I'll let you decide, if it's worth it :)
Comment #13
bbu23Yes, I might have included extra concerns unnecessarily. :)
Based on your research, indeed it requires many changes if we tackle every occurrence. I'll be thinking of it, I also agree about the effort, so we'll have to see. It's definitely doable, but it's very time consuming as you mentioned.
Comment #14
ressaHeh, a little extra concern can sometimes be a good thing :)
It sounds great, that you will think about it. And who knows, maybe someone else will step up and tackle it? Let's see ...
Comment #16
bbu23So I'm trying to avoid having opened issues whenever I can. This means, that I am trying to take a decision whether to go forward with this or cancel it.
I created a kinda POC with how this replacement would behave/look like with the mention that the proposed "Export menus" and "Import menus" menu items are implemented as "Menu exports" and "Menu imports". The reason is simple: Menu exports is the plural of Menu export and those pages are listings of Menu export or Menu import entities.
On the other hand, I had/have some inner conflicts with this. I admit that it looks & sounds better for sure, but going back to the source issue, I'm just curious why "Content Type" is fine but not "Export Type". After all, this is a type of export and "Article" is a type of content.
Furthermore, if I decide to advance with this, from now on there will be a distinction between UI text and code text, which by itself is not a problem, but let's call it "a very small bifurcation".
Will be playing with it, thinking, but looking forward to your response @ressa
Comment #17
ressaThanks @bbu23 for creating an implementation of the proposed solution so fast!
It looks great, and it feels more intuitive now. (There was a single detail, I added a comment in my review.)
I think the reason the "Export type" thing caused me a slight confusion, is because this module is strictly about menus, and as a user, I just don't expect to wrangle with a new concept of "Types". Also "Type" doesn't give any meaning to me.
Thinking more about it, the individual items (types/exports) could get a more specific name, more special than "Menu exports" ... "Menu group" could work, to signify that this is a collection of menus? Or even "Menu collection"? Or maybe it again just could be a cause of confusion, introducing new concepts ...
So all in all, I am a fan of the current POC :)
Comment #18
bbu23Thank you for your answer on the "Type" thing, seems fair enough.
As for "Menu group", "Menu collection" etc. I'll stick to the initial proposal, as at the moment I consider a must to have the "export" and "import" words present, agreeing with your last statement:
Thanks for your feedback as well!
Comment #20
bbu23Comment #21
ressaPerfect, thanks for the great work!