…it can have only one page (one tab) and several sections and different options.
Basically the option’s value will be an array:
array (
'one_theme_text_field_0' => 'Some apples are red.',
'one_theme_text_field_u' => '',
'one_theme_text_field_t' => 'This is a read-only but selectable field',
'one_theme_checkbox_field_1' => '1',
'one_theme_checkbox_field_1m' =>
array (
0 => '1',
1 => '1',
2 => '1',
),
'one_theme_select_clientnum' => 9223372036854775807,
'one_theme_select_pwd' => '55545z%!Z 4;5 zpoiz',
'one_theme_select_field_3' => '-- Please select --',
'one_theme_textarea_field_4' => '',
)
Sorry! The most important:
I’d like the user to input translations on the theme options page, not in strings translation.
I am thinking about one option per language.
For example: option names are theme_option1_en_US and theme_option1_jp_JP etc.
function current_language() {
if ( function_exists( 'pll_current_language' ) ) {
$current_language = pll_current_language( 'locale' );
if ( false === $current_language ) {
$current_language = pll_default_language( 'locale' );
}
} else {
$current_language = get_locale();
}
return $current_language;
}
Your advise is welcome.
Plugin Author
Chouby
(@chouby)
Hi Viktor,
You can dissociate the UI an the storage.
If your theme if for public release, I would recommend that you keep strings translations in PLL_MO objects. That would make 3rd party compatibility easier (I am thinking for example to translations services such as Lingotek). And this does not prevent you to build your own interface to translate your options.
Otherwise, one option per language is indeed possible.
Thank you.
My problem is these are dynamic options, not hard-coded strings.
So if you strings-translate them and the original string changes, you would have to retranslate it to every language.
I use option names like OPTION-NAME + current_language()
It is one class only, and is ultra minimalist
https://github.com/szepeviktor/wordpress-plugin-construction/tree/master/theme-options-page/includes
If your theme if for public release
Actually this is an options page maker for themes.
Plugin Author
Chouby
(@chouby)
I see that you marked the topic as resolved but will give information fro other users anyway.
PLL_MO introduces 2 methods to read / write the translations from / to the db.
See https://github.com/polylang/polylang/blob/master/include/mo.php
Other methods are inherited from the WordPress MO class. I use make_entry(), add_entry() to add a translation to a MO object, and translate() to get a translation given the source string. See https://github.com/polylang/polylang/blob/master/settings/table-string.php
If you don’t use the pll_register_string(), the strings won’t appear in the strings translations, but the options will still be stored in the MO object.
pll__() is still the best way to get the translation on frontend. I associate it to the ‘option_xyz’ filter.
See https://github.com/polylang/polylang/blob/2fa777aacedea04c882c58f0d09994c4096e0ce4/frontend/frontend-filters.php#L44-L46
Thank you!
I’d like to repeat that my project is a Theme Options Page maker.
So all data may change any time.
It is not the fixed hard-coded string -> translated string relation.
Let’s say there are few inputs. Currently these are stored in an option as an associative/hierarchical array.
So you’re saying that I should store every individual field in a PLL_MO object?
ps. These fields can be select-s or checkboxes which are not strings but could be different in different languages.
Plugin Author
Chouby
(@chouby)
Yes. Here is some code to start.
To save on admin:
$option = update_option( 'my_option', $value );
foreach ( pll_get_languages_list( array( 'fields' => '' ) ) as $language ) {
$mo = new PLL_MO();
$mo->import_from_db( $language );
$mo->add_entry( $mo->make_entry( $value, $translated_values[ $lang->slug ] ) );
$mo->export_to_db( $language );
}
To read on admin to populate your form:
foreach ( pll_get_languages_list( array( 'fields' => '' ) ) as $language ) {
$mo = new PLL_MO();
$mo->import_from_db( $language );
$option = get_option( 'my_option' );
$translated_values[ $lang->slug ] = $mo->translate( $option );
}
On frontend:
add_filter( 'option_my_option', 'pll__' );
Thank you for your help.
I think there’s a confusion. These values from the “theme’s Option Page” are not translation of something.
/**
*Build a Translation_Entry from original string and translation strings,
*/
function &make_entry($original, $translation)
Think of it like a field called: Label of call to action button = “Buy now” in English
= “Acheter maintenant” in French, but there is no original value which could be the base of the translation, it is a free input field.
Or am I misunderstanding something?
Plugin Author
Chouby
(@chouby)
Your theme has to be compatible with both monolingual and multilingual websites. For monolingual websites, you will store your option in ‘my_option’. Don’t change that. This option should become the original string in the entry. You may probably use the string in the default language. This one is stored in your option. The other in PLL_MO objects.
Thank you.
If the original value (the base of translation) changes, should we re-translate to all languages?
How could I handle ‘my_option’ as it is a big associative (hierarchical) array?
Plugin Author
Chouby
(@chouby)
Yes, the translation is attached to the original value, not the option name. But I guess that it is possible to code something to work around that (you know both the old and new value before updating in DB).
I see no problem for arrays. You just have to register each array item and to translate each of them too.
add_filter( 'option_my_option', function( $options) {
foreach ( $options as $key => $option ) {
$options[ $key ] = pll__( $option );
}
return $options;
} );
I use a recursive approach here for wpml-config.xml
Thank you very much.
I think the translation will be done in Strings Translation.
