Terminology update: don't say "Resolution" when we mean "Dimensions"

This issue is still very much valid and came up in the last Usability meeting 📌 Drupal Usability Meeting 2023-10-27 RTBC as we reviewed an issue on resizing image. This should be done everywhere: replace incorrect "resolution" with the correct "dimensions" especially for all user facing texts.

I wonder of this could be split to 2 issues to provide the first easier fix faster?

1. Fix the user facing text
2. Change the variable names and other related code

I removed some of the tags that listed old events.

Splitting the variable / API changes to a separate issue was recommended by @xjm in #122 so that seems like a good way to proceed here.

I made updates to comments and user interface changing the word resolution to dimensions where relevant.
This does not change wording where referencing Drupal 6 terms (migration).
Does not update any variables and that would be a follow-up issue.

Opened 📌 Update variable/API terminology to not use "Resolution" Active so removing "Needs follow up" tag
Since API changes were moved to follow up removing upgrade path and change record tag. Believe the attach CR on this issue could probably be deleted.

String freeze and minor version target I don't recognize but don't think they fully apply.

Looking at MR 5227 I only see label and comment changes so seems in scope of this issue.

Assuming the MR is canonical here since the patch files are very old. Please remember to hide patch files when converting a patch to an MR. Thanks!

Saving issue credits. (That took awhile.)

• I reviewed locally with git diff --color-words and verified that all the changes are updating code comments or UI strings where "resolution" is incorrectly used for image dimensions.

• I grepped for:

  grep -ri "resolution" * | grep "//" | grep -v "vendor" | grep -v "node_modules"
  

  I verified that there were no other inline comments incorrectly referring to image dimensions as "resolution".

• I grepped for:

  grep -ri "resolution" * | grep -v "vendor" | grep -v "node_modules" | grep '\*'
  

  ...to check for the same thing in docblocks. Doing so, I found the following files where the word "resolution" is used to mean "dimensions" in the docblock summaries for several test methods:

  core/modules/file/tests/src/Kernel/Plugin/Validation/Constraint/FileImageDimensionsConstraintValidatorTest.php
  core/modules/file/tests/src/Kernel/LegacyValidatorTest.php
  core/modules/image/tests/src/Kernel/ImageItemTest.php
  

  Renaming the test methods themselves is scoped to the followup, but the docblock should be updated now.

• I grepped for:

  grep -ri "resolution" * | grep -v "vendor" | grep -v "node_modules" | grep "\bt("
  

  ...to check for obvious translatable strings containing the word. Image resolutions are mentioned in image_help(), but in that case it's maybe correct? Please evluate whether you think this should be changed or not:

  As an example, you might upload a high-resolution image with a 4:3 aspect ratio, and display it scaled down, square cropped, or black-and-white (or any combination of these effects).

  .

  Do they simply mean a large image, or do they mean a high-resolution image?

NW to at least fix the three test docblocks. Thanks!

I updated the 3 tests for word "dimensions".

I had deliberately left out changing the "high-resolution" part since it makes sense if read according to for instance Adobe's definition
"High resolution images are pictures or photos where the media has higher concentrations of pixels or dots, resulting in better quality and clarity of the image – as it contains more detail."

A number of end users deal with high-resolution photographs and the help-text would make sense to them. In the past the industry used terms like "press quality", "print quality" or "web quality" and here press & print would be high-resolution and web quality low-resolution. The help text communicates that Drupal handles original high-resolution photos just fine.

Appears feedback for the 3 dockblocks has been addressed.

Thanks @simohell; that explanation works for me.

Committed to 11.x and 10.2.x as it includes minor-only updates to UI strings. Thanks!

I went to publish the CR, but then realized it should actually be about the API and data model changes, not the simple string changes. So I removed it from this issue and reattached it to the followup instead.

xjm → closed merge request !5227

Automatically closed - issue fixed for 2 weeks with no activity.