WordPress Plugin: WP Native Dashboard (en)
| WordPress Version: | WordPress 2.7 or higher |
| PHP Version: | PHP 4.4.2 or higher |
| tested Browser: | IE7 | FireFox 2.0.0.16 | Opera 9.27 | Safari (Windows) 3.1.2 | Google Chrome |
| not supported Browser: | none known yet |

One of my favorites in coding for WordPress is to manage different localizations. I was not convinced by PoEdit, because i have to do translation work outside the running application without a chance to verify the translation immediately. Doing so inside WordPress backend saves a lot of time and also provides the verification i need.
But the next problem raised while i was unable to switch my backend language on demand. I do normally write my posts at 2 languages (german and english) but i had no chance to work at the backend related to the language i’m currently posting with.
I think that most of the blogs where native speaking/writing authors are publishing posts, they would like to defined the prefered backend language too. That’s why i did introduce this plugin.
Capabilities
The main goal of this plugin is the definition of languages that WordPress backend can be used with. This definition can only be managed by administrators, any other user can’t change this settings. The admin can define, which of the 3 possible extensions are enabled for blog members (or which combination out of):
- extend the WordPress logon screen
- extend the backend header with quick switcher
- extend the user profile settings
All of those extension can only be enabled by administrators. All your blog member (including the subscriber) can use the enabled features to choose their prefered language.

What’s about multi-lingual plugins ?
This backend related plugin doesn’t change your blogs behavoir at frontend and also doesn’t collide with any known multi-lingual plugins. It only overstep the WPLANG given blog language and sets it to the users prefered (choosen), if the user works at backend. It’s the same as you would permanently change the wp-config.php definition prior to logon. But the plugin does this without any file modification and more sophisticated.
Where can i get the WordPress language files ?
This plugin has got a build-in download interface from svn.automattic.com to retrieve the existing files that are matching your current version and are provided by polyglot teams. You can check the repository for existing files and afterwards download the required files form your installation. Currently it is necessary to have direct write access to your file system doing so. If this is not possible (and will be detected by the plugin) the download option won’t be shown.

Direct File Write Permissions
Some configurations at your hoster may require that your updates has to be performed by FTP or SSH. This plugin now fully supports this during language file download and erasing language files. It uses the WordPress core functions for filesystem and will prompt you for user credentials if they are really needed (like updates would do).
Internally it works the same way than update of plugins/core would do it, but with a nice dialog showing up therefor. So you can safely use this as you know it.

Actual Download
The new version: wp-native-dashboard-v1.3.0.zip (468 downloads) can be also found at wordpress.org/extend/plugins.






Kornelije Sajler
28.07.2009 | 00:09Hi, first thanks for this great plugin and all rest plugins. I have some problems with this plugin, and problem is when I install your plugin I got an error, in foreach loop of $installed languages inside wp-native-dashboard.php.
So I debug it to find why installed languages aren’t filling $installed array.
In wp_native_dashboard_collect_installed_languages() you are searching for languages in wp-content directory or (WP_CONTENT_DIR.’/languages’) but in my installation of WordPress (2.8.2) languages are stored in wp-includes directory.
I’m very new in WordPress world and don’t know the past of changes, and I really don’t know is there a constant for wp-includes dir like WP_CONTENT_DIR for wp-content dir. And I don’t know why your searching languages in content when they are (for me) in includes folder, but maybe you can tell us
I fix it easily like this changing WP_CONTENT_DIR.’/languages’ to ABSPATH.’wp-includes/languages’, but it is called twice. This is what my function looks at the end, I comment code that didn’t work for me:
I don’t know does anyone have had this problem but this is my fix, and it works fine, hope will help someone. I think to write a blog about it and I hope that’s OK with you, and you probably give us more information about this problem.
Thanks again Heiko for this wonderful plugin!
reply »
codestyling
28.07.2009 | 00:22It seems, that i made this mistake inside. I sould have used the constant therefore like WP_LANG_DIR
This can be found as defintion at wp-setting.php:
I will changed this as soon as possible and also adapt it to FTP capabilities for users unable to write directly to disk. Placing in includes path is an old style behavoir the location has been changed to be wp-content. Reason for that was not to loose language files during an automatic update and also make a backup easier for user (just zip the wp-content path and make a db dump)
reply »
Kornelije Sajler
28.07.2009 | 11:30Yep, this far more nicer and cleaner solution than my, but I didn’t know about WP_LANG_DIR.
I would also point you to make more readable dropdowns for changing languages, I really don’t like en_US, or de_DE I would rather prefer English or Deutsch for choosing.
reply »
codestyling
28.07.2009 | 11:45Currently i’m testing the fixed version (and also the FTP credentials support for not writable webspaces).
The naming for languages i have also thought about, but where to obtain the names ?
Let’s say i write a *.php only containing a huge array of translation from “en_US” => “Englisch” etc.
I have to extend this any time a not yet available language appears. Furthermore what happens to “ja_SJIS.mo” in this case ?
It’s not trivial to map this with “user friendly” names, any suggestions are welcome.
reply »
Kornelije Sajler
28.07.2009 | 15:48Now I see that Localization is total mess!
First you mention ja_SJIS, but according to wikipedia SJIS is a character encoding and there is no ja_SJIS because it isn’t valid. Valid patterns are Language_Region like en_US, en_GB. United States, Great Britain are valid but Shift JIS is not valid region it’s a character encoding. Here I have found a lots of information and they all point to IANA text file, but thanks to Richard Ishida who have made a page for searching and displaying everything from IANA text file (and also leave PHP source code).
Problem with IANA is there is no rule, order or relation between Languages and Regions tags so nothing stop you to put a en_DE, as some kind of German English dialect, which is very liberal but is confusing and gives endless possibilities, so no help from IANA.
Now I can’t see only one solution to make “user friendly” names is to display name and language code. And I would’t translate “user friendly” name for me it must bi in Native language like Français, Deutsch, Hrvatski, עברית,…
And yes i think it had to be in array in .php file, I see no solution, but you could maybe sync with WP i18n repository, is there an attribute like native name of language in .mo file or somewhere else?
reply »
codestyling
28.07.2009 | 16:00Yes, that’s my daily struggle, there is no reliable standard.
I think, i will solve this as i did it for the localization plugin, just create an UTF-8 based *.php file containing an hash map and fill it as possible. It will result as fallback to the current locale specifier. It have to be updated whenever someone wants it language correctly named.
And no, the mo-files contains in best case the english language names but need not. So you can have non, lowercased, uppercased or something wired inside. It’s also not reliable.
reply »
ovidiu
29.07.2009 | 10:47just wondering, tried your plugin today, loading the available languages for download took 5 minutes, then when I click on any of the language files for downloading, all I get is a pop up saying: Error. Download not available.
am I doing somethign wrong? will check the logfiles later on from home, can’t check now, but if you have another idea, I am open for suggestions.
reply »
codestyling
29.07.2009 | 11:09The download search process takes some time, because the repository will be walked for all registered language directories. It’s new for me, that this takes upto 5 min, on my machine it takes 1.5 min to get the list of available languages. As reason for this delay i could only think about low connection speed from your server to other outside servers.
Download not available signals a problem in most cases. If repo scan founds something and lists it, it should also be downloadable. You didn’t write, if you have been requested for user credentials. This would be nice to know to have a direction where to investigate first.
It may be, that this could caused by missing language file folder at original US installations. Normally the folder should be at /wp-content/languages/ (normal WP versions). I will check, if missing such folder runs into this issue. You could check, if you have such a folder too.
reply »
ovidiu
29.07.2009 | 14:42ok, thx. forgot to mention its wpmu 2.8.2. where is the languages folder supposed to be so I can check? There is definitely no wp-content/languages folder here
and yes, its an original US english version, just downloaded…
No I wasn’t asked for credentials, the permissions are set up perfectly, I can isntall and edit themes and plugins from within wordpress jsut fine.
reply »
codestyling
29.07.2009 | 15:45I’ve checked the WPMU package and yes, the languages folder is missing as also known from US WP normal version. This folder should be created as /wp-content/languages, so you can also backup your localizable version by just zipping the wp-content folder.
WordPress internally searches first this folder and in case of missing it assumes, that the old one location is still been used (version prior to 2.6) as /wp-includes/languages
In the meantime i found out, that missing both folder the update won’t work as expected. I have changed this and will update this night a new version again.
If no such folder exists, WP sets the constant nevertheless to the old path. So a download will force creation of folder first based on the constant prior to populate it with files. I’m thinking about to report this as bug at WP Trac, because in case of missing both folders it should default the constant WP_LANG_DIR to the new instead of old on location.
reply »
ovidiu
30.07.2009 | 09:57thx. works now with the latest version
reply »