we got the request from a group of German academic plugin developers to maintain the German translation of their own plugins. There were some issues that other German users of the plugins made improvements that were incorrect. The idea is now that they get permissions to check improvements that are related to their plugins.
We didn't see this option actually.
Are there any suggestiosn how to handle this?
Is there a similar situation in other languages and how do you handle this?
I am not really affected by the problem Ralf has described (at least I am not aware that I am affected ;) ), but as I am also a "german academic plugin developer", I'd like to add my 2 cents:
We have contributed several plugins to the Moodle plugins repo and have decided to follow the best practice to only ship the english language pack with the plugin and to translate the german language - our native language - in AMOS.
This has the positive effect that everyone in the community is able to improve the german translation and that the german language pack maintainers can have an eye on several fixed terms (like the consistent naming of "student" or "teacher" in german Moodle).
However, this strategy becomes negative as soon as other german community members try to "improve" translations of our plugins but get it wrong. It's not hard to imagine a scenario where someone else changes some important term of the german translation of one of our plugins in AMOS and gets the change through the language pack maintainer's review. As soon as this change will get downloaded (nowadays automatically) to our Moodle, this change might produce problems for our users and might raise our support effort. In the end, we might need to change the string back in AMOS which is even worse for the whole community.
So, it would be great if
a) we as plugin developers would be able to review string changes of one or some (previously defined) languages of our own plugins instead of relying on the work of the central language pack maintainers.
b) or we as plugin developers would at least be pinged about changes of one or some (previously defined) languages of our plugins which were just accepted by the central language pack maintainers.
Furthermore, with such a mechanism, we could lower the workload of the central language pack maintainers because mostly they are only pushing through the translations for our own plugins which have been thoroughly worked out before by us.
PS: This corresponds somehow with the outstanding ticket https://tracker.moodle.org/browse/MDLSITE-2957 which might also improve the traceability of the language pack maintainer's changes to a AMOS contribution.
Thanks for your work,
You suggest something like a language pack maintainer on the level of a module? And probably over several languages (at least English and the native language of the module developer).
I never came across this problem. I wonder if it is a problem that happened coincidentally to you a few times or if the problem is widespread and bugs all plugin developers. If the first is the case, then talking with the language pack maintainer can be a good idea: a change is very noticeable in a contribution and should/could be looked at closer then to a new string.
On the defend of language pack maintainers: if you get a contribution with 250 strings of various modules, that is a nightmare to review. 30 strings of 1 module should really be the max.
I see. Would it help if you were able to subscribe/watch automatically all AMOS contributions that alter the given component's strings? Say you would subscribe to the atto_styles component and AMOS would automatically notify you when a new contribution arrives with some atto_styles string changes. You could then check the contribution and eventually leave your point of view there in the contribution comments area.
thanks for your answer.
Your proposal is basically what I described in my proposal b).
And, yes, that would be helpful. (It would even solve question 3 of my post in https://lang.moodle.org/mod/forum/discuss.php?d=3068).
just that you know - we were the ones who brought that up and the problem occurred as in our Publication module the term student was changed from "Studierende" to "Teilnehmer" which also changed the plugin original name, which in the end was a problem because of the documentations we created for this module. There was also confusion among our users, because the module somehow "vanished" on production system because of the changed name.
Your solution is definitely a step in the right direction and would be really helpful.
Just out of curiosity: would there be a possibility to be german lang maintainer just for the AMC plugins that we develop?
would there be a possibility to be german lang maintainer just for the AMC plugins that we develop?
Well. You can make an agreement with German pack maintainers that they would not touch your plugins in AMOS. The existing strings could be removed from AMOS and you would put the lang/de/ folder back into your plugin source code (the AMOS version takes precedence IIRC). So you would have that under your own control. It is a hacky and non-systematic solution but, to be honest, I do not feel the use case is strong enough to have this as a general AMOS feature.
yeah I get your point of view - so watching or subscribing to our modules would be really a great step into the right direction.
yes, being able to subscribe/watch automatically all AMOS contributions to AMC plugins would certainly help. I don't think the problem occurs very often, but if it occurs, it results in some confusion. With your proposed solution the AMC partners could be a little bit more conservative with automatic language updates via cron, e.g. once every two weeks instead of daily. This would give us (and the language maintainer) some time to handle a language change made by someone else which we consider problematic.
I look at the problem like this: Moodle's default language (english) is under control of the plugin developer, but all other languages aren't. But with all AMC partners actually running german Moodle instances, our default language is actually german – which we would like to control ourselves Being able to maintain the german language files of the AMC plugins ourselves would therefore be the preferred solution.