• Resolved tdechangy

    (@tdechangy)


    Hi, I encounter an issue similar to this one :
    https://www.ads-software.com/support/topic/error-with-translating-email-subject-header-with-latest-version/

    For an actual example i have one sentence on my invoice sent that’s in the initial language while I triple checked it was well translated. Or is it the oposit where only this one was translated?
    And on a checkout page, five elements were in the opposite language to..

    As you can see, issues seem essentially happen from the checkout stage to any email sendings. For the rest WooCommerce translations were fine.

    He said :

    ” It was due to the fact that the string was being formatted before the translation was retrieved so no translation was found.”

    But I don’t know how to solve this, hoping that it’s the solution. Can you give a path to follow here please ?

    • This topic was modified 6 years ago by tdechangy.
    • This topic was modified 6 years ago by tdechangy.
Viewing 10 replies - 1 through 10 (of 10 total)
  • Hello
    I need more details in order to provide a viable path to follow for resolving this problem.

    Could you provide some screenshots of the string in question and of the code that generates this string?

    In order to be translated properly, a string needs to be wrapped correctly in a gettext call.
    Perhaps our documentation here: https://wpml.org/documentation/support/troubleshooting-string-localization/ might help?

    Thread Starter tdechangy

    (@tdechangy)

    the documentation “Troubleshooting String Localization” shouldn’t probably concern this issue. Or WooCommerce developers are just unable to build their plugin in a good multilingual way.

    A few examples show the thank you page and emails + respective translations for some of the wrong translated elements.

    https://cl.ly/02aa5f046334
    https://cl.ly/02aa5f046334
    https://cl.ly/4926bc9de2ed
    https://cl.ly/d31f0c47df5c
    https://cl.ly/7723170772c4
    https://cl.ly/1229c82d2cdf

    Okay, I see the screenshots and everything looks right and as it should be.

    It is possible perhaps if you remove these strings and try and re-translate them?
    *You might have to re-save the payment method titles.

    If this does not help, then I suggest that you open a new ticket in our forum at wpml.org where we can ask you for access and check the site and try to debug the issue.

    Thread Starter tdechangy

    (@tdechangy)

    Thanks George for your quick support.
    Now after a few new trials it seem that most translations are working back. Maybe it’s a (localhost) DB queries issue that may happen sometimes and solve by its own when relaunching the server..

    At least now I know that I may delete a string to rebuild it.

    – To be sure, what happens when I delete one ? Are there specific setting that should be enabled (except the obvious “enable string translations”)?

    – Concerning this, the “Following string translations” option is not always obvious for me. When should I use it, does it work only for front-end, or does it for admin side too?
    + When enabling this option I gat a message saying that “if the original language of all strings is english” is disabled. Many of my strings are in French as original language. But wether the original lang. is in English or anything else, what does this option mean in the end. This option doesn’t seem to change anything while enabled or disabled.

    When you delete a string – its entry is removed in the icl_strings and icl_string_translations tables. Then if the strings is in a .mo file – after a check for new .mo files/updates of .mo files it is re-added. If the string is displayed somewhere, then it is automatically re-registered (if it does not exist) and the translation is added from .mo file if present. The settings that are good to be enabled are the auto-registering of strings in WPML > String Translation.

    “Following string translations”? Do you mean the options to not load the .mo files in WPML > Theme and plugin localization?
    That option improves performance because by default WordPress loads the .mo files contents and translations and WPML String Translation does the same – so double the load without that option.
    If you check the option that “original language of string is English” this is known to increase the performance, but it is only available if your default language of the site is English – as this saves loading of strings in the memory instead of loading another set of strings for the language and uses the string from the source instead – which is faster than querying the database.
    However, if you have defined strings in French in an example, and you have that option enabled – then the French strings will be considered to be in English.

    I hope I have explained it well and that I have understood your question accurately.
    Please excuse me if it is not so and let me know.

    Thread Starter tdechangy

    (@tdechangy)

    Thanks for this explanation on string recovery. It seem that I had a server issue the led to this but still some string are maybe wrong. I’ll see later If I need to do this deleting & restoring process soon.

    Until there :

    When I talked about “Following string translations” I ment auto-registering of strings in WPML > String Translation (I translated the french version).

    I feel this option quite to identify how it works since it’s invisible an thus work “in the dark”. There is a (yellow) highlighting color set to display strings that were found using the string auto-registering, but I thought that the highlighting would be used to show those strings while browsing on both the front-end & admin sides.

    In that way we could see that the desired strings are already registered or not!
    In the end, showing the highlight in the strings list doesn’t add much value.

    I already talked quickly about it with one of your coworkers in the hope to ease the use of WPML translation for web designers. What I suggested here is one step closer to what I would like to see.

    In fact the “auto-registering” option should allow to translate any string directly from the front-end, needing just to click on it… One online service already does it! And it looks fantastic with a fair amount of time won on this already annoying task.

    Since I disable the .mo files option to win in performance (and I don’t want to learn one more annoying method) I can be afraid that the “auto-registering” doesn’t find the string again since, as I said, everything is working in the dark, and I don’t like that feeling of working as being blind.

    ______

    You said : If you check the option that “original language of string is English” … if you have defined strings in French, and you have that option enabled – then the French strings will be considered to be in English.

    This troubles me a lot. I do have many strings in French and translated to english, still they seemed to be displayed as they had to on the front-end. French version on French site and vise versa.

    Can you explain me in more details what this option does when active, using one or more alternative “first” languages ? I wait for your answer but this option seem more cumbersome than anything.

    The setting for the original language of the strings may not be even active on your site if your site default language is not English.
    There is nothing to be troubled about.
    Even if you activate that setting somehow – the worst thing that could happen is that some strings can appear in English instead of your language of choice and you should be very quick to spot that on your site.
    I think that I explained what that option does in my previous reply – it loads the strings from source instead of the value kept in String Translation.
    There is nothing to be afraid of that option and since your default language is not English – you should not be able to even activate it.

    Thread Starter tdechangy

    (@tdechangy)

    Pretty good, I won’t use the “original language of string is English” feature from now then.

    As I talked about “auto-registering of strings” with its yellow highlight, you didn’t bring more information concerning my suggestions :

    … In fact the “auto-registering” option should allow to translate any string directly from the front-end, needing just to click on it… An online service already does it! And it looks fantastic with a fair amount of time won on this already annoying task.

    I rode that WPML is working on a new interface/feature for after WP 5.0, could id be related to what I suggested here ?

    Best.

    I did not bring more information for your question because this is a forum about WooCommerce Multilingual. For WPML you should ask in the wpml.org forums.

    You are suggesting a very cool feature, but I am not sure how well it could be implemented from a technical standpoint.
    Translating the strings from the front-end is something that is relatively a big project and it should be done (if possible)with a great care in relation to performance and as-is the option for tracking strings itself is a pretty costly performance-wise when enabled. I am not aware for plans on implementing such a feature after WordPress 5.0

    Thread Starter tdechangy

    (@tdechangy)

    Ok, thx.

    I’ll post a ticket on the WPML support forum.

Viewing 10 replies - 1 through 10 (of 10 total)
  • The topic ‘Error with translating Checkout & email sentences’ is closed to new replies.