General developer forum

Hi,

Here come a proposal for a subplugin API architecture, with essential concerns with keeping fluid the i18n system.

This architecture was tested with success in the new Brainstorm version that will be published soon.

This has concerns with people who want to have their blocks or module extensible, so they would develop some form of plugability in it. The main issue with language files is that you may not be able to make Moodle explore your own subdirectories to discover and find automagically the new strings and help topics.

Here is the way I resolved it in Brainstorm.

Brainstorm has an extension pattern that uses an "operators" directory where subplugins reside. Each operator is a plugin that will be in a named directory in "operators".

So, the module topology is :

mod/
   brainstorm/
      brainstorm_files...
      operators/
          operator_commons...
          categorize/
             categorize_files...
             lang/
                en_utf8/
                   operator.php // the standard lang file for the sub plugin
                   help/
                      brainstorm_categorize/
                          help_files...
      lang/   // standard Moodle aware language pack
          en_utf8/
              brainstorm.php
              help/
                 brainstorm/
                    help_files...
                operatorrouter.html  // the important one see below
                         
Of course Moodle cannot foresee where to find subplugins it ignores all of. Let see how to automate language discovery and resolution.

first, we must link dynamically the operators language packs.

in each legacy langpack after the module's stringset we set :

///get all operators lang files
global $CFG, $USER, $SITE;
$DIR = opendir($CFG->dirroot.'/mod/brainstorm/operators');
$lang = current_language();
while($opname = readdir($DIR)){
    if (!is_dir($CFG->dirroot.'/mod/brainstorm/operators/'.$opname)) continue;
    if (ereg("^\\.", $opname)) continue;
    if (file_exists("{$CFG->dirroot}/mod/brainstorm/operators/{$opname}/lang/{$lang}/operator.php")){
        include "{$CFG->dirroot}/mod/brainstorm/operators/{$opname}/lang/{$lang}/operator.php";
    }
}

This scans directory of plugins when the lang file is read by Moodle and add as strings as necessary.

Next, we have an issue on help files. They would be NEVER found so deep in the module pack.

Here the trick is that the help button invokes a target html page by name checking the file ends with .html or not.
The standard way to call the help file is avoiding appending the .html extension, so the call is simply :

<?php helpbutton('sequentialaccess', get_string('sequentialaccess', 'brainstorm'), 'brainstorm'); ?>

The helpbutton function luckily do not check if we have appended other parms or not. So we can invoke it
in a tweacked manner :

<?php helpbutton('operatorrouter.html&amp;operator=categorize&amp;helpitem=allowmultiple', get_string('allowmultiple', 'brainstorm'), 'brainstorm'); ?>

This invokes a standard help file we have in our Moodle aware help directory, but passing along extra parms to that file, so it could deroute its realisation with other content :

In our sub plugin router we find :

<?php
$operator = required_param('operator', PARAM_TEXT);
$helpitem = required_param('helpitem', PARAM_TEXT);
$helpfile = "{$CFG->dirroot}/mod/brainstorm/operators/$operator/lang/{$lang}/help/brainstorm_{$operator}/{$helpitem}";
include $helpfile;
?>

In other words, we made a special help files that loads from another help pack location inside our subarchitecture !!

This works fine and could be used for assignement, where subs assigmenttype lang files are not of immediate use, or questiontype either.

This assumes .html files are php enabled (the actual standard setup in most out-of-the-box web server setups).

Cheers.