Viewing 20 posts - 1 through 20 (of 20 total)
  • Author
    Posts
  • #1168274

    Hi,

    I am having massive troubles with not translated items since upgrading WPML 4.2.4.1 to 4.3.5 (4.3.6).
    Some of the woocommerce items and items within the Theme (using ENFOLD child functionality) stopped
    beeing translated, using __() function.

    A ticket at WPML is already open, but they say that ENFOLD might not be using some new functionality
    of WPML, causing this problems.

    Maybe you can look also into this ticket:
    https://wpml.org/forums/topic/__-function-in-own-widget-does-not-return-translated-string/page/2/

    Do you have some other issues, which might be related to this symptoms?

    Thank you in advance,
    Best Regards,
    Michael

    #1169085

    Hey zwachm,
    Sorry for the late reply, I have reviewed your post at WPML and see they have ran a compatibility test in their sandbox and was not able to reproduce your error, they have also asked for you to post what changes in the settings you have made so they can continue testing. Perhaps you didn’t see this request so I’m just trying to point this out so they can continue with the test.

    Best regards,
    Mike

    #1170311

    Hi Mike,

    great, that the forum is open again!
    Thank you for taking a look. As you also can see, I do not know what WPML support means with the “special settings”.

    That’s why I have also contacted you, since they mentioned some new functionality by the last WPML update.

    Would it help, if you can take a look at my test-site?

    Best Regards,
    Michael

    #1170336

    Hi,

    the best example is the product page:
    https://www.bundesfeuerwehrverband.at/produkt/grisu-der-drache/
    where you can see “FROM” in front of the price. It should be “AB” in German.

    I have alos tried to deactivate the ENFOLD-Child Theme without success.

    Regards,
    Michael

    #1170367

    Hi,
    On this post It looks like the WPML team got this error on their page:

    This element was disabled in your theme settings. You can activate it here: Performance Settings

    To correct they need to go to Enfold Theme Options > Performance > Disabling of template builder elements and choose “always load all elements”
    2020-01-04-145843
    I hope that helps them to recreate your issue to solve, I’m not a WPML expert. Is the “From” the only word not translating?
    2020-01-04-150526
    I may be able to fix that with a script, or I can ask for help from someone on our team with more WPML experience.

    Best regards,
    Mike

    #1170430

    Hi Mike,

    on my test-site and my productive site this ENFOLD performance-setting is set to
    “always load all elements”.

    For your information:
    there are all around several items, which are not translated any more:
    Woocommerce-Mails (partly translation is missint: e.g. Phone is not translated)
    – the “FROM” as mentioned before for multiple prices
    – some Strings within my plugin, called by function __()
    for example: __(‘Check your cart, add some products or change amount’,’obfv’)
    although translated in WPML string translatioin within the text domain “obfv”

    It started all with WPML Upgrade from WPML Multilingual CMS 4.2.4.1 to 4.3.5

    It would be realy helpful if some of your WPML guys could take a look into it, since WPML has not found anything yet.
    I would be able to give them a login (WP and maybe ssh) login to my test-site…!

    Thank you in advance!
    Best Regards,
    Michael

    #1170450

    Hi,
    Thank you for the feedback, Please include an admin login in the Private Content area and I will ask the team for someone with more WPML experience to take a look.
    I assume it may help to also include the url of the strings that are not translating so they can check and test quickly, such as your example above, is it in the shopping cart or on the check out page?
    Thank you for your patience.

    Best regards,
    Mike

    #1170480

    Attached, please find login data!

    Thank you!

    #1170614

    Hi,

    Thank you for the info.

    The MZ OBFV plugin for Woocommerce alters the default price markup, but it doesn’t contain any translation for the string. You’ll find the modification in the plugins/mz-obfv-framework/inc/mz-obfv-woocommerce.php file inside the mz_obfv_woocommerce_variable_price_format function around line 1947.

       //https://iconicwp.com/blog/change-price-range-variable-products-woocommerce/
    $prefix = sprintf('%s ', __('From', 'obfv'));
    

    You may need to add your own translations or ask the the plugin author for additional info.

    Best regards,
    Ismael

    #1170669

    Hi Ismael,

    thank you for looking so deep into my plugins!

    The function in the mz-obfv-framework plugin uses the function
    __(‘From’, ‘obfv’)
    to translate “From” within textdomain “obfv”. Exactly this text
    is, according to WPML String Translation, translated to Ab in languate
    German (Deutsch). So it seems ok to me and the string should be translated.

    So I assume, that exactly this it the issue, that in my case the function
    __() does not translate strings in some special cases!

    Do you have an idea why?

    One thing I can see is, that in my environment the product URL is typed with /product/ (in English).
    (might be /produkt/ in German).
    Is this maybe the minning link, that __() assumes, that this product is browsed in English??
    https://obfv.log2track.com/product/grisu-der-drache/

    Thank you for your time,
    Best Regards,
    Michael

    #1170892

    Hi,

    Thank you for the update.

    It seems to be an issue with the sprintf function as described in the following thread.

    // https://wordpress.stackexchange.com/questions/240596/with-sprintf-returns-untranslated-string

    The sprintf function should go inside the translate function, not the other way around.

    $prefix = __( sprintf( '%s ', 'From' ), 'obfv' );
    

    Best regards,
    Ismael

    #1170948

    Hi Ismael,

    thank you for pointing out that. But in my case it is not caused by this.
    I have changed the code to

    //   $prefix = sprintf('%s ', __('From', 'obfv'));
    $prefix = __('From', 'obfv');
    

    without having any change of the wrong behaviour.

    Regards,
    Michael

    #1171216

    Hi,

    Have you tried with the plugin developer? What they have said?

    Best regards,
    Basilis

    #1171276

    Hi,
    the plugin developer – it’s me!
    The code simply does not return the valid translation.

    Best Regards,
    Michael

    #1171683

    Hi,

    Thank you for the clarification.

    Are you sure that this is the only filter that manipulates the price markup? You might have missed other functions or filters in your plugin.

    We are not really sure if this is going to help, but it’s worth a try. Try to replace line 1961..

    sprintf('%s%s', $prefix, $price);
    

    .. with:

    
      __('From', 'obfv') . ' ' . $price;
    

    You should be able to delete the $prefix variable in the top line. Let’s see if removing the sprintf function will help.

    Best regards,
    Ismael

    #1171701

    Hi Ismael,

    I think you are on the wrong track.

    Even if I change the code in there to:

    
    return __('From', 'obfv');
    

    the english “From” is shown.
    So the __() function, in my opinion, thinks that the English translation is *needed*… at least in this part of code.

    Regards,
    Michael

    #1171745

    Hi,

    I want to give you the same information I found about the issue, as I have provided to wpml support guys:

    I have debugged the file wp-includes/l10n.php
    and found, that if I set
    $locale fixe to “de_DE” within function get_locale() with the following code, the string is translated successfully.

    
    function get_locale() {
            global $locale, $wp_local_package;
    return 'de_DE';
    

    So it seems, that some circumstance causes in my opinion a changed locale language within the site…

    Maybe this helps.

    Best Regards,
    Michael

    #1172626

    Hi,

    Thank you for the info.

    Are you saying that it’s not returning the proper locale? Maybe the following filter will help to ensure that the appropriate locale is returned based on the value of the ICL_LANGUAGE_CODE.

    // https://developer.wordpress.org/reference/hooks/locale/
    // https://wpml.org/documentation/support/wpml-coding-api/#language-constants

    Best regards,
    Ismael

    #1176001

    Hi,

    for your information: the topic was now solved by WPML support.

    Within WPML the default languate, named de_DE was temporary renamed to e.g. de_DE+ and afterwards named de_DE again.
    This forced some internal WPML initialization and some .po file re-generation and stuff.

    This solved the issue.

    Regards,
    Michael

    #1176006

    Hi,
    Glad to hear this is solved and thanks for sharing the solution with us. Perhaps this information will help other WPML users.
    We will close this now. Thank you for using Enfold.

    For your information, you can take a look at Enfold documentation here
    For any other questions or issues, feel free to start new threads in the Enfold forum and we will gladly try to help you :)

    Best regards,
    Mike

Viewing 20 posts - 1 through 20 (of 20 total)
  • The topic ‘Enfold and WPML Language mix since WPML 4.3.5’ is closed to new replies.