Improve strings quality and consistency

[pedro-mendonca]

Fixes #20186

Description

• Improve strings consistency for action labels with WP core pattern (Capitalize)
• Merge with similar existing strings.

[youknowriad]

I believe we explicitly switched recently to sentence case everywhere. Can you confirm @karmatosed?

[pedro-mendonca]

In titles or button labels?

[youknowriad]

Everywhere I believe.

See #16764 #19903 #19901 #18758 #18757

[aduth]

I'm confused as well, seeing efforts like #20209 which appear to be changing for consistency in the opposite direction 🤷‍♂

Are there any documented resources concerning this?

cc @Soean

[Soean]

@aduth
We have had this topic several times now. Here is an appropriate section from the Gutenberg Handbook. https://developer.wordpress.org/block-editor/contributors/document/copy-guide/#five-pay-attention-to-capitalization

I have not found anything suitable in the Core manual. Only this section. At the moment it is very inconsistent. In Gutenberg there are now some strings in different upper and lower case notations. The changes of the last weeks differ from the rest of the core project.

Should we add this topic to a meeting? Or is there a documentation page I haven't found yet?

[pedro-mendonca]

At the moment it is very inconsistent. In Gutenberg there are now some strings in different upper and lower case notations. The changes of the last weeks differ from the rest of the core project.

That is why I purpose this in the first place, because WP core is a bit more consistent at the moment.
Still, I wasn't aware of the latest decisions specificaly for Gutenberg.
Feel free to close this issue, as it's more WP core style oriented.

[aduth]

Seems like it would be good to reconcile. The guidelines for core are a bit sparse and don't really make clear (at least in my reading) what "Capitalization" entails when there are multiple words. Maybe we can move or adapt the Gutenberg guidelines?

To be clear, I don't have a preference one way or the other, just that there's consistency. Right now, it seems like there's conflicting consistencies between Gutenberg and the rest of core. A meeting might be the best place to resolve this. In the meantime, I would expect we probably either want to hold off on these specific changes, or conform to consistency with the Gutenberg guidelines and the rest of the codebase.

[aduth]

This one would probably still be good to fix regardless. I'm not really sure why this label is fully-capitalized?

cc @mkevins @pinarol @jorgefilipecosta re: #18265

If it's a UI thing, I'd wonder if there's some native equivalent to the web's text-transform: uppercase.

[mkevins]

This all-caps string was brought in by this commit: abd295d to be consistent with the other native media blocks:

gutenberg/packages/block-editor/src/components/media-placeholder/index.native.js

Lines 75 to 83 in 78de49e

	if ( instructions === undefined ) {
	if ( isImage ) {
	instructions = __( 'ADD IMAGE' );
	} else if ( isVideo ) {
	instructions = __( 'ADD VIDEO' );
	} else {
	instructions = __( 'ADD IMAGE OR VIDEO' );
	}
	}

I believe the text-transform property (textTransform on React Native) is now supported on both iOS and Android, so the native MediaPlaceholder could be refactored to use that. I'm not 💯 sure, but it may be that this was previously not possible (at the time these strings were introduced).

[pinarol]

I'm not really sure why this label is fully-capitalized?

It was a design decision. (@iamthomasbishop correct me if I am wrong.)

I believe the text-transform property (textTransform on React Native) is now supported on both iOS and Android, so the native MediaPlaceholder could be refactored to use that. I'm not 💯 sure, but it may be that this was previously not possible (at the time these strings were introduced).

This is tricky mostly because of non technical reasons. Our translation rates aren't perfect in some languages. Thus, if we use device locale to do the uppercasing, it might generate some unexpected results on strings that are not localized yet. In general, we don't usually do uppercasing/lowercasing for user facing Strings on mobile. Also these kind of uppercase strings are very rarely used.

[mkevins]

This is tricky mostly because of non technical reasons. Our translation rates aren't perfect in some languages. Thus, if we use device locale to do the uppercasing, it might generate some unexpected results on strings that are not localized yet.

Thanks for that extra context!

[aduth]

@pinarol I'm a bit unclear on whether you're suggesting we cannot or should not use textTransform? In my mind, the device transform would have the same result as the current implementation whether or not the string is translated, and I would think it would be preferable to err on the side of not ascribing that case in the string used in code (for consistency, and for improved reusability of that string).

[pinarol]

In some languages the uppercase of some letter is different than their uppercase in English. Like in Turkish, the uppercase of "i" is "İ", and the lowercase of "I" is "ı". So if we programmatically uppercase "Add Media" using TR locale it'll become "ADD MEDİA" which is not correct. This wouldn't be a problem if we had good translation support on every language but in some languages users see a mixture of English & X language words. So we'll be uppercasing English words using X locale, which is why I want to avoid using dynamic uppercasing/lowercasing.

But I agree that we should aim for improved reusability, so let me loop in @iamthomasbishop and see what he thinks about dropping the fully uppercase "ADD MEDIA" in favor of "Add Media"?

[iamthomasbishop]

From a native-mobile perspective, I would definitely prefer writing the strings in one way (sentence-case to align w/ Core) and programatically transform based on the target platform's component/label guidelines.

In other words, we'd always write the string as sentence-case (for example: Xxx xxxxx or Add media). From there, we would transform casing on RN based on the platform guidelines for the corresponding component (button == uppercase on Android and title-case on iOS, whereas a normal text-label title would be sentence-case on Android and title-case on iOS).

Does this make sense? I also remember someone mentioning that we aren't able to reliably use text-transform on RN, but not sure if that's resolved.

[aduth]

Based on the linked precedent, it's my understanding that these changes would not be desirable, currently favoring sentence case per the following guidelines:

https://developer.wordpress.org/block-editor/contributors/document/copy-guide/#five-pay-attention-to-capitalization

See also:

• Expanding on sentence case to everywhere else #18758
• Copy: Inconsistent capitalization of labels in tooltips and dropdown menus #16764
• Copy: Setting Sidebar controls case inconsistencies #19902
• Apply sentence case formatting to Setting Sidebar controls #19903

Separately, we should discuss the inconsistencies between Gutenberg and the rest of wp-admin. I requested that this be discussed in tomorrow's (2020-02-26) editor meeting:

https://make.wordpress.org/core/2020/02/25/editor-chat-agenda-26th-february-2020/#comment-37980

Based on the outcome of that discussion, it may or may not be warranted to revisit this, but as part of a larger effort of strings consistency.