String for "Light" has different contexts in Chinese

[ironprogrammer]

Background

Original forums topic: ​https://wordpress.org/support/topic/i18n-issue-5-9-rc1-string-light/
Credit: @alexclassroom
Version: 5.9 RC1

(This ticket is submitted on behalf of a forums user/contributor.)

Reported Issue

The string “Light” used in these files means different things:

1. wp-includes/class-wp-theme.php:985
"Light" refers to a light color.

2. wp-includes/js/dist/block-editor.js:22719
"Light" refers to a light font weight.

Per contributor, for zh_TW, the first translation ("light color") is “淺色”, and the second translation ("light font weight") is “細體”.

As "Light" can be used in different contexts, it should be separated into two strings.

Submitter's note: This should also be checked against zh_CH or similar variants.

[audrasjb]

It would indeed make sense to contextualize the color related strings, using a gettext context (see function _x). Chinese is not the only language with the same issue.

I think it's a bit late for WP 5.9, but we can milestone this to WP 5.9.1.

I'm moving this to 5.9.1, but also pinging @SergeyBiryukov and @tobifjellner for any suggestion on the best milestone for this change (5.9.1? 6.0? or even 5.9?) :)

[tobifjellner]

I'd still shoot for 5.9:

• It's a change that is expected to be non-breaking.
• Since appr. one year, lacking translations of a few (lately arrived) strings doesn't block the creation of a localized build.

And yes, the same problem "light (color)" != "light (weight)" exists in Swedish and Russian, too. :)

[Presskopp]

there are 2 strings "light" in core:

one with context "admin color scheme", which is correct and could be reused, maybe with a change of context to "color scheme" or similar

and one without context (the one the ticket is about)

this is affecting german as well and should be corrected asap

[audrasjb]

First, thanks for the quick feedback!

Hm. Looking at class-wp-theme.php the only not contextualized "light" string used in core is here: ​https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-includes/class-wp-theme.php#L985

And it looks like it is used for some deprecated tags.
See the comment right above the string:
// As of 4.6, deprecated tags which are only used to provide translation for older themes.

Therefore, it doesn't looks like something really urgent, since changing the string used in the editor will only introduce a wrong translation on an unused string. What do you think? Worth contextualizing the old and deprecated string before 5.9 is released?

[tobifjellner]

So wp-includes/js/dist/block-editor.js would need to get contextualized as soon as possible = 5.9.

For those deprecated tags a comment to translators would be good to add. But we can't add context there, since those legacy themes would then not match.

[noisysocks]

If we want to update wp-includes/js/dist/block-editor.js then we need to do it via a PR in the Gutenberg repo.

[SergeyBiryukov]

Replying to tobifjellner:

For those deprecated tags a comment to translators would be good to add. But we can't add context there, since those legacy themes would then not match.

I think we can, as themes would only have a light tag in English in style.css, not the translation of it. So it should be fine to add a context for this string in core for clarity, the themes won't need to change anything.

[audrasjb]

PR available upstream: ​https://github.com/WordPress/gutenberg/pull/37939

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

[audrasjb]

The above PR is for core. @SergeyBiryukov are you ok with this being committed and then backported to 5.9?

[hellofromTonya]

These strings were not introduced in 5.9:

• 'Light' string in the wp-includes/class-wp-theme.php was introduced in 4.6 (see #33407 and changeset [37946]).

• 'Light' string in the js/dist/block-editor.js file was introduced in 5.7.

Marking this patch for commit to trunk.

What about backporting to 5.9 branch?

As these strings were not introduced in 5.9 and 5.9 is in the RC cycle, I'm hesitant to do the backports. Deferring to @SergeyBiryukov or another committer with i18n expertise to provide guidance.

[audrasjb]

Yes, these changes were introduced before, but the interference comes from 5.9 and global styles. So I think the issue itself only shows itself in 5.9.

(thanks for peer reviewing btw!)

[audrasjb]

Alright, in the meantime, let's commit this to trunk now.

[audrasjb]

In 52588:

i18n: Contextualize "light" color translation strings.

This change helps translators to distinguish between color and font-family contexts.

Props ironprogrammer, audrasjb, tobifjellner, Presskopp, SergeyBiryukov, hellofromTonya.
Fixes #54804.

Committed in https://core.trac.wordpress.org/changeset/52588

[audrasjb]

Reopening for potential backport consideration.

[SergeyBiryukov]

Replying to hellofromTonya:

As these strings were not introduced in 5.9 and 5.9 is in the RC cycle, I'm hesitant to do the backports. Deferring to @SergeyBiryukov or another committer with i18n expertise to provide guidance.

If I understand correctly, for 5.9 this is already solved in [52596], which includes ​PR 37939 from Gutenberg.

Adding context to either one of the strings (done in the PR above) solves the issue, so I think [52588] is no longer strictly necessary at all. If we'd like to keep it for 6.0 just in case, I would suggest a couple of changes:

• Let's change the context to color scheme, as I think the string is more about the color scheme of a theme than any particular color.
• Let's add the same context to the "Dark" string too, for consistency.

[audrasjb]

Alright, thanks you for your feedback @SergeyBiryukov !
Let's move this to 6.0, so we can address the underlined context changes :)

[hellofromTonya]

Changing the version to 4.6 as [37946] introduced the Light, Dark, etc. strings.

[SergeyBiryukov]

In 52603:

I18N: Improve the context for color-related strings in WP_Theme::translate_header().

• Use the color scheme context for the "Light" string, for more accuracy.
• Add the same context to the "Dark" string too, for consistency.

Follow-up to [37946], [52588].

Fixes #54804.