Internationalization support for sizes added by 'edit_custom_thumbnail_sizes' filter

[tmatsuur]

The image size labels added by the edit_custom_thumbnail_sizes filter are not internationalized.

<label for="imgedit-target-custom<?php echo esc_attr( $key ); ?>"><?php echo esc_html( $size ); ?></label>

In a Japanese environment, there will be a mixture of translated and untranslated text.

To solve this problem, the following size of translated text is prepared before the loop process.

$size_names = array(
	'thumbnail'    => __( 'Thumbnail' ),
	'medium'       => __( 'Medium' ),
	'medium_large' => __( 'Medium Large' ),
	'large'        => __( 'Large' ),
	'full'         => __( 'Full Size' ),
);

Change the following where labels are output.

<label for="imgedit-target-custom<?php echo esc_attr( $key ); ?>"><?php echo esc_html( isset( $size_names[$size] )? $size_names[$size] : $size ); ?></label>

Since image size labels are also used in the "image_size_input_fields" function, etc., it may be better to make them a function rather than an array.

In addition, the translated text for "Medium-Large size image height" and "Medium-Large size image width" exists, but the translated text for "Medium Large (or Medium-Large)" does not.

If you are conscious of word commonality, "Medium-Large" may be better than "Medium Large".

[SergeyBiryukov]

Hi there, thanks for the ticket!

Moving to 6.0.1, this appears to be a follow-up to [53161] / #28277.

[mukesh27]

Hi there!

I checked the issue and sent some feedback.

For the custom image name system use get_intermediate_image_sizes() function ​here so it will not add Full Size image type.

Instead of a fixed image size and name array can we use the image_size_names_choose filter with some default array?

<?php
$image_size_names = apply_filters(
        'image_size_names_choose',
        array(
                'medium'       => __( 'Medium' ),
                'medium_large' => __( 'Medium Large' ),
                'large'        => __( 'Large' ),
        )
);

I will upload patch soon.

Trac ticket: https://core.trac.wordpress.org/ticket/55840

[audrasjb]

Hey there, thanks for the PR @mukesh27!

Since get_intermediate_image_sizes() also calls wp_get_additional_image_sizes() which return custom sizes with their label, shouldn't we change a bit the existing code to make sure custom sizes are also labelled with their translated label (when it exists)?

[tmatsuur]

Replying to audrasjb:

Hey there, thanks for the PR @mukesh27!

Since get_intermediate_image_sizes() also calls wp_get_additional_image_sizes() which return custom sizes with their label, shouldn't we change a bit the existing code to make sure custom sizes are also labelled with their translated label (when it exists)?

When extending the functionality of the get_intermediate_image_sizes(), I am concerned about the possibility of unintended rewriting by the "intermediate_image_sizes" filter.

I don't think you have to worry about that if you have a new function.

[SergeyBiryukov]

It looks like the PR is closed and a new patch is needed. With 6.0.1 RC1 coming soon, moving to 6.0.2 for now.

[SergeyBiryukov]

Looks like this did not get any further traction yet. With 6.0.2 RC1 coming today, moving to 6.1 for now.

[desrosj]

This one has not received any of the needed attention this cycle. With 6.1 due out in less than 12 hours, I'm going to punt.

[costdev]

This ticket was reviewed in the bug scrub. As the PR was closed, this ticket needs a new patch. Adding the appropriate keyword.

Additional Props: @afragen, @hellofromTonya

Trac ticket: https://core.trac.wordpress.org/ticket/55840

[petitphp]

Patch from @mukesh27 seems ok to me. I did more testing with multiple theme using the filter image_size_names_choose (see. ​https://wpdirectory.net/search/01GQFGC70R6ASDNSXNS0631KBX) and the names for the custom sizes are displayed correctly.

[antpb]

Assigning to myself to review and likely commit for 6.2

[robinwpdeveloper]

Thanks for the updated PR @petitphp
Both PRs are similar in the functionality, It's good to go to 6.2

Optional Feedback: If possible we can reduce the number of line changes to make it same as @mukesh27

[petitphp]

Thanks for the validation @robinwpdeveloper.

I've updated the PR with your feedback.

[costdev]

Myself and Mukesh reviewed this ticket. The PR looks ready for commit consideration, adding the keyword.

What do you think @antpb?

Additional props: @mukesh27

[costdev]

This ticket was scrubbed pre-6.2 Beta 1. Reclassifying this ticket as a defect (bug).

[johnbillion]

I'd be tempted to retain the full array element for consistency -- even though it's not used here -- as it's present in all other instances of that filter.

[azaozz]

Just FYI, medium-large is a "hidden" image size that is not (should not be) used anywhere in the UI. It was added only to support responsive images (srcset and sizes), same as the other two default image sizes: 1536x1536 and 2048x2048 (these are the "size names" in the image meta), see https://core.trac.wordpress.org/browser/tags/6.1/src/wp-includes/media.php#L5237.

Looking at the PRs, medium-large perhaps shouldn't be "translatable"? WordPress has only four image sub-sizes that are exposed in the UI: thumbnail, medium, large, full size (sometimes). The other three are not.

[antpb]

@johnbillion I added full and removed medium large from the array per @azaozz recommendation. Is the attached patch looking good for commit?

I suspect not having thumbnail is fine for this filter? Every other instance usually includes it. I can add if so before commit.

[petitphp]

Patch look good to me.

I suspect not having thumbnail is fine for this filter? Every other instance usually includes it. I can add if so before commit.

Since thumbnail is a special case and handle separately, I don't think it's useful to add it here.

[petitphp]

Edit image UI after applying patch 55840.3

[azaozz]

Replying to petitphp:

Since thumbnail is a special case...

The image_size_names_choose is used at 7 more places in core, and the array that is being filtered is consistent everywhere:

array(
	'thumbnail' => __( 'Thumbnail' ),
	'medium'    => __( 'Medium' ),
	'large'     => __( 'Large' ),
	'full'      => __( 'Full Size' ),
)

I don't think it is a good idea to make it different/inconsistent here.

As this will be the eight location of that filter, perhaps having a function that just applies the filter would be better? Not sure if image_size_names_choose() is a good name for a function though, perhaps something like wp_image_size_display_names() is better. Can make a patch a bit later if somebody doesn't beat me to it :)

[azaozz]

@petitphp Btw where do you see the settings as in patch_55840_3.png? This is a big "doing it wrong". The image handling in WP cannot handle editing only one sub-size, and it doesn't make any sense.

I'm actually thinking to remove the whole "Apply changes to..." thing. It was intended (as far as I remember) to allow people to switch from square (cropped) thumbnail to a proportional one or the other way round many many years ago, but it never worked well. (That was added to core because of pressure by a vocal minority at the time... Big mistake!!). I'll open a ticket to remove it.

[azaozz]

Related: #57685.

[azaozz]

Thinking more about it: because of #57685 this ticket could either be repurposed to add a helper function for image_size_names_choose or closed as "wontfix" and another ticket opened for the helper function. Anybody has any preference?

[petitphp]

@azaozz I was indeed using the edit_custom_thumbnail_sizes filter to display all individual sizes.

[antpb]

It was agreed in the Media meeting to move forward with a helper function. Moving this to 6.3 so we can scrub and create the new issue in the next cycle.

[antpb]

we still have pending the task of making a new issue for the helper function but have missed it in the 6.3 cycle. Moving 6.4 to keep it on our radar for our next scrub.

[oglekler]

It looks not like a bug, but more as an enhancement, so, I am changing the type.

[oglekler]

Because there is no development in the last 7 months, and we are getting close to Beta 1, I am moving it into 6.5. If there will be no progress, the next move should be to the Future release.

[audrasjb]

From today's bug scrub:
As this is an enhancement and since we’re still waiting for a patch, let’s move it to Future release milestone.
Happy to review and move it back to milestone 6.5 if a complete patch is proposed during the alpha cycle.