• Resolved icarleug

    (@icarleug)


    Hello!

    Since you added a regexp check for wpm_translate_string some strings that previously were translated might not longer be translated.
    This may be especially true for those using an editor like UX Builder who likes to encapsulate text blocks with <p>[en:]</p> for example.
    Not sure how common it is for the different builders to insert html code into the strings though.

    Performance-wise the current regexp is the best. Not sure of any performance hit if the regexp would change to remove the ^ in front, though I guess it still would be a lot better than parsing all strings for language data.
    My site is pretty small, so I didn’t get any performance hit though…

    File: /includes/wpm-translation-functions.php
    1023: return preg_match( '#^(<!--:[a-z-]+-->|\[:[a-z-]+\]|\{:[a-z-]+\}).+#ism', $string );
    to
    return preg_match( '#(<!--:[a-z-]+-->|\[:[a-z-]+\]|\{:[a-z-]+\}).+#ism', $string );

    Best Regards,
    Andreas

Viewing 4 replies - 1 through 4 (of 4 total)
  • VaLeXaR

    (@valexar)

    Ok. I will add this in next version.

    Thread Starter icarleug

    (@icarleug)

    Found out that just changing it might not be the best solution after all, if there is an inline html-block somewhere with a language code (like the terms in flatsomes checkout) it will replace the entire page with just that code (so not optimal)…

    Best Regards,
    Andreas

    VaLeXaR

    (@valexar)

    Is it better to leave as is now? Can you make a screen shot of the error?

    Thread Starter icarleug

    (@icarleug)

    It is probably better to leave it to prevent unwanted behaviour.
    Better to fix the page instead.

    Best Regards,
    Andreas

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘String translation issue with 2.0.1’ is closed to new replies.