Note: the issue described in this post should be very rare, as it depends on the specific architecture we use to develop our plugins. We decided to share our findings, so that they may be useful if anyone else encounters the same issue.
We were using Codestyling Localization to localise our plugins, when we noticed that some of them did not appear in the list of the available ones, despite being fully localised. After some in-depth debugging, we discovered an edge condition that prevents the localisation plugin from detecting our plugins' text domain.
The issue occurs because most of our plugins are now relying on a "framework plugin", developed by us, which implements dependency checks and some classes that can be reused by "child" plugins. One of these classes takes care of the plugin initialisation, and it loads the appropriate text domain as well. As a result, none of the files in the directory where the child plugin is installed contains a call to
Codestyling Localization searches for such string in the plugin files, but it doesn't find it, therefore it skips the plugin, even though the localisation is loaded correctly.
The workaround for this issue is to add a call to
load_plugin_textdomain() somewhere in each child plugin (we usually put it in the constructor of plugin's main class). Even though the operation is redundant, it doesn't cause any side effect, as translations are merged with the ones loaded by the parent plugin, which are exactly the same.