• Resolved Tor-Bjorn Fjellner


    Hi, while I was looking at the Swedish translation of this plugin, I noted several strings that rather look like programming parameters, which one really shouldn’t translate.

    Here’s one example from your code:
    $ban_type = $this->_input->__('ban_type', 'ban_forever');
    I have a feeling that you here actually didn’t intend to use the translation function __() (and even with incorrect text-domain…)

Viewing 7 replies - 1 through 7 (of 7 total)
  • Plugin Author PeepSo, Inc.


    It’s the fault of POT that mistakes methods like PeepSoInput::__(string, string); as gettext

    These have to be simply ignored

    If that’s the case, then perhaps the structure CommandOrMethod::__(string, string) isn’t such a good choice.
    After all _() is a standard formula used by gettext, and __(), since long, is the wrapper of the same function in a platform (WordPress) that happens to power a really big part of the web…

    Alternativtely, you could suggest updates to the string scraper code so that it wouldn’t pick up these strings…
    WordPress.org doesn’t even look at any pot-file you may have supplied. The plugin directory automatically scrapes every update for strings using a matching algorithm for wrapped gettext functions.

    Plugin Contributor Matt Jaworski


    Unfortunately, we didn’t realize WP/gettext is too “stupid” to handle this until it was too late. And changing the method name again is not that simple because all child plugins are using them and we have 3rd party developers using them too.

    Are you looking via Crowdin or the WP.org translation engine? Because we generally use Crowdin and the “weird” string have been blacklisted there.


    • This reply was modified 2 years, 2 months ago by  Matt Jaworski.
    • This reply was modified 2 years, 2 months ago by  Matt Jaworski.
    Plugin Contributor Matt Jaworski


    I’ve put an improvement ticket for this. Right now it’s scheduled for 1.8.1 milestone, we will try and rename the method to something else without breaking compatibility with out own plugin “universe”.

    I’m working with the translation environment at translate.wordpress.org. If it would be possible to rename your method, that’s possibly the best approach. An alternative solution might still be to add an exclusion for the code scanner that import strings to polyglot for translation.
    (By the way, I’m afraid that even poedit has a is similarly stupid scanner, but nobody would get the idea to scan specifically your WordPress plugin with that one, though, at least if you provide an always updated .pot with each release…)

    A stop-gap might be to add comments to translators on the immediately preceding line. Here’s an example from the developer handbook:

        /* translators: 1: Name of a city 2: ZIP code */
        __( 'Your city is %1$s, and your zip code is %2$s.', 'my-plugin' ),

    So you might add a line like:
    /* translators: No need to translate this one. Just copy the English version */

    The reason I suggest to do it this way is that any translation package would start getting distribution only after 95% readiness is reached.

    Plugin Contributor Matt Jaworski


    Yup, but we are talking about 500+ occurences here, so adding a comment each time is not really something we want to do.

    We will rename the method – need to run a project wide “find and replace” on the codebase of all 20ish plugins, and then manually verify everything, plus fire the entire automated testing run just to make sure nothing broke.

    1.8.0 is already in code freeze, so it will be “fixed” in 1.8.1. The timeframe for that release is not set yet, though.

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘Possible code error’ is closed to new replies.