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

forgot to add a screenshot to the IS in my initial post

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

Please review changes.
Thanks!!

Thank you for the initial MR @chandansha! Problem is when I checkout the feature branch the button label is still Install (and i've cleared the cache several times). Another thing to note is that the only changed file in your commit is the compiled bundle.js. Shouldnt the change for the string be also reflected in one or more of the svelte sources? And talking of change while taking a look I realized the necessary change wouldnt be just about the button label but the verb will also has to change for the "add and apply" button, at the moment it is only possible to apply local recipes but as soon as recipes on d.o are available add and apply becomes relevant as well. And in addition to that the recipesactivator.php has to be adjusted as well probably, out the moment it only outlines the local install. I'll update the issue summary accordingly.

I opened 📌 Only show number of installs if non-zero Active 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. 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 users?

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's message, 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 any further information, that you can undo that action. No matter what wording we use on the button, I think 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.