Adjust the micro copy for the Recipes source type to the Recipes terminology

Changed the button label Install to Apply on the Recipes source type.

Please review changes.
Thanks!!

I opened #3461037: Only show number of installs if non-zero to deal with the "installs" language for now :)

Chandansha - can confirm that in this MR, only the bundle.js has any changes. I would expect to see some changes in the Svelte source as well.

I'm also unsure how it was handled in the source, but I think generally speaking if we want to change this copy, we shouldn't just be doing it with an "if" in the Svelte; I think this is a non-trivial change to allow the source plugin to provide its own language for its action button.

Yes, we'd also need something on the project object in the frontend, sourced by the backend, to show the language rather than hardcoding 'Install' here:
https://git.drupalcode.org/project/project_browser/-/blob/2.0.x/sveltejs...

ActivatorInterface.php would need to require a new method, something like getActionText(), which would return at least two states of text (one for if the project is already available, and one for if it is not yet available), for example "Add & Install" vs just "Install" - for recipes, they may both just be "Apply" (we're considering just "Install" regardless for PB anyway for modules - because we're not sure if communicating this to the user is even helpful).

While we're at it, we may need to also do a "View Commands" text version as well... if we're building it to be flexible.

Will run this API change by @phenaproxima, but it's clear this is not a novice issue any more.. 😆

I'm not entirely convinced this is a good idea.

Changing the action text between sources exposes the underlying difference between project types, and adds cognitive load. (It's all too easy to imagine this complaint: "I was looking for the install button, but everything only said 'Apply' -- why couldn't I find it?")

What's so wrong with "Install"? Sure, it's true that recipes are not technically installed like modules or themes are, but users don't care about that. It's a developer-facing distinction.

The question, then, is how would a change like this be valuable to end users? I'd like that to be answered before we proceed here.

I can see the logic that recipes are "applied" to a site, rather than installed. However, I think for a novice site builder, it's not very clear what "Apply" means when it's on a button. When I see an "Apply" button on a website, it implies "make a request", as in "Apply for a loan", "Apply to join a group", "Apply for job".

I think this can be solved. Perhaps something like "Apply to site" would be clearer?

I to like the idea of making the button reflect the type of item being browsed, so in principle, I think it's a good change.

But I think we need to think carefully about our choice of button labels.

One of a new users' first interactions with Drupal will be a mini browser of recipes, and in that instance will "Install" be clear, since from their point of view, they're already in the middle of the install?

I to like the idea of making the button reflect the type of item being browsed, so in principle, I think it's a good change.

But that still doesn't answer my question, which is what is it about this change which would be valuable to end users? Would it be clearer? Simpler? Nicer? I honestly don't know.

I think we need to answer that before proceeding here.

The only con I can see to the usage of “Install” is that, to some end users, that might imply that there must be some “Uninstall” mechanism to recipes (similar to installing/uninstalling an app on your phone or computer).

"Hi @chrisfromredfin and @rkoller,

I made some changes, but when I read @rkoller comment, I checked my merge request (MR) and realized that it didn't include any of the changes. I did some research to figure out why my changes weren't being pushed and discovered that the .gitattributes file was hiding my changes. I pushed my changes today to inform that I didn't push a blank MR.

I also read @chrisfromredfin's comment #12, which I found not suitable for beginners, so I skipped that issue and moved on to another one.

Thanks to you both!"

It's a developer-facing distinction.

This is sort of true, but there is a major actual distinction: recipes can't (currently) be *uninstalled* whereas modules can. I'm not sure that simply having the button say "Apply" conveys this, but I do think having it say "Install" implies that you can uninstall?

I'm not sure that simply having the button say "Apply" conveys this, but I do think having it say "Install" implies that you can uninstall?

I feel like we could go down a semantic rabbit hole here. The doing of any action implies, in the absence of further information, that you can undo that action. Most UIs have a concept of "undo" that people just expect, no questions asked. So my feeling is that, no matter what wording the button uses, people will still ask "how can I undo that"?

The answer is that recipes have a certain degree of reversibility because of the config checkpoint system we invented, but that is, for now, really just limited to recovering from config validation errors. There's no UI for reverting to a pre-recipe state (yet). For all intents and purposes, until such a UI exists -- and it's in the roadmap, I'm pretty sure -- recipes can't be undone except by restoring from backup.

As we think ahead to other types of browsers, I think we may need to support each source changing what its Activator "does" anyway. I wonder about themes. I am thinking that if people don't see a theme change more or less right away then we may want to change to "Set Default" for themes. Components could be "Installed" if we build a component browser, but not really in the same way modules are. Maybe "Add" makes more sense for components.

I can see both sides.

Triaging as beta blocker, since we definitely need a decision on this one way or the other.

Since maintainers of the Recipes system are adamant that recipes are always applied and not installed, I am not in favour of the Project Browser using terminology that will ultimately cause confusion. If we expect people to use this interface as part of their first experience of Drupal, it should not be sending people down the wrong path in understanding how to think about how it all works. So, a -1 for me on "Install" as a label.

I also agree that as we think about other things (like components) that could be made available through the project browser, "Install" makes less sense. I think "Add to Site" as a button label is generic enough.

I'm still in favour of being consistent with Drupal terminology. If the Drupal term is "Apply" we should use it. If we think that's going to be confusing in Project Browser, we should petition to have the term changed in the rest of the Drupal project.

Also, I think an important distinction with recipes is that they can be re-applied multiple times (I think the current Project Browser implementation blocks this), and they can't be "uninstalled". I think if we use the same install/uninstall terminology we use for modules, it masks this distinction.

I am going to close this with (Outdated).

Now, all the buttons just say "Select" or "Deselect" which is The Right Thing™ - BUT, when we work out the bulk action bar at the bottom, we may want to differentiate or come up with language there. I will reference this issue on that one.