Language tags crash

Hi @kitelab

Is it some kind of plugin that does this language tagging? It’s not a native WordPress feature so I need more information to replicate this.

It’s qtranslate-x and it works throughout (without doubling pages or products), fast and reliable.

Even when using bilingual product variation descriptions (in apf fields without any language tags), apf stops the page just before the apf text field.

The fields are not translatable. Like echo __( .... )

In addition, we have “WooCommerce & qTranslate-X” and “qTranslate slug” installed. There’s a new fork called qtranslate-XT.

Hi @kitelab

TL;DR:
The premium version of our plugin works with WPML & Polylang, where you can set an extra condition to only show field groups per language (see screenshot here). This way, you can simply duplicate your field groups and translate them right within the plugin.

More info:
I had a look and the problem seems to be with qTranslate-X (and qTranslate-XT has the same problem) where they crash if you don’t use __() when using their shortcode [:en].

A solution is to not use [:en] and translate the options in another way. I understand the plugin offers an easy way of doing things for you, but it’s not really a WordPress standard so I can imagine not many plugins support this syntax.

Furthermore, the plugin hasn’t been updated in 3.5 years and according to the comments, many people are having issues. I would strongly suggest you look at changing to an updated language plugin. I understand qTranslate-X has some features you like, but if it’s unmaintained, it’s only going to give you (security) problems down the road. Your site should use up-to-date plugins so it benefits from speed and is more secured against hackers :-).

Hi Maarten, every Plugin we have installed, uses the textdomain syntax __(…), it’s WordPress standard. Not just nice to have, but best practice or even mandatory.
Just some samples, but each and every string is like this, that’s why woocommerce and any other good plugin are completely translatable:

__( 'Remove this item', 'woocommerce' )
or this
<?php _e( 'Calculate shipping', 'woocommerce' ); ?>

I’m just a user and have no idea about coding, but yes, there are some plugins that do not support translation. But the custom fields plugin we are using currently does translate.

Best … Thomas

I know that using __() and _e() is WordPress standard. We use them too where necessary. But what I meant to say was that plugin settings are usually translated in another way, and not a shortcode like [:en].

Which plugin are you currently using for custom fields?

Hi Maarten, of course you know. Settings etc. by po mo via Poedit, admin content such as a label of a custom product field by qtranslate in the wp admin area with the mentioned language syntax.

We have some experience with the following plugins, besides a couple of others:

• WooCommerce Extra Product Options by themecomplete (code canyon): Currencies ok. Languages ok. Huge, still not slow on frontend. A few years ago, we used to organize ANY option, variation etc. with this one, globally and for individual special products. Overkill for us, since the generic woocommerce variations are the reliable product options (multi-currency, multi-language).
• That’s why we currently have installed “Woocommerce Custom Fields For Variation”, because with this one we can rely on the multicurrency price calculations of the generic wc variations. Using it for personalized texts just on a couple of products. It wouldn’t be practical for more. And we removed some “total price php and js” lines due to wrong multicurrency calculations, even when the option price is set to zero.

You see why we are looking for a practical solution, or hoping?

Have a nice evening … Thomas

p.s. I like the lean, clean and fast character of qtranslate. It’s a clever solution.