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.

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.

PERFECT! thx ??

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.

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

Well done !

THX.

Niels Lange is the author in fact and he should answer this important topic here. No answer = unsupported plugin.

Sorry for the mistake.

So, what can we expect Niels Lange ?

Well that’s what I thought to do if you didn’t fix it. But it’s quite frustrating to allowing it on the Cart page !

I hope you’ll search for a working solution soon. Maybe declaring JS later or so..

Thanks at least for quick reply.
Oh, and don’t forget to update this topic when resolved so we can remove the particular CSS !

• This reply was modified 6 years ago by tdechangy.

Indeed, same issue here. First good surprise and then so disappointed.
What says the author of the plugin to solve this ? Isn’t it of any importance on the cart page anjanphukan ?

Are you willing to solve this soon ? any delay ?

I truly hope I’ll be able to thank you sincerely for you full job when done, otherwise wrong reviews will start raining I think.

Waiting for your reply ??

Quite similar issue here and it solved the issue. THX

I finally found the right code. It removes the top of checkout.

// REMOVE coupon field on the top of the cart and checkout page ***”’
remove_action( ‘woocommerce_before_checkout_form’, ‘woocommerce_checkout_coupon_form’, 10 );

// ADD Coupon field before payment ****
add_action( ‘woocommerce_review_order_before_payment’ , ‘woocommerce_checkout_coupon_form’ , 10 );

Sadly there seem no “remove” hook for the Cart coupon so I used CSS. If some hook exists, please let me know.
> Same for the message “… click here to enter code”. that’s useless when moved with this code since it’s not active > coupon field is always visible.
>> let me know if there is another way to make it active (without editing theme files).

Hi Luminus, can you forward the full code you used here ? I tried this one without success :

add_action( ‘woocommerce_review_order_before_payment’ , ‘woocommerce_coupons_enabled’ , 10 );

It seem that the coupon hook is not the good one probably.

If you have a remove-action for coupon on cart page it would be fantastic.

I didn’t see such feature but I already switched to another solution.

Hopefully I’ll have some time to try it once more.

Hi, here you can see the result in the Plugin updates section :

View post on imgur.com

You can also see on this screenshot that on the welcome screen, your “Images optimization” promotional box isn’t responsive at all, even on this (+/-)1200px wide screen.

View post on imgur.com

Best.

I also agree that this should be a must-have.

Why put limitations where it seem quite simple to implement?