Plugin Author
Chouby
(@chouby)
Hi!
Do you mean they are missing on admin side? Normally Polylang should skip only empty options.
Hi, thank for replying! Well, yes. There is approx. 20 “admin-texts” items in XML, but in Polylang admin / String translation tab are listed only some of them – those with any string value. Those with only numerical value are missing.
I am referring to this tutorial for WPML – http://themes.quitenicestuff.com/docs/sohohotelwp/translate-plugin-booking-other.html … I hoped it will be possible with Polylang too.
Plugin Author
Chouby
(@chouby)
I successfully translated numeric values. The only case which does not work is when the value is 0.
Well, I mean those numerical “strings” are not displayed on that tab. So I can’t even to try to translate them.
XML content: http://imgur.com/OswWzzZ
String translation tab: http://imgur.com/RaW74GV
There should be seven another strings between fax_number and currency_unit.
I searched Polylang source codes and found for example register_string_recursive() (wpml-compat.php).
protected function register_string_recursive($context, $strings, $options) {
foreach ($options as $name => $value) {
if (isset($strings[$name])) {
if (is_string($value) && $strings[$name] == 1) // !!! -----> is_string($value) ... and $value is number/ID ...
pll_register_string($name, $value, $context);
elseif (is_array($value) && is_array($strings[$name]))
$this->register_string_recursive($context, $strings[$name], $value);
}
}
}
Those is_string() conditions creates this problem I suppose.
Plugin Author
Chouby
(@chouby)
You may be right. Maybe I could not reproduce because in the plugin I used for tests, numeric inputs are kept as strings. Did you make the test if removing the is_string() condition solves your problem?
Yes, removing is_string() from this conditions did the job – those strings appeared on String translation tab. But there are probably some front-end issues, because even when it was correctly translated in WP admin, nothing changed on front-end … and I gave up searching 🙁
Plugin Author
Chouby
(@chouby)
The same in translate_strings_recursive() maybe?
Yes, it works, but … I don’t want to hardcode those changes to your plugin and disable its later updates 🙁 Have those is_string() checks any special meaning? Will it “break” when removed?
But there is another issue – the other plugin loads settings on ‘init’ action, and this code
$this->settings = get_option( 'quitenicebooking' );
echo "Step 1: " . $this->settings['step_1_page_id'];
… echoes “Step 1: 5” … but translated value is 213. But this is echoed on the top of the page, before any HTML … plugin has one widget, it is placed in sidebar, and it loads plugins settings again, via $quitenicebooking_settings = get_option('quitenicebooking'); … and now the 5 value is correctly translated to 213!
I checked that wpml-compat.php translate_strings() function is called even before the first settings load, but returns untranslated values. So I think that when booking plugins loads, Polylang functions works (after is_string() removal), but the setting translation is not available at the moment. But it is available later when the page renders (booking widget loading same settings).
Do you have any idea what can be wrong now?
Plugin Author
Chouby
(@chouby)
1. I will replace the test
if (is_string($value) && $strings[$name] == 1)
by
if ((is_numeric($value) || is_string($value)) && $strings[$name] == 1)
to definitely allow translating numeric values.
2. The option is loaded to soon when setting the language from content. Try setting the language from the directory name.
1. Yay! Thank you 🙂
2. Yes! It’s my default choice everytime (language by directory), and I know I was setting it this time too. But now I see the “language by content” is set. Setting language from directory (and those changes in source code) solved my issue.
Can I ask when the change in source code will by public?
Plugin Author
Chouby
(@chouby)
Upgrade solved everything! Thank you very much! 🙂
