[Chiuso] Translate dynamic string from a php variable

dovrei aver attivato solo i plugin strettamente necessari. Il problema derivava dalla mancanza di alcuni file in uno dei due plugin per cui ho aperto questo ticket. Li ho riapplodati e ora sembra funzionare.

Per visionare il problema di mancata traduzione è sufficiente andare nel backend di un prodotto variabile e aprire una variazione e li si può vedere come la stringa "Noita Price" non venga inserita nelle stringhe da tradurre.

Ho scritta dinamica perchè quella stringa da tradurre è stata creata da me con il plugin User Role Price. In pratica questo tool ti fa creare un ulteriore campo prezzo per i prodotti associato ad un ruolo. Quello che ho cercato di fare, anche con i tuoi consigli, è di tradurre l'etichetta di questo campo, etichetta che è stata scritta da me in sede di creazione del campo.

L'etichetta viene salvata nella variabile $name
<p class="form-row <?php echo $class; ?>">
<label><?php echo esc_html(stripslashes($name)) . ' (' . get_woocommerce_currency_symbol() . ')'; ?> " href="#"> [?]</label>
<input type="text" size="5" name="<?php echo $field_name; ?>" value="<?php echo esc_attr( $_field_price ); ?>" class="wc_input_price" placeholder="<?php echo esc_html(stripslashes($name)); ?>" <?php echo $read_only; ?> />
</p>

Per impostare questo campo occorre andare nel backend in Woocommerce -> User Role Price -> tab Prices

Non so se ho capito bene. Quando parli di "contenuto" ti riferisci al valore che viene inserito nel del custom field (ovvero il prezzo) oppure all'etichetta/nome del custom field? quello che a me serve tradurre è il nome del custom field/etichetta e non capisco perché non venga considerato nelle traduzioni come avviene per la scritta "Prezzi delle variazioni custom". Il prezzo sarà lo stesso in tutte le lingue poi.

Con "campo è bloccato" cosa intendi?

Puoi togliere il tema è metterne un altro senza problemi ed anche tutti gli altri plugin ma l'importante è non togliere Woocommerce User Role Pricing, WooCommerce Wholesale Ordering e ovviamente woocommerce.

L'etichetta Noita Price da tradurre verrà visualizzata solo nel backand, nel frontend non verrà mai visualizzata perché viene usato solo il valore inserito ovvero il prezzo che è sempre lo stesso.

Per vederla basta andare nella pagina di modifica di un prodotto del backend.

Il plugin doppio Kootj puoi tralasciarlo dato che non influisce su quel campo dato che non usa quell'etichetta ma solo il suo valore nel frontend.

In sostanza la stringa da tradurre è "Noita Price" quella che vedi nel backend del prodotto e non il valore che verrà inserito.

Una volta che viene creato un prezzo customizzato mediante il plugin User Role Price questo campo verrà visualizzato nel backend in tutti i punti in cui compare il campo prezzo regolare quindi per tutti i tipi di prodotto definiti in woocommerce.

la riga di codice da cui deriva la visualizzazione dell'etichetta nel frontend è questa "echo esc_html(stripslashes($name))" che da quanto ho capito presenta esc_html che non va bene ma anche provando altro resta sempre non presente nelle stringhe da tradurre mentre funziona correttamente la riga di codice poco sopra "_e('Custom Variation Prices:', 'woocom-urp');" quella che visualizza correttamente il testo in grassetto "Prezzi delle variazioni custom"

Contatto l'autore è sento che dice, ma potresti spiegarmi meglio quanto scrivi " se le stringhe dei campi personalizzati sono localizzati per default in qualche modo?"

Mi ha risposto molto velocemente:

"I’m heading out the door, but I need to load up a current version of WPML to do some testing with their newer version to see if anything has changed. I’ll do that later today.

However, any custom text that you create by filling out a form field on the admin side is translated differently than the other text strings that you translate with __(xxxx, domain) or any of the _e variants.

It’s possible I missed that one, so I will need to double check. But, I know that I did register the admin created text strings with WPML, so they should show up somewhere in the WPML interface to be translated. I can’t remember right now if WPML translates those automatically as they are retrieved from the options table, or if I needed to run each one through a function when retrieving the value.

The problem with this particular plugin is that many of those admin fields are not pre-defined, they are dynamically created as you create new custom prices. So, it’s impossible to define them ahead of time for WPML to translate. But, I’m pretty sure I did figure out a way to do it. So, either I missed that one, or WPML changed something, or you possibly weren’t looking in the right section to find that string to translate.

I will take a look later today."

ecco la risposta "OK, so taking a closer look at what you posted, and then finding that function in my code to confirm, that field label you are talking about ONLY shows on the admin side. It is never used on the public side. Also, since you are creating the custom price fields and giving them a unique name that you can use to identify them, you can make that unique name in any language that you want. There is no need to translate those fields, since the public will never see those names. Also, as mentioned, these fields do NOT have a pre-defined name… they don’t exist until you create them, so I can’t know the option/field name ahead of time to set it up for translation. Just give it the name exactly as you want your admin users to see, so they can identify which price it is, and don’t worry about that. No need for translation."

A questo punto credo che l'unico modo è andare a modificare il valore dell'etichetta direttamente nel database.