"
@end example
-@noindent
-Then, you should get these translated strings into compiled snippets in
-@file{Documentation/snippets}, see @q{General guidelines} in @ref{Adding
-and editing snippets}.
-
@code{@@example} blocks need not be verbatim copies, e.g. variable
names, file names and comments should be translated.
don't do so, some @code{@@lilypond} snippets might be broken or make
no sense in their context.
-When you have updated texidocs in
-@file{Documentation/@var{MY-LANGUAGE}/texidocs}, you can get these
-changes into compiled snippets in @file{Documentation/snippets}, see
-@q{General guidelines} in @ref{Adding and editing snippets}.
-
Finally, a command runs the three update processes above for all
enabled languages (from @file{Documentation/}):
git rev-list HEAD |head -1
@end example
-A special case is updating Snippet documentation strings in
-@file{Documentation/@var{MY-LANGUAGE}/texidocs}. For these to be
-correctly marked as up-to-date, first run @code{makelsr.py} as
-explained in @ref{Adding and editing snippets}, and commit the
-resulting compiled snippets left in @file{Documentation/snippets/}.
-Say the SHA1 ID code of this commit is <C>. Now edit again your
-translated files in @file{Documentation/@var{MY-LANGUAGE}/texidocs}
-adjusting the 40-digit committish that appears in the text to be <C>;
-finally, commit these updated files. Not doing so would result in
-changes made both to your updates and original snippets to
-persistently appear in the check-translation output as if they were
-out of sync.
-
-This two-phase mechanism avoids the (practically) unsolvable problem
-of guessing what committish will have our update, and pretending to
-put this very committish on the files in the same commit.
-
@c http://lists.gnu.org/archive/html/lilypond-devel/2009-01/msg00245.html
@c contains a helper script which could be used to perform massive
@c committish updates.
translations to Git.
@itemize
-@item Translation changes matching master branch are preferably made on
-@code{translation} branch; they may be pushed directly to
-@code{master} only if they do not break compilation of LilyPond and
-its documentation, and in this case they should be pushed to
-@code{translation} too. Similarly, changes matching
+@item Translation work is made on
+@code{translation} branch. This branch is merged on
+@code{staging} once a week, approximately. Then,
+@code{master} branch is merged on
+@code{translation}, where the check-translation script (see
+@ref{Check state of translation}) shows changes in English docs which
+should be translated, and the cycle starts again.
+
+@item Translations may be pushed directly to
+@code{staging} only if they do not break compilation of LilyPond and
+its documentation. Those changes could be pushed to
+@code{translation} too, or alternatively translators could wait until
+they come from
+@code{master} the next time it is merged on
+@code{translation}. Similarly, changes matching
@code{stable/X.Y} are preferably made on
-@code{lilypond/X.Ytranslation}.
+@code{X.Ytranslation}.
@item @code{translation} Git branch may be merged into
-master only if LilyPond (@command{make all}) and documentation
-(@command{make doc}) compile successfully.
-
-@item @code{master} Git branch may be merged into
-@code{translation} whenever @command{make} and @command{make
-doc} are successful (in order to ease documentation compilation by
-translators), or when significant changes had been made in
-documentation in English in master branch.
+@code{staging} branch only if LilyPond (@command{make all}) and
+documentation (@command{make doc}) compile successfully.
+
+@item @command{make} and @command{make doc} are usually successful in
+@code{master} Git branch because those tests should have already
+succeeded in
+@code{staging} branch before merging.
+@code{master} branch may be merged into
+@code{translation} when significant changes had been made in
+documentation in English in
+@code{master} branch.
@item General maintenance may be done by anybody who knows what he does
in documentation in all languages, without informing translators
first. General maintenance include simple text substitutions
(e.g. automated by sed), compilation fixes, updating Texinfo or
lilypond-book commands, updating macros, updating ly code, fixing
-cross-references, and operations described in @ref{Maintaining
-without updating translations}.
+cross-references, and operations described in
+@ref{Maintaining without updating translations}.
@end itemize
projects / lilypond.git / blobdiff