untanyz

sorry wrong plugin support page

Why not? As far as I tested it worked fine.
Without this in profile page “Log In” and “Log Out” string don’t get translated.
What would be proper fix? As far as I understand those string are fetched from database, and later passed through “tml_title” filter with only translates “Active” string, maybe include other page translations there too?
Though I do not understand purpose of these mechanics.

I see, well it would be nice if the dates could be entered manually, but still best calendar plugin I have seen!

I use Firefox 22.0 and Chromium 28.0.1500.52. But you’re right I was logged in and it was admin bar fault.

Thanks, I know it’s never a good idea to change core, but in my case I need scroll bar to always be there. Thanks for the Help!

I see, ok, well then I look forward for the new update.

By the way there is little bug in gg-ajax.php line 52
__(‘to’, ‘even_geek’), the “t” is missing from ‘even_geek’ -> ‘event_geek’

OK, after some testing I see that the problem is with the language code, links from Calender widget are linking to events page with the /lang/ prefix, it shows as 404 error.
https://site-domain/en/events/2013-06-03/ – 404,
https://site-domain/events/2013-06-03/ – everything is fine.

Is it Polylang or Events Manager bug?

I have done as you told, and found out that the problem was caused by
WP Events Calendar plugin which is no longer supported, I guess it’s time to search for an alternative.
Anyways thanks for clearing things up!

I’m sorry the problem doesn’t affect only 404 page.
Here’s how it is – I use 2 languages for my page
English and Lithuanian, I need admin page to be in my language(Lithuanian), I set
define('WPLANG', 'lt_LT');
so far so good, but I need my archive, 404, and some others pages to be in 2 languages:
domain/en/non-existing-page – should generate 404 page in English,
domain/lt/non-existing-page – should generate 404 page in Lithuanian.
wp_title() function generates _e(‘Page not found’); and thus it’s translated in account of define('WPLANG', 'lt_LT');, it ignores /en/,/lt/ language codes and translates string according to defined language. And it happens anywhere a string is translated without theme text-domain. I can work around this problem, by adding needed strings to themes localization, and then translating string using themes text domain, e.g. _e('Page not found', 'theme-text-domain');

So in short
_e('Page not found', 'theme-text-domain'); will translate string depending from language code /en/,/lt/
_e(‘Page not found’); will translate string depending from defined language define('WPLANG', 'lang_LANG');

Now the question is, if it’s really a bug, or it is just the way it works?

Any updates on this issue?