Plugin is not parsing _nx() string translations

  • Hi there,
    first of all thanks for great plugin. I’ve been using it for years.

    Second of all – there seems to be an issue, that loco translate by default is not searching for _nx() translation strings, therefor you need to add this function manually in settings. It took me a while until I figured out that WooCommerce string printf( _nx( 'Showing %1$d–%2$d of %3$d result', 'Showing %1$d–%2$d of %3$d results', $total, 'with first and last result', 'woocommerce' ), $first, $last, $total ); cannot be parsed because the function is not defined within Loco or plugin config by default. After manually adding _nx to parsable functions I got around 1867 new non-translated WooCommerce strings, which is a lot of unread translation strings in my opinion (enough to post support topic :D).

    Hope this helps and you’ll add it as default function.

    • This topic was modified 3 years, 4 months ago by richardevcom.
    • This topic was modified 3 years, 4 months ago by richardevcom.
Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Author Tim W

    (@timwhitlock)

    there seems to be an issue, that loco translate by default is not searching for _nx() translation strings

    The _nx function is supported and I have no problem extracting strings from your code using Loco Translate’s parser.

    After manually adding _nx to parsable functions I got around 1867 new non-translated WooCommerce strings

    I don’t follow this. Loco Translate doesn’t provide any mechanism to add parsable functions unless you mean you modified my source code. If you had modified the code, you’d see the function was already there.

    Thread Starter richardevcom

    (@richardevcom)

    @timwhitlock really weird. I tested on local test environment and WooCommerce _nx() translation strings behave the same.

    Yeah, manually (for testing purposes).

    I’ll double check that there is an error and it’s really not on my end and get back to you soon.

    Plugin Author Tim W

    (@timwhitlock)

    Yeah, manually (for testing purposes).

    How? How did you add _nx to parsable functions when Loco Translate has no mechanism to do this?

    If you are clearer about what you’ve done I may be able to spot where you’ve gone wrong or where there might be confusion.

    Thread Starter richardevcom

    (@richardevcom)

    In my case I edited POT file with another editor and added parsable function (translatable string function name) _nx and reupload it. As explained above, WooCommerce has some _nx strings and all of them were not read by Loco Translate. To read them first test workaround I did to make sure its because Loco Translate can’t read _nx was to rename it to _n and it worked. Then I just passed _nx to POT file an that’s all.

    If you’re stating that Loco does parse _nx then I have to double check it was Locos fault in first place and get back to you with my findings.

    • This reply was modified 3 years, 4 months ago by richardevcom.
    • This reply was modified 3 years, 4 months ago by richardevcom.
    Plugin Author Tim W

    (@timwhitlock)

    As explained above, WooCommerce has some _nx strings and all of them were not read by Loco Translate

    Loco Translate only reads these functions when you Sync a POT file to the source code. The POT file that ships with WooCommerce (woocommerce.pot) already defines the string you are referring to, so there would be no need for Loco Translate to know anything about it.

    I can guarantee to you that _nx functions are parsed when strings are extracted from PHP files into POT templates, but I recommend you don’t do this when there is already a valid POT file provided.

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Plugin is not parsing _nx() string translations’ is closed to new replies.