load_textdomain() fails to merge in additional translations

[muranyia]

I was initially investigating why I cannot load a supplementary translation for a plugin from a template using load_plugin_textdomain(), for which the function reference claims that "If you call load_plugin_textdomain multiple times for the same domain, the translations will be merged.".

At the end it seems to me that it is load_textdomain() that fails to merge in the additional translations. Interestingly the function reference says "If the domain already exists, the inclusion will fail.", however in source:tags/4.7.3/src/wp-includes/l10n.php#L589​ merge_with() is called, with the clear intention of merging the new translation with the old one.
My observation is that the merging does not happen, and only one translation can be effective at a time.

According to my tests, using an ordinary assignment (=) instead of a referential assignment (=&) at source:tags/4.7.3/src/wp-includes/l10n.php#L593​ solves this problem.

[ocean90]

Hello @muranyia, thanks for your ticket!

This sounds like a duplicate of #37819. Can you confirm that?

[muranyia]

Replying to ocean90:

Hello @muranyia, thanks for your ticket!

This sounds like a duplicate of #37819. Can you confirm that?

Hi,
Yes and no. In #37819 the goal seems to be to overwrite loaded tramslations, which the documentation never claimed you could do, although it's a feature that would certainly make sense. The function reference for load_plugin_textdomain() says: "If you call load_plugin_textdomain multiple times for the same domain, the translations will be merged. If both sets have the same string, the translation from the original value will be taken."
This bug simply suggests a fix so that code works as documented, as the use of the referential assignment seems to be a typo that serves no purpose.
Any further decision whether overwriting translations shall be possible (i.e. what is default direction of merging) can be done separately from this issue/fix, and (imho) shall be done in fashion that doesn't break existing applications that utilize these functions.

So, attachment:37819.2.diff:ticket:37819​ aims to solve the defunct assignment AND to reverse the direction of the merging. I suggest that the assignment is fixed a.s.a.p and then the idea of changing the merging logic is evaluated more carefully.

Nevertheless, you are free to consider this a duplicate and I can do my comments at #37819.

[muranyia]

Duplicate of #37819.