Here's my use case:
- Review a contribution for version say 3.2 of Moodle (but valid for other versions)
- Click on "Commit" (a bit to quickly ), forgetting to propage it before
- The contribution is accepted, all OK, but...
- Click on "Show resolved contributions", locate the already committed one and click on it
- Click on "Apply" and observe that all strings are on white background (normal situation)
- No way to propagate these strings to other versions of Moodle
My question: is there a way to propagate already committed contributions in one version to other (newer and older) versions of Moodle?
Firstly, you should not need to worry about it. AMOS has a regular job running which propagates strings to other versions automatically in most cases. So if a string translation has been committed to one version only, AMOS will eventually auto-propagate it to other versions where the translation is still missing.
If the contribution contains a modification of an existing translation, AMOS should again auto-propagate the change if (and only if) the same change applies there cleanly.
The explicit propagation via the button is useful in rare cases only when the string has different translation in two branches. Let us assume there is an English string "Foo" which you you have translated as "Bar" on 3.3 and "Baz" on 3.2. If there was a contribution that changes the translation to "Qux" on 3.3 only, AMOS would not auto-propagate it to 3.2. But if it was translated to "Bar" on both versions, AMOS should apply the change to them.
In either case, the AMOS Stage page provides additional advanced tools such as "Merge strings from another branch" and "Compare strings at two branches" that you can use to double check potential inconsistencies between Moodle versions.
Hope this clarifies.
I was not aware of this automatic propagation mechanism. Thanks for the clarification. IMHO it would be useful to know the schedule of this automatic task. Could it be possible to document it, maybe here: https://docs.moodle.org/dev/AMOS_manual?
(I sometimes use "Merge strings..." and "Compare strings..." useful tools.)
Sorry, my memory was actually wrong. I just checked the code and it seems to be like this:
- There is no scheduled job, this auto-propagation happens immediately after you commit the change.
- When talking about a scheduled job, I was confused by the fact that when a contributed Moodle plugin is submitted to AMOS and it now supports a new Moodle version, AMOS auto-propagates existing translations.
- This auto-propagation only fills the missing translations and does not overwrite any existing translation. So the example with Foo, Bar, Baz ad Qux was wrong. You would need to propagate explicitly to change the existing string. Now I recall it is intentional - the maintainer may have good reasons for why the same English string is translated differently in two Moodle versions. And AMOS should not try to be more clever than the human maintainer.
My apologize for the confusion. And yes, please feel encouraged to update the AMOS manual docs
Thanks David, much appreciated info.
Re: You would need to propagate explicitly to change the existing string.
If I understand correctly, that means that I would have to propagate strings that should be overwritten. How could I do this for an already committed contribution?
PS. I'll try to update the AMOS doc with my monkey english
How could I do this for an already committed contribution?
IIRC (I sometimes do!) you should be able to "Apply" any contribution, even accepted one. So the contributed translation will get back to your stage and you should be able to propagate them.
The other option would be to use the advanced tools mentioned above.
Please let me know the contribution number should you run to any troubles.
Ah, now I see it. AMOS does not display the propagate buttons if there are no committable strings on the stage. But to get some committable strings, we need to propagate this contribution first (kind of chicked - egg problem).
As a quick workaround, it should help to add yet another translation change (can be even unstaged after propagating). I will appreciate an MDLSITE issue for this (or even a pull request would be great ).
Thanks in advance!