For reference (raised by rozzin in IRC):
* http://foldoc.org/module
* http://foldoc.org/library
* http://foldoc.org/plugin
As noted by XRevan86, modules are not necessarily non-essential.
As we will keep the modules directory in GS root [therefore, near to
plugins/], it is evidenced the difference between both.
This is a simple yet fundamental structural change. It doesn't change
functionality but makes clearer the way we understand GNU social's
internals.
New plugins:
* LRDD
LRDD implements client-side RFC6415 and RFC7033 resource descriptor
discovery procedures. I.e. LRDD, host-meta and WebFinger stuff.
OStatus and OpenID now depend on the LRDD plugin (XML_XRD).
* WebFinger
This plugin implements the server-side of RFC6415 and RFC7033. Note:
WebFinger technically doesn't handle XRD, but we serve both that and
JRD (JSON Resource Descriptor), depending on Accept header and one
ugly hack to check for old StatusNet installations.
WebFinger depends on LRDD.
We might make this even prettier by using Net_WebFinger, but it is not
currently RFC7033 compliant (no /.well-known/webfinger resource GETs).
Disabling the WebFinger plugin would effectively render your site non-
federated (which might be desired on a private site).
Disabling the LRDD plugin would make your site unable to do modern web
URI lookups (making life just a little bit harder).
lib/plugin.php now has a parent onAutoload function that finds most common
files that are used in plugins (actions, dataobjects, forms, libs etc.) if
they are put in the standardised directories ('actions', 'classes', 'forms',
'lib' and perhaps some others in the future).
This will apply to *ALL* plugins in *ALL* languages, so should probably only be used when doing site customization...
You'd probably do:
$config['site']['locale_path'] = '/srv/awesome/data/locale';
$config['plugins']['locale_path'] = '/srv/awesome/data/locale';
with a structure like:
srv/
awesome/
data/
locale/
en/
LC_MESSAGES/
statusnet.po
OpenID.po
AnonymousFave.po
etc, all alongside each other. You could separate plugins from the core if you like.
Where locale files have not already been generated, you can build one for a plugin like so:
php scripts/update_po_templates.php --plugin=MyPlugin
and pull out the template file:
plugins/MyPlugin/locale/MyPlugin.pot
Edit that (make sure you at least set the CHARSET, probably to UTF-8) and save your customized .po
files into the structure as above, and use msgfmt to generate .mo files for final output.
