me again,
A user reported a problem related to the $wp_default_secret_key at pt_BR.php. This person says that when he updates his sites he can’t access the admin panel and get a message: “You do not have sufficient permissions to access this page.”. Deleting this file fixes the problem. What’s wrong here? The variable value in brazilian portuguese is the same in the wp-config.php file. So I guess it shouldn’t be a problem. could somebody help us, please?
-
Cátia Kitahara
Reply
Milan Dinić 1:39 pm on February 11, 2011 Permalink |
Maybe problem is that he has default keys (as in core en_US version, ie. ‘put your unique phrase here’).
Sergey Biryukov 2:06 pm on February 11, 2011 Permalink |
http://core.trac.wordpress.org/ticket/14024
Milan is right about the potential reason, but actually it shouldn’t happen even with the default keys. I guess $wp_default_secret_key should also be translated in wp-includes/default-constants.php.
Zé 2:45 pm on February 11, 2011 Permalink |
That is correct. What we (pt) do is just leave it in English. It’s too easy to forget to translate.
Mattias Tengblad 3:23 pm on February 11, 2011 Permalink |
So what you’re saying is that if we translate $wp_default_secret_key in wp-config-sample.php and setup-config.php we should also translate $wp_default_secret_key in default-constants.php? If so, where is this documented?
Sergey Biryukov 3:54 pm on February 11, 2011 Permalink |
I’ve added a note on Files For Direct Translation.
To be clear, there’s no $wp_default_secret_key in setup-config.php.
When you translate it in default-constants.php, the string in wp-content/languages/<your-locale>.php is actually no longer necessary, however it’s still required to be there in order to build a localized package. So yes, currently it should be translated in all three places (wp-config-sample.php, <your-locale>.php, default-constants.php).
Da^MsT 3:59 pm on February 11, 2011 Permalink
Good to know, should have been pointed out earlier.
Cátia Kitahara 4:17 pm on February 11, 2011 Permalink
Wait, please. Just to clarify things. There are two possible solutions:
1. Don’t translate the variable at wp-config-sample.php and don’t add the locale.php file
2. Translate the variable at wp-config-sample.php and at default-constants.php and add the locale.php?
Both solutions are admissible, is that correct?
Milan Dinić 4:20 pm on February 11, 2011 Permalink
If you don’t translate it in locale.php file and you did translate it before, this could affect existing installations.
Cátia Kitahara 4:24 pm on February 11, 2011 Permalink
so my best approach should be translate the default-constants.php from now on?
Sergey Biryukov 5:54 pm on February 11, 2011 Permalink
Yep, until a proper solution is found. Currently it’s more like a workaround.
Milan Dinić 4:24 pm on February 11, 2011 Permalink
I don’t like this. Instead of reducing direct translation and simplification of that, we are adding more files, and complicate already complicated situation.
This is a clear sign of how i18n is getting in worse and worse position, how it is ignored, how there isn’t care to truly fix existing issues and to make improvements.
Mattias Tengblad 4:34 pm on February 11, 2011 Permalink
+1
“Opened 8 months ago” (ticket mentioned above) kind of tells the story.
tsjogren 11:50 am on February 17, 2011 Permalink
Hi Mattias
This is Torbjörn (Translating BP to Swedish).
I have the same problem reports from swedish users.
1. When does the problem occur? What WP versions?
2. What is the workaround? renaming sv_se.php did help.
3. Is this fixed in future versions (WP 3.1)
Please advice so i can give the users the correct answers.
I did a WP 3.0.1 install, upgraded to 3.0.5 and installed BP with no problems…
Mattias Tengblad 2:26 pm on February 17, 2011 Permalink
1. From 3.0 and up
2. Yup renaming or deleting sv_se.php will work. Tell the users to update their secure keys in wp-config manually.
3. Yes, the workaround mentioned above is already applied in trunk (3.1).