The problem: suppose a third-party module (e.g. brainstorm), want to declare it's own sub-plugin type (e.g. bsoperator). If these sub-plugins want to have language strings, the only option is to edit the core places_to_search_for_lang_strings function in moodlelib. It would be nice if this was not necessary. (See http://moodle.org/mod/forum/discuss.php?d=91846 for more background.)
My proposed solution is a new function register_lang_string_location($prefix, $path) that effectively adds a new entry entry to the array returned by places_to_search_for_lang_strings(). This can then be called from the top of mod/brainstorm/lib.php. The call would look like register_lang_string_location('bsoperator_', 'mod/brainstorm/operators').
This works because any code that uses a bsoperator must be part of the brainstorm module, and any code in the brainstorm module will have done require_once('mod/brainstorm/operators');
I think I would actually implement this using a singleton class to encapsulate everything. This class could also be used to contain some of the other private inner workings of get_string like places_to_search_for_lang_strings, clean_getstring_data, get_string_from_file, ...
Of course, no-one is suggesting that we change the outer API that the get_string function presents to the world.
If anything, this proposal should increase performance, because the list of places to search for strings will only contain areas that are relevant to the code that has been included so far in this request.
- has been marked as being related by
-
MDL-16438 centralise information about plugins to avoid duplication
-
- Closed
-