Issue Details (XML | Word | Printable)

Key: MDL-13816
Type: Improvement Improvement
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Tim Hunt
Reporter: Tim Hunt
Votes: 1
Watchers: 5
Operations

Add/Edit UI Mockup to this issue
If you were logged in you would be able to see more operations.
Moodle

Improve the mechanisms by which the places to search for plugins' language strings is managed

Created: 06/Mar/08 07:29 PM   Updated: 30/Mar/09 02:13 PM
Component/s: Languages
Affects Version/s: 1.9
Fix Version/s: 2.0

Issue Links:
Relates
 

Participants: Tim Hunt
Security Level: None
Resolved date: 30/Mar/09
Affected Branches: MOODLE_19_STABLE
Fixed Branches: MOODLE_20_STABLE


 Description  « Hide
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.



 All   Comments   Change History   Version Control      Sort Order: Ascending order - Click to sort in descending order
Tim Hunt added a comment - 30/Mar/09 02:12 PM
Following MDL18669, this is now possible to do with a method register_plugin_type the string_manager class.

However, the issue is help files. When help.php is requested, there is no way to know what calls to register_plugin_type were made on the page that printed the link to the help file. I think the only secure way round that is to store extra plugin types in the session.

New mechanism documented on http://docs.moodle.org/en/Development:Places_to_search_for_lang_strings#Advanced_usage:_what_to_do_when_your_plugin_type_supports_sub-plugins