Default translate function failing with TranslatePress

  • Resolved maschmiede

    (@maschmiede)


    8 months, 2 weeks ago

    In a WordPress 6.5.5 with TranslatePress 2.8.1 (+ Business Edition 1.4.0) we try to translate a text inside a custom extension which calls a gettext function like:

    $test = __('Publishing', 'my-lang-domain');

    When we add this to the frontend and use it for example for a url get parameter and debug this parameter with a normal var_dump(); we get the expected string(10) "Publishing". Also the translation to (in this case German) works fine and also return with the right value string(12) "Verlagswesen".

    Here is our problem: When we try to match the get parameter with the $test variable from above inside a normal if(){} php condition we never get a true because var_dump($text); returns with: string(94) "Publishing". Why is it 94 chars long even showing only 10 chars? And yes i’ve checked that in the source code as well.

    I thought it could be a higher unicode character because it was copied from MS Excel but even with another manually translated value the same problem appears. In German however which is the default language you got both the $test and the get parameter with the right length.

    Does someone experienced similar problems? Do I miss something in the settings or the documentation of TablePress? Could there be a relation to the fact we use German instead of English as default language?

    • This topic was modified 8 months, 2 weeks ago by maschmiede.
Viewing 2 replies - 1 through 2 (of 2 total)
  • Plugin Author Cristian Antohe

    (@sareiodata)

    Hi,

    That’s weird, not sure why you get 94 chars for a 10 char string. As you mentioned, it could be an encoding issue.

    That being said, you don’t want to check a $_GET parameter against something that can be modified like a gettext. Instead, check against a known string, like “published” that’s hardcoded in the source code and then attribute the $test = _(“Publishing”, “domain”) variable.

    Thread Starter maschmiede

    (@maschmiede)

    We found the problem. It doesn’t happen if you do the __() for example inside your function.php or in the root php file of a plugin. But as soon as you go inside a shortcode or another “ob” function environment you get silent ascii characters like:

    !trpst#trp-gettext data-trpgettextoriginal=2022#!trpen#Publishing#!trpst#/trp-gettext#!trpen

    In order to fix this we now use the offered trp_translate() instead but for that you need an extra private page where you list all your values. With that you can normally translate your words from your root language into any other language with TranslatePress as known.

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘Default translate function failing with TranslatePress’ is closed to new replies.