I think i18n support for WordPress external elements should be clarified to ease their maintain and contributions.
Here is a proposal of structure :
+ wp-content/
+- i18n/
-- catalog.pot
-- fr_FR.mo
+- plugins/
+-- i18n/
---- provider/
----- catalog.pot
----- fr_FR.mo
+-- sample-plugin/
+--- i18n/
----- catalog.pot
----- fr_FR.mo
---- README.txt
---- sample-plugin.php
+- themes
+-- sample-theme/
+--- i18n/
----- catalog.pot
----- fr_FR.mo
* wp-content/i18n
Contains all translation related to WP (the equivalend of the languages/ directory)
* plugins/i18n
Contains all global translations for providers (actually located in plugins/provider-fr_FR.mo for example)
* plugins/sample-plugin/i18n
Contains translations specific to a plugin
* themes/sample-theme/i18n
Contains translations specific to a theme
It would be good to complete that with a textdomain_namespace('provider/; ./') to implicitly use i18n files located in i18/provider/{locale_LOCALE}.mo} and sample-plugin/i18n/{locale_LOCALE}.mo}. The goal is to avoid usage of __('Text', 'textdomain') which is a real pain.
i18n files at the root of the plugin directory is not esthetic and difficult to explain to users.
With that everything is coined up and can give ideas to introduce some conventions.
