I agree that plugins should always allow for localization. It's
trivial to do, so there is no reason not to do it.
The rest I all dont agree with at this stage in the APIs development.
Not only is roundcube still in a 0.x release, the API is still not
fully settled. People have requests for hooks, and other elements of
the API regularly. People need to be able to play with the API and
see as many examples as possible, and arbitrary rules that plugins
have to adhere to before being published is just counter-productive as
this stage. The plugins themselves are currently acting as
documentation. For that reason I try to document my plugins as much as
I can in the code itself (see for instance my compose_addressbook
plugin that uses many of RCs cool features like ajax back and forth
communication). If you want to play with plugins right now, be
prepared to read the code and learn. Also be prepared to come to the
API Plugins section in the forums where most plugin authors lurk.
It would be a good idea for future development to allow for a version
check in the API. But I would be careful on how strict to apply it.
Plugins are more often than not abandonware, fire and forget. But that
doesnt mean they cant still be useful many releases into the future.
The only way you would want to be strict is in applying a minimal
version your plugin needs. You absolutely dont want to be strict on
the highest version your plugin supports, as that causes chaos as RC
upgrades (except for the few plugins that RC ships with).
I do think we'll see a plugin repository in the not too distant
future, and when that happens i fully agree we can be more strict with
plugins. Until that time, be glad people are even making plugins. Most
plugins dont need much documentation and are easy to figure out.
Cor
List info: http://lists.roundcube.net/dev/