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;
}