Plugin Author
Chouby
(@chouby)
Polylang does not modify how the themes/plugins developers should handle their strings. See here or the codex
The goal of the couple of functions pll_register_string
(on backend) / pll__
(on frontend) is to allow for the translation of user defined strings which are generally stored in options, as it is done for the Responsive theme options in the example you cite.
Thread Starter
eknsyr
(@eknsyr)
Hey,
Seems like I didn’t really grasp that concept. Can you explain where I can find these
user defined strings which are generally stored in options
?
Thanks.
Plugin Author
Chouby
(@chouby)
It much depends on the plugin/theme. But for example, since you mentioned the code to adapt the Responsive theme, the options are found in Appearance->theme options->Home page (headline, subheadline, content area…)
pll_register_string
says “I want to translate these strings in the translations list table found in settings->languages->strings translation”
Thread Starter
eknsyr
(@eknsyr)
Hi Chuoby,
Thanks a lot for your time. After looking for a possibility to get that backend options page for my own custom theme, I noticed that implementing such a feature would require me to dig deep into WordPress and I don’t really have the time for that right now. Then I stumbled upon this thread of yours and it is really tempting to just implement those lines of code and make it work.
Now what made me really curious is that this approach is based on using the _e() function. And Polylang offers a similar function, pll_e().
Now why would I even need pll_e() when WordPress itself with its (limited?) i18n capabilities offers me to translate custom strings?! How does it even differ?
Would really appreciate your help
Thanks a lot!
Plugin Author
Chouby
(@chouby)
When you use _e('some_string', 'some_domain')
, WordPress translates the string according to the right language (either defined in the wp-config.php file for a single language installation or defined by Polylang for a multilingual installation). The translation is found by WordPress in a .mo file. WordPress knows where to find this file thanks to load_plugin_texdomain
or load_theme_textdomain
.
When you use pll_e('some_string')
, Polylang does the same but looks for the translation in the database.
The first function uses a static approach. The strings are created in English in the .php file by the theme (or plugin) programmer and translated in the po/mo files by the theme (or plugin) translator.
The second function uses a dynamic approach. The strings and the translations are created by the user and stored in the database.
Thread Starter
eknsyr
(@eknsyr)
Hi again,
Thanks a lot for the explaination! For the static text in my template I don’t really need easily changable translations, so I just used the WordPress functionality with __(), which works great.
Now I have a different question, my client might want every (currently available in english) content entry duplicated for each language. So that when you view the german version of the blog, all entries are shown, no matter if there is already a real translation available or not.
Is this possible dynamically or do I have to manually copy each post?
Plugin Author
Chouby
(@chouby)
If I well understood, this should answer your question.