Warning not in bold?

[NekoJonez]

Most of the warnings in WP have the "warning" part in bold. Yet, there are a few that aren't in bold.

Except these:

​https://build.trac.wordpress.org/browser/tags/5.9.2/wp-includes/functions.php?marks=1583#L1582
​https://build.trac.wordpress.org/browser/tags/5.9.2/wp-includes/class-wp-theme.php?marks=284#L283

For the sake of being consistent, shouldn't these have bold tags as well?

[Presskopp]

related #37280

[NekoJonez]

In the latest dev builds, the locations are changed:

​https://build.trac.wordpress.org/browser/trunk/wp-includes/functions.php?marks=1582#L1592
​https://build.trac.wordpress.org/browser/trunk/wp-includes/class-wp-theme.php?marks=284#L285

[SergeyBiryukov]

Thanks for the ticket!

Updated the description with permanent links so that the locations do not change. Removing the version, as these messages were not introduced in 5.8.2 or 5.8.3.

It looks like most of the "Error:" prefixes in core are placed inside a <strong> tag, so I think it makes sense to do the same here.

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

[audrasjb]

We reviewed this patch during WordCamp Geneva 2022’s contribution workshop.

The above PR was meant to test the provided patch.
Looks like tests are passing.
Self assigning for commit.

[audrasjb]

In 53118:

General: add missing strong tag to some error messages.

Props NekoJonez, oakesjosh.
Fixes #54437.

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

[NekoJonez]

I'm reopening this, since I found another one during translation.
​https://build.trac.wordpress.org/browser/trunk/wp-admin/includes/ajax-actions.php?marks=1294#L1294

During development of 6.0, a trac ticket of mine was fixed. This was adding strong tags in warnings. Yet, during translation I found two others.

Trac ticket: (https://core.trac.wordpress.org/ticket/54437)

I should have checked the other branches before submitting this PR... Now, I have found another one. All branches have been checked and I think I got them all.

[audrasjb]

Thanks @NekoJonez 👍

[NekoJonez]

Replying to audrasjb:

Thanks @NekoJonez 👍

No problem @audrasjb sorry for not checking the other translation branches as well before first submitting the PR... Now, I got them all so I think if no objections in this PR happen it's all fine to go and get this ticket re-fixed :)

@NekoJonez tests are now failing though:

1) Tests_Ajax_ReplytoComment::test_with_draft_post
Failed asserting that exception message '<strong>Error:</strong> You cannot reply to a comment on a draft post.' contains 'Error: You cannot reply to a comment on a draft post.'.

You need to also update unit tests :)

@NekoJonez tests are now failing though:

1) Tests_Ajax_ReplytoComment::test_with_draft_post
Failed asserting that exception message '<strong>Error:</strong> You cannot reply to a comment on a draft post.' contains 'Error: You cannot reply to a comment on a draft post.'.

You need to also update unit tests :)

As a noob in this, some help with that would be nice.

@ocean90 , I removed all strong tags in the AJAX php file... And tests are still failing.
Do those strong tags also need to be removed in the other files?

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

@NekoJonez I opened another PR to fix the failing unit tests: ​https://github.com/WordPress/wordpress-develop/pull/2669
Does it look good to you?

@NekoJonez I opened another PR to fix the failing unit tests: ​https://github.com/WordPress/wordpress-develop/pull/2669
Does it look good to you?

@audrasjb Excellent. Now I dont have to worry about why my things are failing.

Closing in favor of ​https://github.com/WordPress/wordpress-develop/pull/2669

Excellent! Thank you @audrasjb for this help. I have no idea why for me the unit tests were failing.

[audrasjb]

In 53337:

General: Add missing strong tag to some error messages.

This changeset adds missing strong tag to some error messages and updates some AJAX messages, for better consistency.

Follow-up to [53118].

Props NekoJonez, audrasjb, ocean90.
Fixes #54437.

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

[SergeyBiryukov]

We're currently in ​soft string freeze as per the ​6.0 release schedule, so no strings should be changed at this point, except for the About page. I have no strong objections to leaving this change in 6.0, but as these strings don't seem new, I think it would have been better to handle this in a separate ticket early in 6.1 instead, same as #55661.

[audrasjb]

@SergeyBiryukov yes, but it appears this issue was spotted while translating 6.0 strings, so in my understanding – and I might be wrong :) – the current phase of the release cycle is the good timing to fix issues?

[SergeyBiryukov]

I think it would be a good timing if these strings were new in 6.0, or somehow edited earlier in this release cycle, or somehow connected to the strings changed in [53118].

It's probably not much of an issue, just a matter of sticking to our own release schedule and something to keep in mind for future releases to avoid adding unexpected work for translators.

Adding the i18n-change keyword as per ​Trac Workflow Keywords.

[audrasjb]

Ok got it, thanks. To clarify: I didn't notice those strings were not new ones, introduced in 6.0 :)

[peterwilsoncc]

@SergeyBiryukov, @audrasjb

I'm concerned about leaving [53337] in 6.0 too.

How would it work if this was reverted:

• have the language packs been updated since RC1?
• fuzzy matching would pick up the strings from the 5.9 project, would polyglots need to re-approve the old strings?

[audrasjb]

@peterwilsoncc it is already declared as a fuzzy string for WP 6.0.
See ​https://translate.wordpress.org/projects/wp/dev/admin/fr/default/?filters%5Bstatus%5D=either&filters%5Boriginal_id%5D=10187702&filters%5Btranslation_id%5D=75028029 for example.
I'm really sorry for the misundestanding and it is my mistake, but now, reverting the change would add even more work to polyglots teams.

[peterwilsoncc]

Don't worry about it too much, we all have misunderstand something at one point or another. I've done similar and worse ;)

Thank for helping my understanding of how fuzzy matching works. It seems best to avoid making things harder for the translation teams.