2011/10/31 David Kastrup <d...@gnu.org>: > The syntax changed in incompatible ways. Appropriate changes to > convertrules.py were made, and update-with-convert-ly was run on the > tree including the translations, keeping the translations compilable but > untranslated. No manual changes were made to the translations. > > Of course, this is a nuisance to translators, but I really don't see how > we could do any better than that.
I now understand that you are right. > We had the additional complication that the merges from staging changed > the structure of the commits and separated them into a commit doing the > syntax change itself, and the commit with the convert-ly run. The > above-mentioned commit is such a syntax change commit leaving the tree > in uncompilable state without the immediately following commit. > > We can do better than that and eventually will, but I don't think this > should cause your current problems. What actions do you propose for new translations when syntax changes occurr? They are not visible from the lilypond/translation branch until I merge master into it. I could be wrong, but I recall having merged and performed a successful doc compile before pushing. As new files appeared, they did not have the required changes for a successful compile when eventually merged onto master. In the worst case, this unadverted situation leads to a break in master, but it is very rare. For this to happen, three things are required (all three did happen when ja/ broke). A- Syntax changes. B- Master was last merged into lilypond/translation before these changes. C - new files, previously non-existant, were translated AND they were affected by those syntax changes. I think it is a rare enough situation as to not to be too much worried. It has an easy fix, too. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
