Textdomain loaded even though translations do not exist bc textdomain have identical start phrase

[kkmuffme]

If I have 2 different plugins where the textdomain starts with the same characters, e.g. 2 different plugins with textdomains are:
do-something
do-something-else

I have translations for do-something-else, but not for do-something.

Because of ​https://github.com/WordPress/wordpress-develop/blame/trunk/src/wp-includes/class-wp-textdomain-registry.php#L317 WP thinks that "do-something" textdomain has translations too, which is wrong

I found this accidentally due to the changes in WP 6.7 https://core.trac.wordpress.org/ticket/44937

@swissspidy since the fix for this is simple enough, maybe this can be backported and shipped with 6.7

[swissspidy]

Thanks for your report, I‘ll check it out.

6.7 is shipping next week, so this is not something for that release, but something for the next major.

[swissspidy]

I think this was even introduced in #57116 / [55010] in 6.2, so been around for longer.

Prevents the protected $domains_with_translations property in WP_Textdomain_Registry from being wrongly populated if translations exists for "some-plugin" but not "some".

Not sure if this actually causes any bug, as this information is only used in WP_Textdomain_Registry::has(), which already returns early if $this->current[ $domain ] is set or $this->all[ $domain ] is empty.

$domains_with_translations was introduced in https://core.trac.wordpress.org/changeset/55010 (​https://github.com/WordPress/wordpress-develop/pull/3640) but it actually doesn't seem to serve a purpose... Not sure what i was thinking there. But if I remove it, then nothing actually breaks.

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

[swissspidy]

Are you actually running into any bug here? 🤔 I am looking into this at ​https://github.com/WordPress/wordpress-develop/pull/7735 but right now it seems like it's pretty much dead code.

[kkmuffme]

I didn't have time to debug it in detail yet, I just saw lots of repeated calls for $wp_textdomain_registry->get( 'do-something' in a workflow where the locale was switched and textdomains unloaded (e.g. cron sending emails in 12 different languages)

<?php
        if ( ! $wp_textdomain_registry->has( $domain ) ) { // this returned true for do-something
                return false;
        }

I just took a look at it now quickly, and it seem, and it seems that it's not actually bc of ​https://github.com/WordPress/wordpress-develop/pull/7735/files#diff-00d2e07a27c8cddbc39e516791b3afbbc2b4517b3000b7ad167e45b91e8e81a3L124 but bc ​https://github.com/WordPress/wordpress-develop/pull/7735/files#diff-00d2e07a27c8cddbc39e516791b3afbbc2b4517b3000b7ad167e45b91e8e81a3R125 is set and therefore it returns true (in_array( $domain, $this->domains_with_translations, true ) seems indeed to be dead code, but it would make it return true too incorrectly)

I'm not really familiar with WP's i18n, but does it sound plausible to you that isset( $this->current[ $domain ] ) || is still set after the language was switched? (or the textdomain unloaded manually)

[swissspidy]

I‘d need some code to reproduce in order to be able to tell for sure.

The email use case is a good hint.

[swissspidy]

By the way does this still happen with ​https://github.com/WordPress/wordpress-develop/pull/7713?

[kkmuffme]

Sorry, can't test this atm - I figured out one reason for this (and the other issue I reported) - bc the "doing it wrong" PR was changed between the different RCs/PRs and I somehow was running not on the latest RC.

[firebird75]

@swissspidy I have tested your fix from ​https://github.com/WordPress/wordpress-develop/pull/7713 and I can confirm that it fixes the issue. Would be great to ship it with 6.7.1 because the issue is really widespread.

[swissspidy]

@firebird75 What issue does it fix for you exactly? 🤨 The PR actually was created to address #62337, which is indeed slated for 6.7.1 but is about something slightly different.

[firebird75]

@swissspidy it fixes an issue that I have experienced in 6.7 where the plugin language files aren't loaded and it defaults to english. I have applied your fix on the WP core files and this fixed the problem :)

[swissspidy]

@kkmuffme Any update on this? Are you still running into issues on 6.7.1 or trunk?

[kkmuffme]

Sorry, didn't have time to test this - as there are lots of plugins that have issues and need to be reported and fixed.

Something I did realize though is, that now while lots of plugins move their translation late(r), what often happens still is that they load the user too early - which in turn sets the locale too early - basically https://core.trac.wordpress.org/ticket/62393 and therefore is essentially the same issue again (and probably tons of plugins struggling to fix their code again if/once that is implemented, just like what happened now :D