Greetings! I’ve been trying to turn “Libratus” theme into multilingual one.
Following instructions provided here (http://www.zenphoto.org/news/translating-tutorial#theme-translations), I created libratus.po (and .mo) files in the
..themes\libratus\locale\ru_RU\LC_MESSAGES folder. Using Poedit I discovered and translated strings. But even with libratus.mo compiled switching languages (frontend and backend) seems to have no effect.Tried with dynamic-locale plugin and without it. With multilingual option enabled/disable end even with English lang turned off. The core translations are working fine and changes I make to zp-core\locale\ru_RU\LC_MESSAGES\zenphoto.po file do take effect.
Maybe there is no automatic handling of theme language files and the only may is to merge it into zenphoto.po? Or am I missing something? The theme modified by me is avalible on github (https://github.com/PaulBuhtab/libratus/tree/master/libratus/locale/ru_RU).

The problem is that Libratus is simply not setup for theme based translation. http://www.zenphoto.org/news/translating-tutorial#plugin-and-themetranslations
Without those the separate theme translation is just not used.

So do I have to replace every instance of "gettext("some text");" with "gettext_th("some text","");" to have a mulilingual theme with a separate translation file? And ngettext with ngettext_th, right? Will try.

Alternatively, I could include those string into main zenphoto.po file. But it will mix everything up.

Yes, correct.

It worked. Thanks!

The theme I'm trying to improve uses single quotes (') to enclose textstring and module names (i.e.gettext('some text'); OR include('inc-footer.php');).
And tutorial here instructs to use double quotes
(i.e. gettext_th("some text","");)
Seems to work boyh ways but, which way is better. Or it doesn't matter in this case. Single quotes mean no parsing at all, maybe they are preferable?

For gettext it should not matter if single or double quotes. Gettext text is not parsed like an echo "something $s" where $s would be replaced. On gettext the full text is replaced by the text in the translation file. Variables only work if you use sprintf() or printf() additionally to replace placeholders. Examples here http://www.zenphoto.org/news/translating-tutorial#how-doeszenphotos-translation-work

Except here you are right that single quotes are preferable generally.

The translation worked fine for single language localized site. But a problem is that I can’t switch back to English if I try to implement a multilingual site (with a language switch). zp-core strings are translated as they should when I switch site language from the front end, but the theme strings remain translated regardless of user selected language, default site language, HTTP_Accept_Language option. My code is updated on github (see first post for link). The translation itself isn’t completed, yet.

Works for me generally besides that not all strings are gettexted apparently. Also there is a typo on album.php line 114 (gettext_) .

But please try the support build as there was just an issue discovered with the language selector that broke the English flag.

After switching language options back and forth everthing works fine. But it seems "gettext" and "gettext_th" may not behave synchronous in come cases. Maybe some combination of hosting setting is the cause.
Worked with en_US as defaul lang and http_accept=false.
Thanks for encouraging answer.

Do you have an example? Are really all theme strings covered in the theme translation file?

Here is an example (an empty one): http://2fd6db98ea.url-de-test.ws/

I missed "ngetexted" strings, because was not sure of "ngetext_th" syntax and even existence. Don't guarantee but suppose that all instances of "getext" replaced.
The .po project is 83% comleted and what is left belongs to admin pages.

When able I'll update github repository. And I'm almost ready to submit core translation for Russian lang for v 1.4.9.
Also I'm going to find a way of supporting translation with poedit given than gettext_th is used instead of gettext (think it should be simple).

As far as I can see on that site all is properly translated and is kept that way when I switch between English and Russian.

Syntax of ngettext() is explained here:
http://www.zenphoto.org/news/translating-tutorial#how-doeszenphotos-translation-work
It's the same for the theme/plugin based one, except the suffixes _pl/_th.

Setting up Poedit is quite easy, you just have to add the gettext_th/gettext_pl calls to the catalog settings under additionall keywords (not sure how it is named right now as my Poedit is in German). You cannot disable the normal gettext calls, only add additional ones if I understand right.

A Russian core translation will be very welcome. If you submit set the internal version to the next version (so in this case 1.4.10).

Glad that proper functioning is confirmed so far. Tested it different browsers - seems OK.
The source repository is updated, but I don’t generate a pull request because not sure. Maybe both “gettext” and “gettext_th” versions should exist separately. Anyway, the translation itself (.po, .mo) is almost valid now.
As for other points, info is quite timesaving. Now don’t have to guess, search.

[quote]Maybe both “gettext” and “gettext_th” versions should exist separately.
[/quote]
Not sure what you mean by that exactly. The core translation of course should not cover _pl/_th calls from a third party theme or plugin. Only official themes and plugins are and should be covered by a core translation.

I wanted to say that generally there are two ways of localizing site running zenphoto. The first and the default way is translating zp_core, with the third party theme path included into zenphoto.po project.
The plus managing all string in one place.
The disadvantage is that the admin will have to maintain modified project (quite extensive) with each zenphoto version upgrade.
The other way is to modify the theme so that it’s translation can be maintained separately through ”_th” functions and “themename.po” file.
The plus is that core upgrades come easy.
The disadvantage is that theme version upgrade becomes a bit complicated (if the author holds to using “gettext”).

The second way seems more preferable for me, but others may have their own reasons.

Ok, actually the second way is the preferred way for every third party plugin or theme and it is that way noted on our translation tutorial. Third party string should not be in a core translation.