We would like to use a custom implementation of the string manger in order to add new strings or modify them for Moodle core components. But in the API this is not recommended: “This is supposed to be used in experimental and/or development scenarios only, not in typical production environment.“ https://docs.moodle.org/dev/String_API#Custom_string_managers
Can anyone tell
me
the reason why this should not be used in a production environment?
Thanks!
The Moodle tracker ticket (linked to from the documentation you've mentioned) really sums up why it is not recommended for general use.
But really the bigger question is why would you want to use it on a production site?
If you want to customise language strings, then you can already do that by editing them in the user interface (site admin > language > language customisation).
If you need to deploy customised language strings, you can copy (or even version control with git) the [moodle data]\lang\[langcode]_local directory.
If you need new language strings, you can create a new plugin and put as many language strings as you want in it.
Hello Davo Smith,
thanks for your reply.
One example is, we would like to modify the feedback module. I need to add a new item to the feedback but I want to do as little as possible core modifications.
I need to add a new folder to to mod/feedback/item thats OK, but I also would need to change the lang file and add a string with the identifier of my new item folder name at mod/feedback/lang/en/feedback.php, because when Moodle renders the select choices of the possible feedback questions these strings are used.
At the user interface (site admin > language > language customisation) it is not possible to add new strings we can only modify existing ones.
Furthermore I have
another problem with the string customization, we work on 3 different
Systems, a development, a test and a production server with three
different dataroots. If we could modify the strings in our Plugin we
only need to do the string modification one time.
At the
Moodle tracker there are different use cases for development
scenarios mentioned but I could not find the reason why this should
not be used in production.
As I've mentioned already, it is possible to version control the [moodledata]/lang/en_local folder (we've done this for one customer, for similar reasons), but agreed that it isn't quite as convenient as having all the code in one place.
The feedback situation is unfortunate - it would be a lot better if plugins there could be entirely self-contained.
I guess it is up to you as to whether you prefer to use on production a feature designed only for developer usage that is not (officially) tested during Moodle code upgrades and which has no guarantee of working / existing in the future; OR if you feel it is a greater risk to add a couple of extra lines to the end of one (or more) of the core language files. I'd, personally, go for the 2 extra lines in the language file. However, I have to implement so many customer requests that are really impossible without (small) core changes, that, maybe, I've just got too comfortable with doing that (and letting git handle the maintenance).
