[docs] Copy icons to clipboard

[codewithguruji]

• I have followed (at least) the PR section of the contributing guide.

[mui-pr-bot]

Details of bundle changes

Generated by 🚫 dangerJS against 7edc47f

[mbrookes]

Thanks for working on it. I think we should:

• Add a "copy" button. Copying when selecting or just clicking the text is unexpected. We don't know what might be in the user's clipboard that we just splatted.
• Add a notification similar to that on the "copy the source" button in the demos, so that the user knows that the text has been successfully copied.
• Remove the automatic text highlight, since this breaks expectations for a single click on some text.

[oliviertassinari]

I have tried to experiment with this but I couldn't come up with anything great without dedicated a disproportionate amount of time. I have found two things that suck. 1. the snackbar is a nightmare to use: #18098, 2. the dialog title bundle two DOM nodes #19696 which is surprising.

[oliviertassinari]

Actually, I think that I have found a nice trick, using https://ionicons.com/, https://fontawesome.com/icons/archway?style=duotone and GitHub copy button as inspiration:

@codewithguruji @mbrookes What do you think about the latest version? (It has cost me ~30 minutes, could it be a quick win?)

https://deploy-preview-23850--material-ui.netlify.app/components/material-icons/#main-content

[mbrookes]

Definitely an improvement - the only thing I might add is "click to copy" on the tooltip. It isn't unreasonable to assume that a click is with the intention to copy though, so probably good enough.

[oliviertassinari]

the only thing I might add is "click to copy" on the tooltip.

FontAwesome does that, I agree, it might work even better. I won't spend time on it, but if somebody wants to push it further, I will be curious to see the result :)

[mbrookes]

I think that these 3 labels should be generic (not scoped under searchIcons)

I originally thought the same (in general), but since they will dedupe on CrowdIn, there's no overhead. Doing it this way reduces the chance of accidentally removing a translation in use on another page. It should also make it easier to spot dead translations.

(I also noticed that you had moved potentially shareable translations in the API page under a page specific key.)

[oliviertassinari]

I originally thought the same (in general), but since they will dedupe on CrowdIn, there's no overhead. Doing it this way reduces the chance of accidentally removing a translation in use on another page. It should also make it easier to spot dead translations.

I don't think that spotting dead translations should be a variable on the tradeoff as it can be automated. I don't think that accidentally removing a translation is a variable either because it's easy to grep in the codebase. I think that what's important is whether or not we want to anticipate the need to provide custom translation for each context. IMHO, the best tradeoff is to optimize for English and to a "best-effort" for the other locales (so we spend as little time as possible on them) => no duplication.

[oliviertassinari]

@codewithguruji Thanks for working on this :)

[codewithguruji]

@codewithguruji Thanks for working on this :)

Thank you so much @oliviertassinari @mbrookes