Update "image size" description on the Media & Text block

What problem does this address?

Causes confusion as it doesn't change the visual size, but the image dimensions, see #48395.

What is your proposed solution?

Improve the description.

[hanneslsm]

Thank you for the issue!
To ensure consistency, the description should also be added to

• image block
• images within a gallery

The replaced string only exists in the Media Text block. I can't find a setting string in the Image block. Can you specify what copy you'd like to see changed in the mentioned blocks? @hannesdev

[hanneslsm]

Correct, only the Media Text block has a description.
The Image block and images in gallery do have the same "image size" function but no description at all (yet).

Screen.Recording.2023-02-27.at.14.47.10.mp4

@hannesdev Good catch, should be added to the Image block now, which should fix it for the Image as an innerblock to Gallery as well.

[hanneslsm]

I know this might open up a bigger discussion because the code also has the word "size" in it (don't know if this must be changed then), but what if we change the title to "image resolution"?
The word "size" does not really have any meaning here - It's not necessarily the dimensions (this is what this issue is about) but also, it's not really the file size, is it? With a good compression a 1920x720 image could have nearly as much KB as a "smaller" image.

Could anyone from the copy team could comment on this? (Unfortunately, I do not know who to put in CC)

I know this might open up a bigger discussion because the code also has the word "size" in it (don't know if this must be changed then), but what if we change the title to "image resolution"?

@hannesdev Already changed it to resolution in the description of the latest commit. Size is still relevant in the title, because of the name of the function you register them with, and how it's called in your settings.

[hanneslsm]

Convinced. This is a bigger topic.
As stated in the other issue I think that the whole topic should be rethought though, holistically from the point of view of good UX. Now that everything is edited via the editor most users probably assume that the best image quality with the fastest loading time is automatically used anyway. I may create a new, well thought-out issue when I have more time.