Right, I just committed a quick update to the trunk. Ssnews should now no longer fall over if it can't find an RSS feed. I am having trouble with Updates though, as when I try to replicate your issue, the error is generated from within the HTTP class. Not sure what to do about that at the moment, but you should (Hopefully) be able to re-enable your Ssnews plugin now.

Cheers,

Mo

Hi Mo,
I just installed your dashboard on 2.3.6 - and I think it's just absolutely beautiful :-)

Question: are you planning on implementing any internationalization?...

EDIT: oops, stupid me - I saw that of course you did most of the work already. I'll try and help look for the few that are missing...

Hi Mo,

I collected a couple of missing i18n's in a textfile overview. If I can be of help implementing them, just say the word. Btw: how would you create a language file from the getTranslatedProperty() system? I don't suppose the TextCollector will work?

Hi Martimiz,

Thanks for this, I will try and integrate it as soon as i get a chance :).

As for internationalization, unforunatly I am one of those damn un-neighbourly people who only speak one language (and sometimes I struggle at that :) ). So I haven't ever really had much need to do any research into getting multilingual sites up and running. I probably will in the future, but I will cross that bridge when you come to it.

To answer your question, do you mean you want to know how to make Silverstripe output the translated version of your site, rather than the default?

Mo

Thanks Mo, and no probs, I know it can't be top priority for everyone. It's just us outlanders that keep translating everything all the time :-( I usually set up the backend in the language my client prefers, which mostly isn't English, and I'd love to add a translated version of your dashboard :-)

As to my question - what I usually do after finishing a module, I let the TextCollector class graze it to create a default en_US.php language file (to be translated later). It travels all these _t(....) ocurrences in code and templates to extract $lang[][] translations.

So now I'm trying to understand: you automated your plugins to look for translated statics with getTranslatedProperty()? I was wondering how you would go about adding these translations to the languagefile in the first place, since the TextCollector won't spot them. If you'd add them manually, you'd have to keep track of new additions and plugins all the time, so I thought maybe you were thinking of some kind of script..?

[EDIT] Found it - I really wanted to know how to do this myself as well :-)
I hope you don't take this wrong - I'm absolutely awed by what you've done with this module, and I already learned so much more from it then from most tutorials, your coding is so clear and beautifully documented :-)

Anyway: it's the i18nEntityProvider interface that does the trick: just have all plugins implement it, and then add something like this (although maybe less crude) to the DashboardPlugin class:

    /*
     *  Provide languagefile-info to the i18NTextCollector 
     *  to add translations for static vars in all plugins
     *  that implement the i18nEntityProvider
     */
	function provideI18nEntities() {
		$entities = array();
		$properties = array('title', 'link_text', 'caption', 'null_message');
		foreach($properties as $property) {
			$val = $this->stat($property);
			if (!empty($val)) {

				// equal to getTranslatedProperty()
				$index = $this->toLangVar($val);
                		$entities["{$index}"][] = str_replace("'", "\'", $val);
			}
		}
		return $entities;
	}

Credit where it is due, Uncle cheese wrote the plugin engine and I then integrated it and tweeked and modified it a bit to be more generic. This module has defiantly been a group initiative :) . I just hope lots of people get some use out of it.

Also, I just committed a new version to the trunk. It should add all the internationalisation stuff we have talked about, I also listed all the _t variables in a lang/en_US.php of lang/en_GB.php. Hopefully that will make your life easier?

Try it out, if you have any issues, let me know :).

Cheers,

Mo

Thanks Mo AND Uncle cheese :-)

Also thanks for doing the translations, Mo. Still loving the module! Some small issues maybe. The textCollector won't find translations that have no default text. So it will find this:

_t('ClassName.TEST', 'A test')

But not this:

_t('ClassName.TEST')

Meaning you'd always have to keep track of and add translations to the languagefile by hand...

Using a generic namespace 'dashboard' has it's advantages, I agree, but it can also make finding the context a bit difficult, since there's no reference to any template or classfile in the languagefile.

Also - might it be a good idea to use the name of the variable as an index instead of its value, to avoid very long indexes like ? In getTranslatedProperty():

return _t($this->toLangVar($property),$val);

instead of

return _t($this->toLangVar($val),$val);

A little thing: In SSNews.php (trunk) if(file_exists(self::$rss_url)) doesn't work on my server, fopen or get_headers do, but I'm not sure if that would be the right approach.

Hi all,

for a client I create a multilanguage site. But when I selectes another language in tha Page Tree, I was redirected to the Dashboard and not to the Pages section with the pages in the other language. When I click on Pages, I see the page tree in the defaul language.

For everyone who has the same problem, I created a workaround:

in /dashboard/_config.php replace

if(
	$curUrl[0] == Director::baseURL() . 'admin/' ||
	$curUrl[0] == Director::baseURL() . 'admin'
) {
	Director::addRules(50, array(
		'admin' => '->admin/dashboard/'
));

by:

if(!isset($_GET['locale'])) {//TRANSLATION issue fix
if(
	$curUrl[0] == Director::baseURL() . 'admin/' ||
	$curUrl[0] == Director::baseURL() . 'admin'
) {
	Director::addRules(50, array(
		'admin' => '->admin/dashboard/'
	));
}
}//TRANSLATION issue fix

But is there a 'legal' or bettter solution?