leods92

Good news!!!
I’ve finally found what was the problem and I have fixed my problem.

Chouby, thank you so much for your persistent assistance.

When one adds a language via PLL the plugin generates the proper dictionary files in the /wp-content/languages directory. However, those dictionaries remain untouched forever.
In my opinion, when PLL is updated the plugin should regenerate those dictionaries.
Anyway, what I did was to install a new WP instance with PLL. Then, I added the languages I wanted and copied the new generated /languages/*.mo files to the other WP installation I have.

I created different databases, activated and deactivated plugins, changed themes, etc, until I finally got to the above mentioned solution.

I’m not exactly sure why this happened as the dictionary files were already in the /languages/ directory. Maybe their contents were the same of their English counterparts (so the months were being displayed in English) or maybe they were just outdated and didn’t contain months translations; I really don’t know.

Hope this helps somebody else.

Thanks again, Chouby! I hope you continue to develop PLL as greatly as you have been doing so far.

Good point!
No they’re not.

I tried those hooks but it didn’t work.
Even running the default twenty-twelve theme I cannot get the months translated.

Damn! I have no idea how to fix this.
And it’s pretty annoying considering the entire website is translated but those tini-tiny months.

Thanks for helping for this long anyway. ??

I’m calling it in a function from the functions.php theme file.
The function is inside a ‘theme_setup’ hook.
I haven’t added the language code to all URLs, they’re being set according to the content and user preferences (cookie, Accept-Languages HTTP header).

How can I make sure that ‘wp’ hook is called before calling get_the_date()?
That’s probably a newbie answer and I will search about it afterwards but if you feel like sharing it… ??

Chouby, thanks for your kind support.

I was using get_the_date() which is supposed to use date_i18n.
Anyway, I tried the date_i18n() but the months are still shown in English.

Could you tell me exactly which function are you using?
Also, are you testing with Polylang installed and Portuguese being the secondary language?

Thanks again, man!
I really appreciate your help.

I haven’t explored WP source code that deeply to be completely sure but I don’t think this is that trivial. As PHP generates the month names, with proper time/date functions, translated month names are not in dictionary file. Well, at least that was what I have concluded so far.

The translated language I’m having problem with is Brazilian Portuguese.

Anyway, have you found a multi-lang blog which has its months translated?

The thing is even if I run a polylang-less setup I still don’t get the months translated. Have you ever seen a set up using polylang where months are being translated? I’d like to see it in action and maybe contact the maintainer of such website/blog.

Thanks again for your kind support!

Yes, it does.
I’m sorry but as I’m in a hurry I didn’t check what were the changes.
Have you just rollback the SQL change?
Anyway, thanks a lot! ??

Exactly!

LINE 1: …l_tm.meta_key = ‘_language’ AND pll_tm.meta_value IN (4) ORD…
^
HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. for query SELECT t.*, tt.* FROM wp_terms AS t INNER JOIN wp_term_taxonomy AS tt ON t.term_id = tt.term_id LEFT JOIN wp_termmeta AS pll_tm ON t.term_id = pll_tm.term_id WHERE tt.taxonomy IN (‘category’) AND tt.count > 0 AND pll_tm.meta_key = ‘_language’ AND pll_tm.meta_value IN (4) ORDER BY t.name ASC made by require(‘wp-blog-header.php’), require_once(‘wp-includes/template-loader.php’), include(‘/themes/yyb/index.php’), get_sidebar, locate_template, load_template, require_once(‘/themes/yyb/sidebar.php’), dynamic_sidebar, call_user_func_array, WP_Widget->display_callback, WP_Widget_Categories->widget, wp_list_categories, get_categories, get_terms

@eineren
That’s how it’s supposed to work.
It shouldn’t redirect to the main language but to the user’s language.
Choosing the language is not up to you, it’s a user’s decision.
Once he/she change to the main language the auto-redirect you redirect to the main language. However, if the user browser or cookie has as the preferred language the second language that will – and should – be the default for that user.

@chouby
I’m referring to the widget on the front-end.
I’m getting some SQL errors in the server log regarding tags, that’s probably connected with the problem I’m having. As I host my blog in Heroku, I have to use PostgreSQL and maybe that’s an incompatibility. Did you change any queries in the last version?

@boompop
I don’t think turning this feature off is useful at all.
I mean, if someone accessed the content in a certain language once, why wouldn’t him/her in the future? Chances are that he or she will stay with the same language. If he/she wants to keep moving between languages, then they’ll have to click a little more; but that kind of people are not the majority.

@chouby
Great job! I’m so glad you fixed it so quickly.
I have a problem though: the tag cloud stopped working for some reason.
Are you aware of that? Thanks!

@chouby
Exactly!
And the problem of not testing the referer is only noticeable when you hide the default language prefix from the URL.

@chouby
I’m not completely sure if this is a new bug but using the lastest stable version of your plugin I have one problem: users are not arriving at the right homepage.
Going through the latest SVN development changes, I noticed you have made some changes related to this but even trying the latest development versions the problem persists.

Just to assure we are on the same page here, I’d like to summarize how this feature should work:
– User accesses homepage without pll cookie (new visitor or visitor who has disabled cookies) -> Polylang gets the preferred language from request HTTP header “Accept-Language”, sets the proper cookie, and if the language is different from the homepage’s, redirects the user.
– User with pll cookie accesses the homepage -> Polylang gets the preferred language from cookies, and if the language is different from the homepage’s, redirects the user.
– User deliberately change the language, by clicking on a link inside the website -> Polylang reassigns the cookie value and DOES NOT redirect the user as he/she really wants to be at a different homepage.

Since the function get_preferred_language() takes care of getting the preferred language from the cookie (if available), the code you’ve just proposed and the one that’s currently being used should not evaluate whether (isset($_COOKIE[‘wordpress_polylang’]) || isset($_COOKIE[PLL_COOKIE]) is true. Doing so, will skip get_preferred_language and if the user tries to access the homepage WITH a cookie different from the homepage language, he/she won’t be redirected and the cookie will be reassigned to the homepage’s language code.

I’m not sure if I was clear; if I wasn’t please let me know so I explain it better.
I’ve removed the unnecessary evaluation from core.php in my blog and the redirections are now working as expected.

Hope yo hear your insights about this issue.

Today I updated the plugin to the real latest version (sorry about that).
When running version 1.0 the problem doesn’t exist.

Thanks for the support anyway!
Have a great weekend.