Define 'Word count type' as a WP_Locale property

[pedromendonca]

i18n: Define Word count type as a WP_Locale property.

As commented on https://core.trac.wordpress.org/ticket/47511#comment:19, the word count type should be added as a locale property, so it doesn't need to be translated separately across multiple projects.

Many plugins and themes could use it without the need to set their own _x( 'words', 'Word count type. Do not translate!' ) translation string.

This proposal has the exact same approach as of the recent creation of wp_get_list_item_separator() on ​https://github.com/WordPress/wordpress-develop/commit/a37a72077e90a04e4fa6205c6e99fb6614d3bc0d

This proposal implements the following:

• Define word count type as a new WP_Locale property
• Add wp_get_word_count_type() as a wrapper for WP_Locale::get_word_count_type
• Replace all _x( 'words', 'Word count type. Do not translate!' ) strings with wp_get_word_count_type()

Related tickets: #47511, #39733

Add word count type as a locale property, so it doesn't need to be translated separately across multiple projects. This PR implements the following modifications:

• Define word count type as a new WP_Locale property
• Add wp_get_word_count_type() as a wrapper for WP_Locale::get_word_count_type
• Replace all _x( 'words', 'Word count type. Do not translate!' ) strings with wp_get_word_count_type()

Trac ticket: 56698

[desrosj]

Introduced in [33517].

[costdev]

After this ticket was reviewed in the bug scrub, I'm adding the needs-unit-tests, needs-testing-info and needs-testing keywords.

In addition, I've left a requested change on ​PR 3377 to use str_starts_with() instead of strpos() === 0. Adding the changes-requested keyword.

Additional props: @hellofromTonya

[mukesh27]

This ticket was discussed in the recent bug scrub.

@pedromendonca Can you update @since annotations and add unit tests for the changes?

Props to @costdev

[johnbillion]

Pedro's comment on the PR is correct, we don't need to worry about @since tags in patches and PRs as whoever commits the change will ensure the correct value is used.

[pedromendonca]

@mukesh27 I've j ust added some tests for all possible cases.
Let me know if it's ok.

Thank you :)

[costdev]

This ticket was discussed during the bug scrub. I'll submit a refreshed patch that addresses some work needed with the tests, and then I think this will be ready for commit before the 6.2 Beta 1 release party later today.

Additional props: @mukesh27

_This PR is a refresh of #3377 to improve the tests prior to 6.2 Beta 1_

Adds a word_count_type property, so that it does not need to be translated separately across multiple projects.

• New property: WP_Locale::word_count_type.
• New method: WP_Locale::get_word_count_type().
• New function: wp_get_word_count_type() as a wrapper for WP_Locale::get_word_count_type().
• All _x( 'words', 'Word count type. Do not translate!' ) strings have been replaced with a call to wp_get_word_count_type().

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

[costdev]

I have submitted ​PR 4019 to address some work needed in the tests. Adding for commit consideration.

[pedromendonca]

Thanks @costdev for the improvements in the tests.
I would suggest a different wording for the keys of the data provider array.
There is one a valid option, when in fact the valid ones are three, maybe prefixing them is clearer:

• valid - words
• valid - characters_excluding_spaces
• valid - characters_including_spaces

What do you think?

[costdev]

Thanks @pedromendonca! I've updated the PR to note the valid options.

[audrasjb]

In 55279:

I18N: Introduce word_count_type property to WP_Locale.

This changesets adds a word_count_type property, so that it does not need to be translated separately across multiple projects.

List of changes:

• New property: WP_Locale::word_count_type.
• New method: WP_Locale::get_word_count_type().
• New function: wp_get_word_count_type() as a wrapper for WP_Locale::get_word_count_type().
• All _x( 'words', 'Word count type. Do not translate!' ) strings have been replaced with a call to wp_get_word_count_type().

Props pedromendonca, desrosj, costdev, mukesh27, johnbillion.
Fixes #56698.

committed in https://core.trac.wordpress.org/changeset/55279

[kraftbj]

I have a case where wp_trim_words being used in a mu-plugin before $wp_locale is set.

wp_trim_words is calling wp_get_word_count_type and then directly calling on $wp_locale->get_word_count_type.

Would there be any objection to a patch that does something like this:

function wp_get_word_count_type() {
	global $wp_locale;
	if ( ! ( $wp_locale instanceof WP_Locale ) ) {
		// Default value of get_word_count_type.
		return 'words';
	}

	return $wp_locale->get_word_count_type();
}

wp_trim_words can be called earlier in the stack than when the WP_Locale is currently set (during theme setup).

This adds some defensive coding to ensure a value is returned without a fatal error. The default value of words is used.

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

[SergeyBiryukov]

In 55295:

Docs: Document possible return values for wp_get_word_count_type().

Follow-up to [55279].

See #56698.

[SergeyBiryukov]

Replying to kraftbj:

I have a case where wp_trim_words being used in a mu-plugin before $wp_locale is set.

wp_trim_words is calling wp_get_word_count_type and then directly calling on $wp_locale->get_word_count_type.

Good catch, thanks!

The suggested approach looks good to me. wp_get_list_item_separator() could use a similar change for consistency.

Commit incoming :)

[SergeyBiryukov]

In 55351:

I18N: Check that $wp_locale global is set before calling its methods.

This avoids a fatal error if these functions are called in a mu-plugin before $wp_locale is set:

• wp_get_list_item_separator()
• wp_get_word_count_type()

Follow-up to [52929], [52933], [55279], [55295].

Props kraftbj.
Fixes #56698.

Thanks for the PR! Merged in r55351 with some minor edits.

[milana_cap]

Dev note ​https://make.wordpress.org/core/2023/03/03/i18n-improvements-in-6-2/