WordPress.org

Make WordPress Core

Opened 3 weeks ago

Last modified 3 weeks ago

#41551 new enhancement

Officially support use of null for text domain name parameter to l10n functions

Reported by: bobbingwide Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: trunk
Component: I18N Keywords:
Focuses: Cc:

Description

I am working on some code which shares library files between plugins / themes. A plugin or theme that needs to use some particular logic is able to require a library then assuming it's been loaded successfully, make use of the logic. Multiple plugins may deliver a library file but only one instance of a library file is loaded. Common logic implements version and dependency checking and therefore prevents run time fatal errors due to functions or classes being redefined.

The solution works fine, but it poses some challenges with regards to localisation of any strings that are used in the shared library files.

Having investigated a number of potential options I have concluded that a viable solution can be implemented by using some "Just Translate It" logic that is text domain agnostic.

The simplest implementation depends on the use of a null value for the $domain parameter to functions such as __().

This TRAC requests that WordPress core officially sanctions this use of null.

I have developed some unit tests that demonstrate that the current code works fine.

I don't think it's necessary to change any of the docblocks in l10n.php

If required I will furnish more documentation that explains the "Just Translate It" approach.

Attachments (1)

41551.diff (1.6 KB) - added by bobbingwide 3 weeks ago.
PHPUnit tests for translation using a $domain parameter value of null

Download all attachments as: .zip

Change History (3)

@bobbingwide
3 weeks ago

PHPUnit tests for translation using a $domain parameter value of null

#1 follow-up: @swissspidy
3 weeks ago

Note that internationalization is just one aspect of the whole picture. The strings need to be translated somewhere. When you're using a library that's shared by 2 plugins, where on translate.wordpress.org is that library going to be translated?

It's currently a recommendation/rule that plugins and themes only contain 1 text domain that should also match the plugin/theme slug.

That's why libraries like TGMPA suggest passing the needed strings to them, so that the library itself doesn't contain any. See https://github.com/TGMPA/TGM-Plugin-Activation/blob/189ed5d6a2767f554135cc9041e6f4927b396dd9/example.php#L135-L210.

Regarding 41551.diff, it basically treats null like any other valid text domain, which looks kinda weird and unexpected, and could lead to some serious troubles. Why null? It could just as well be any other random string, no?

#2 in reply to: ↑ 1 @bobbingwide
3 weeks ago

For the reasoning behind "Just Translate It "see https://github.com/bobbingwide/oik-libs/issues/7#issuecomment-320028566

Replying to swissspidy:

Note that internationalization is just one aspect of the whole picture. The strings need to be translated somewhere. When you're using a library that's shared by 2 plugins, where on translate.wordpress.org is that library going to be translated?

Since each plugin will contain the source files, makepot will find the strings. The translations will then become available in the plugin's text domain. The "Just Translate It" logic will merge the available translations into the null domain so a translation will be found if one has been supplied.

It's currently a recommendation/rule that plugins and themes only contain 1 text domain that should also match the plugin/theme slug.

Yes I know. But it's not enforced. Not all plugins / themes are on wordpress.org.

That's why libraries like TGMPA suggest passing the needed strings to them, so that the library itself doesn't contain any. See https://github.com/TGMPA/TGM-Plugin-Activation/blob/189ed5d6a2767f554135cc9041e6f4927b396dd9/example.php#L135-L210.

Another duplication of translator's effort. And it means the calling routine has to be fairly well aware of the library's implementation.

Regarding 41551.diff, it basically treats null like any other valid text domain, which looks kinda weird and unexpected, and could lead to some serious troubles. Why null? It could just as well be any other random string, no?

Yes, it could be any other random string. Null is the simplest form.
Once the null text domain has been built, then the translations will be found by existing translate() logic.

If I used a whole suite of different text domains, one for each library, then I'd need to use a different solution for determining when "Just Translate It" logic is required. The code gets a lot messier.

The purpose of this TRAC is to formally request that WordPress core recognises and supports the use of null.

Note: See TracTickets for help on using tickets.