Support » Plugin: Loco Translate » Incorrect use of _n()

  • ResolvedModerator Yui



    When working with the translation of your plugin I noted one incorrect use of the function _n().


     _n("1 string marked Fuzzy","%s strings marked Fuzzy",0,'loco-translate');

    _n() should be used only when the phrase contains a specific number, for instance:
    You have X login attempts remaining.
    X e-mails have been deleted.

    Russian, as an example, the tranlator needs to write three (3) diffeerent translation whenever _n() is used.
    The first one (singular) is used for 1, 21, 31, 41… 101, etc.
    The second one (dual) is used for 2, 3, 4, 22, 23, 24… 102, 103, 104, etc.
    The third one (plural) is used for everything else.

    In other words, if you would happen to have 21 invalid form names, then a website that is configured to use Russian would present that phrase in singular!

    There are other languages that maintain 5 or even 6 different plural forms, all depending on which specific number you’ve got in your phrase.

    It is better to create a separate string for singular.

    Please see:
    and subsequent comments.
    You can also refer to this topic:

Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Author Tim W


    My source singular should read “%s string marked Fuzzy” because the intention is NOT that the first form be used for exactly one.

    This is merely bad form on my part using a literal “1” in the English singular. I hadn’t considered that this might be misleading to translators, causing them to copy the “1” into their first form. Mostly they don’t though, which is why this hasn’t been picked up since it was added in 2017.

    Interestingly in this example the original Russian translator had added the first form correctly using a placeholder and then later another translator changed it to a literal “1” making the translated text incorrect. That change was approved by you almost three years ago.

    I accept that my style is also bad for validation so does need changing. Doing so will obviously invalidate a lot of source strings and cause translators unnecessary work. I would not do that if there were no erroneous translations out there, but it seems there are. So I will make this change and mark resolved when in trunk.

    Plugin Author Tim W


    I’ve fixed this in trunk now. You will see that all languages that were at 100% are now at 98% after four source strings were changed.

    Moderator Yui



    Thank you.
    Fixed the fuzzies for russian.

    CC notification @kleindberg


Viewing 4 replies - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.