X-Git-Url: https://git.donarmstrong.com/?a=blobdiff_plain;f=Documentation%2Fcontributor%2Fdoc-work.itexi;h=87fb7955b943a1ca400ac8b30a9a0c6011f8485b;hb=c99f1a7a513f2f239928ea208ac457bd36f0ff56;hp=9ac318eb6d38fe9b244f6dd8e9860abe83c9e627;hpb=f51609af5239aa5024a8d8c0750e293384fd7381;p=lilypond.git diff --git a/Documentation/contributor/doc-work.itexi b/Documentation/contributor/doc-work.itexi index 9ac318eb6d..87fb7955b9 100644 --- a/Documentation/contributor/doc-work.itexi +++ b/Documentation/contributor/doc-work.itexi @@ -14,6 +14,7 @@ Version Control System (VCS) called git, previously discussed in @menu * Introduction to documentation work:: +* version in documentation files:: * Documentation suggestions:: * Texinfo introduction and usage policy:: * Documentation policy:: @@ -66,6 +67,41 @@ Before undertaking any large documentation work, contributors are encouraged to contact the @ref{Meisters, Documentation Meister}. +@node version in documentation files +@section @code{\version} in documentation files + +Every documentation file which includes LilyPond code must begin +with a @code{\version} statement, since the build procedure +explicitly tests for its presence and will not continue otherwise. +The @code{\version} statement should reference a version of LilyPond +consistent with the syntax of the contained code. + +Since the @code{\version} statement is not valid Texinfo input it +must be commented out like this: + +@example +@@c \version "2.19.1" +@end example + +So, if you are adding LilyPond code which is not consistent with the +current version header, you should + +@enumerate + +@item +run convert-ly on the file using the latest version of LilyPond +(which should, if everybody has done proper maintenance, not change +anything); + +@item +add the new code; + +@item +modify the version number to match the new code. + +@end enumerate + + @node Documentation suggestions @section Documentation suggestions @@ -84,11 +120,17 @@ Please write exact changes to the text. @item A formal patch to the source code is @emph{not} required; we can -take care of the technical details. Here is an example of a -perfect documentation report: +take care of the technical details. + +@item +Send the suggestions to the @code{bug-lilypond} mailing list as +discussed in @rweb{Contact}. + +@item +Here is an example of a perfect documentation report: @verbatim -To: lilypond-devel@gnu.org +To: bug-lilypond@gnu.org From: helpful-user@example.net Subject: doc addition @@ -140,20 +182,42 @@ Please prepare a formal git patch. @end enumerate +@subheading Contributions that contain examples using overrides + +Examples that use overrides, tweaks, customer Scheme functions etc. are +(with very few exceptions) not included in the main text of the manuals; +as there would be far too many, equally useful, candidates. + +The correct way is to submit your example, with appropriate explanatory +text and tags, to the LilyPond Snippet Repository (LSR). Snippets that +have the @qq{docs} tag can then be easily added as a +@emph{selected snippet} in the documentation. It will also appear +automatically in the Snippets lists. See @ref{Introduction to LSR}. + +Snippets that @emph{don't} have the @qq{docs} tag will still be +searchable and viewable within the LSR, but will be not be included in +the Snippets list or be able to be included as part of the main +documentation. + +Generally, any new snippets that have the @qq{docs} tag are more +carefully checked for syntax and formatting. + +@subheading Announcing your snippet + Once you have followed these guidelines, please send a message to lilypond-devel with your documentation submissions. Unfortunately -there is a strict “no top-posting” check on the mailing list; to avoid +there is a strict @q{no top-posting} check on the mailing list; to avoid this, add: -> I'm not top posting. +@code{> I'm not top posting} + +(you must include the > ) to the top of your documentation addition. -(you must include the > ) to the top of your documentation -addition. +We may edit your suggestion for spelling, grammar, or style, and we may +not place the material exactly where you suggested, but if you give us +some material to work with, we can improve the manual much faster. -We may edit your suggestion for spelling, grammar, or style, and -we may not place the material exactly where you suggested, but if -you give us some material to work with, we can improve the manual -much faster. Thanks for your interest! +Thanks for your interest! @node Texinfo introduction and usage policy @@ -193,18 +257,18 @@ to do anything fancy, discuss it on @code{lilypond-devel} first.} All manuals live in @file{Documentation/}. In particular, there are four user manuals, their respective master -source files are @file{learning@/.tely} (LM, Learning Manual), -@file{notation@/.tely} (NR, Notation Reference), -@file{music@/-glossary@/.tely} (MG, Music Glossary), and -@file{lilypond@/-program} (AU). Each chapter is written in a separate +source files are @file{learning.tely} (LM, Learning Manual), +@file{notation.tely} (NR, Notation Reference), +@file{music-glossary.tely} (MG, Music Glossary), and +@file{lilypond-program} (AU). Each chapter is written in a separate file, ending in @file{.itely} for files containing lilypond code, and @file{.itexi} for files without lilypond code, located in a subdirectory -associated to the manual (@file{learning/} for @file{learning@/.tely}, and +associated to the manual (@file{learning/} for @file{learning.tely}, and so on); list the subdirectory of each manual to determine the filename of the specific chapter you wish to modify. Developer manuals live in @file{Documentation/} too. Currently there is -only one: the Contributor's Guide @file{contrib@/-guide@/.texi} you are +only one: the Contributor's Guide @file{contrib-guide.texi} you are reading. Snippet files are part of documentation, and the Snippet List (SL) lives @@ -215,27 +279,50 @@ how to modify the snippet files and SL, see @ref{LSR work}. @node Sectioning commands @subsection Sectioning commands -Most of the manual operates at the +The Notation Reference uses section headings at four, occasionally +five, levels. + +@itemize + +@item Level 1: @@chapter +@item Level 2: @@section +@item Level 3: @@subsection +@item Level 4: @@unnumberedsubsubsec +@item Level 5: @@subsubsubheading +@end itemize + +The first three levels are numbered in html, the last two are not. +Numbered sections correspond to a single html page in the split html +documents. + +The first four levels always have accompanying nodes so they can be +referenced and are also included in the ToC in html. + +Most of the manual is written at level 4 under headings created with @example @@node Foo -@@subsubsection Foo +@@unnumberedsubsubsec Foo @end example -@noindent -level. Sections are created with +Level 3 subsections are created with @example @@node Foo @@subsection Foo @end example -@itemize -@item +Level 4 headings and menus must be preceded by level 3 headings and +menus, and so on for level 3 and level 2. If this is not what is +wanted, please use: + +@example +@@subsubsubheading Foo +@end example + Please leave two blank lines above a @code{@@node}; this makes it easier to find sections in texinfo. -@item Do not use any @code{@@} commands for a @code{@@node}. They may be used for any @code{@@sub...} sections or headings however. @@ -249,21 +336,47 @@ but instead: @@subsection @@code@{Foo@} Bar @end example -@item -If a heading is desired without creating a @code{@@node}, please use -the following: +No punctuation may be used in the node names. If the heading text +uses punctuation (in particular, colons and commas) simply leave +this out of the node name and menu. @example -@@subheading Foo +@@menu +* Foo Bar:: +@@end menu + +@@node Foo Bar +@@subsection Foo: Bar @end example -@item +Backslashes must not be used in node names or section headings. +If the heading text should include a backslash simply leave this +out of the node name and menu and replace it with @code{@@bs@{@}} +in the heading text. + +@example +@@menu +* The set command +@@end menu + +@@node The set command +@@subsection The @@code@{@@bs@{@}set@} command +@end example + +References to such a node may use the third argument of the +@code{@@ref} command to display the texually correct heading. + +@example +@@ref@{The set command,,The @@code@{@@bs@{@}set command@} +@end example + +With the exception of @code{@@} commands, @code{\} commands and +punctuation, the section name should match the node name exactly. + Sectioning commands (@code{@@node} and @code{@@section}) must not appear inside an @code{@@ignore}. Separate those commands with a space, ie @code{@@n}@tie{}@code{ode}. -@end itemize - Nodes must be included inside a @example @@ -274,8 +387,8 @@ Nodes must be included inside a @end example @noindent -construct. These are easily constructed with automatic tools; see -@ref{Scripts to ease doc work}. +construct. These can be constructed with scripts: +see @ref{Stripping whitespace and generating menus}. @node LilyPond formatting @@ -283,6 +396,77 @@ construct. These are easily constructed with automatic tools; see @itemize +@item +Most LilyPond examples throughout the documentation can be produced +with: + +@example +@@lilypond[verbatim,quote] +@end example + +If using @code{\book@{@}} in your example then you must also +include the @code{papersize=X} variable, where @code{X} is a defined +paper size from within @file{scm/paper.scm}. This is to avoid the +default @code{a4} paper size being used and leaving too much unnecessary +whitespace and potentially awkward page breaks in the PDFs. + +The preferred @code{papersize}s are @code{a5}, @code{a6} or +@code{a8landscape}. + +@code{a8landscape} works best for a single measure with a single title +and/or single @code{tagline}: + +@example +@@lilypond[papersize=a8landscape,verbatim] +\book @{ + \header @{ + title = "A scale in LilyPond" + @} + \relative @{ + c d e f + @} +@} +@@end lilypond +@end example + +and can also be used to easily show features that require page breaks +(i.e. page numbers) without taking large amounts of space within the +documentation. Do not use the @code{quote} option with this paper size. + +@code{a5} or @code{a6} paper sizes are best used for examples that have +more than two measures of music or require multiple staves (i.e. to +illustrate cross-staff features, RH and LH parts etc.) and where +@code{\book@{@}} constructions are required or where @code{a8landscape} +produces an example that is too cramped. Depending on the example the +@code{quote} option may need to be omitted. + +In rare cases, other options may be used (or omitted), but ask first. + +@item +Please avoid using extra spacing either after or within the +@code{@@lilypond} parameters. + +@example +not: @@lilypond [verbatim, quote, fragment] +but instead: @@lilypond[verbatim,quote,fragment] +@end example + +@item +Inspirational headwords are produced with: + +@example +@@lilypondfile[quote,ragged-right,line-width=16\cm,staffsize=16] +@{pitches-headword.ly@} +@end example + +@item +LSR snippets are linked with: + +@example +@@lilypondfile[verbatim,quote,ragged-right,texidoc,doctitle] +@{filename.ly@} +@end example + @item Use two spaces for indentation in lilypond examples (no tabs). @@ -303,7 +487,7 @@ to get users accustomed to this scheme construct, i.e. @code{\set Staff.instrumentName = #"cello"} @item -Try to avoid using @code{#'} or @code{#`} within when describing +Try to avoid using @code{#'} or @code{#`} when describing context or layout properties outside of an @code{@@example} or @code{@@lilypond}, unless the description explicitly requires it. @@ -321,49 +505,11 @@ checks. @item Tweaks should, if possible, also occur on their own line. @example -not: \override TextScript #'padding = #3 c1^"hi" -but instead: \override TextScript #'padding = #3 +not: \override TextScript.padding = #3 c1^"hi" +but instead: \override TextScript.padding = #3 c1^"hi" @end example -@item -Most LilyPond input should be produced with: - -@example -@@lilypond[verbatim,quote,relative=2] -@end example - -@noindent -or - -@example -@@lilypond[verbatim,quote,relative=1] -@end example - -If you want to use @code{\layout@{@}} or define variables, use - -@example -@@lilypond[verbatim,quote] -@end example - -In rare cases, other options may be used (or omitted), but ask first. - -@item -Inspirational headwords are produced with - -@example -@@lilypondfile[quote,ragged-right,line-width=16\cm,staffsize=16] -@{pitches-headword.ly@} -@end example - -@item -LSR snippets are linked with - -@example -@@lilypondfile[verbatim,lilyquote,ragged-right,texidoc,doctitle] -@{filename.ly@} -@end example - @noindent excepted in Templates, where `doctitle' may be omitted. @@ -433,7 +579,7 @@ Beam, slur and tie marks should begin immediately after the first note with beam and phrase marks ending immediately after the last. @example -a8(\ ais16[ b cis( d] b) cis4~ b' cis,\) +a8\( ais16[ b cis( d] b) cis4~ b' cis,\) @end example @item @@ -444,8 +590,6 @@ easier/faster processing), use this header: \paper @{ indent = 0\mm line-width = 160\mm - 2.0 * 0.4\in - ragged-right = ##t - force-assignment = #"" line-width = #(- line-width (* mm 3.000000)) @} @@ -748,16 +892,33 @@ Don't capitalize the first word. @itemize @item @code{@@enumerate} --- Create an ordered list (with numbers). -Always put @samp{@@item} on its own line, and separate consecutive -items with a blank line: +Always put @samp{@@item} on its own line. As an exception, if all +the items in the list are short enough to fit on single lines, placing +them on the @samp{@@item} lines is also permissible. @samp{@@item} +and @samp{@@end@tie{}enumerate} should always be preceded by a blank +line. @example @@enumerate + @@item -Foo +A long multi-line item like this one must begin +on a line of its own and all the other items in +the list must do so too. @@item -Bar +Even short ones + +@@end enumerate +@end example + +@example +@@enumerate + +@@item Short item + +@@item Short item + @@end enumerate @end example @@ -771,6 +932,18 @@ the same format as @code{@@enumerate}. Do not use @node Special characters @unnumberedsubsubsec Special characters +@warning{In Texinfo, the backslash is an ordinary character, and +is entered without escaping (e.g. +@samp{The@tie{}@@code@{@bs{}foo@}@tie{}command}). However, within +double-quoted Scheme and/or LilyPond strings, backslashes +(including those ending up in Texinfo markup) need to be escaped +by doubling them: +@example +(define (foo x) + "The @@code@{@bs{}@bs{}foo@} command..." + ...) +@end example} + @itemize @item @code{--}, @code{---} --- Create an en dash (--) or an em dash @@ -963,7 +1136,7 @@ write: DYNAMICS may be manually placed above or below the staff, see @@ref@{Controlling direction and placement@}. Most tweaks should be added to LSR and not placed directly in the -.itely file. In some cases, tweaks may be placed in the main +@file{.itely} file. In some cases, tweaks may be placed in the main text, but ask about this first. Finally, you should assume that users know what the notation @@ -1033,6 +1206,9 @@ Notation Reference: Application Usage: @@rprogram@{blah@}. +Essay on automated music engraving: +@@ressay@{yadda@}. + Extending LilyPond: @@rextend@{frob@}. @@ -1076,7 +1252,7 @@ manual. @item @@predefined ... @@endpredefined is for commands in -@file{ly/@/*-init@/.ly} +@file{ly/*-init.ly} @item Do not include any real info in second-level sections (i.e. 1.1 @@ -1263,7 +1439,7 @@ concern. Check for potential additions. @item move LSR-worthy material into LSR. Add the snippet, delete the -material from the .itely file, and add a @@lilypondfile command. +material from the @file{.itely} file, and add a @@lilypondfile command. @item check the examples and descriptions. Do they still work? @@ -1292,7 +1468,7 @@ harder than it looks. In general, any \set or \override commands should go in the @qq{select snippets} section, which means that they should go in -LSR and not the .itely file. For some cases, the command +LSR and not the @file{.itely} file. For some cases, the command obviously belongs in the @qq{main text} (i.e. not inside @@predefined or @@seealso or whatever) -- instrument names are a good example of this. @@ -1304,7 +1480,7 @@ good example of this. On the other side of this, @example -\override Score.Hairpin #'after-line-breaking = ##t +\override Score.Hairpin.after-line-breaking = ##t @end example clearly belongs in LSR. @@ -1333,30 +1509,26 @@ the difficulty. @node Scripts to ease doc work @section Scripts to ease doc work -@subheading Building only one section of the documentation - -In order to save build time, a script is available to build only -one section of the documentation in English with a default html -appearance. +@menu +* Scripts to test the documentation:: +* Scripts to create documentation:: +@end menu -The script is available as: +@node Scripts to test the documentation +@subsection Scripts to test the documentation -@example -scripts/auxiliar/doc-section.sh -@end example - -This script will require customization for your site if your -LilyPond git repository is anyplace but @code{$HOME/lilypond}. +@menu +* Building only one section of the documentation:: +@end menu -Assuming that no customization is required, you can setup the -single section build with: +@node Building only one section of the documentation +@unnumberedsubsubsec Building only one section of the documentation -@example -mkdir $HOME/lilypond/tempdocs -cp $HOME/lilypond/Documentation/out/version.itexi $HOME/lilypond/tempdocs -@end example +In order to save build time, a script is available to build only +one section of the documentation in English with a default html +appearance. -You can then build a section of the documentation with: +You can build a section of the documentation with: @example scripts/auxiliar/doc-section.sh MANUAL SECTION @@ -1372,6 +1544,25 @@ Notation Reference, use the command: scripts/auxiliar/doc-section.sh notation pitches @end example +You can then see the generated document for the section at + +@example +tempdocs/pitches/out/pitches.html +@end example + +According to +@uref{http://code.google.com/p/lilypond/issues/detail?id=1236,Lilypond issue 1236}, +the location of the lilypond git tree is taken from @code{$LILYPOND_GIT} +if specified, otherwise it is auto-detected. + +It is assumed that compilation takes place in the @file{build/} +subdirectory, but this can be overridden by setting the environment +variable @code{LILYPOND_BUILD_DIR}. + +Similarly, output defaults to @file{build/tempdocs/} but this can be +overridden by setting the environment variable +@code{LILYPOND_TEMPDOCS}. + This script will not work for building sections of the Contributors' guide. For building sections of the Contributors' Guide, use: @@ -1389,13 +1580,24 @@ use: scripts/auxiliar/cg-section.sh doc-work @end example -Like @code{doc-section.sh}, @code{cg-section.sh} may need to be customized -for your installation. +@code{cg-section.sh} uses the same environment variables and +corresponding default values as @code{doc-section.sh}. + +@node Scripts to create documentation +@subsection Scripts to create documentation -@subheading Stripping whitespace and generating menus +@menu +* Stripping whitespace and generating menus:: +* Stripping whitespace only:: +* Updating doc with convert-ly:: +@end menu + +@node Stripping whitespace and generating menus +@unnumberedsubsubsec Stripping whitespace and generating menus @warning{This script assumes that the file conforms to our doc -policy; a few files still need work in this regard.} +policy, in particular with regard to @ref{Sectioning commands}; +a few files still need work in this regard.} To automatically regenerate @code{@@menu} portions and strip whitespace, use: @@ -1404,19 +1606,28 @@ whitespace, use: scripts/auxiliar/node-menuify.py @var{FILENAME} @end example +If you are adding documentation that requires new menus, +you will need to add a blank @code{@@menu} section: -@subheading Stripping whitespace only +@example +@@menu +@@end menu +@end example + +@node Stripping whitespace only +@unnumberedsubsubsec Stripping whitespace only @c TODO: should this be documented elsewhere? It's useful for @c more than just docs. To remove extra whitespace from the ends of lines, run @example -scripts/auxiliar/strip-whitespace.py Documentation/FILENAME +scripts/auxiliar/strip-whitespace.py @var{FILENAME} @end example -@subheading Updating doc with @command{convert-ly} +@node Updating doc with convert-ly +@unnumberedsubsubsec Updating doc with @command{convert-ly} Don't. This should be done by programmers when they add new features. If you notice that it hasn't been done, complain to @@ -1428,7 +1639,7 @@ features. If you notice that it hasn't been done, complain to Material in the Internals reference is generated automatically from our source code. Any doc work on Internals therefore -requires modifying files in @file{scm/@/*.scm}. Texinfo is allowed +requires modifying files in @file{scm/*.scm}. Texinfo is allowed in these docstrings. Most documentation writers never touch these, though. If you want @@ -1463,7 +1674,7 @@ take some time before your request or contribution is handled. @node Getting started with documentation translation @subsection Getting started with documentation translation -First, get the sources of branch @code{lilypond/translation} from the +First, get the sources of branch @code{translation} from the Git repository, see @ref{Starting with Git}. @menu @@ -1551,7 +1762,7 @@ make ISOLANG=@var{MY-LANGUAGE} new-lang where @var{MY-LANGUAGE} is the ISO 639 language code. Finally, add a language definition for your language in -@file{python/@/langdefs@/.py}. +@file{python/langdefs.py}. @node Documentation translation details @@ -1653,7 +1864,7 @@ will be handled by someone who will translate it to English and send it on bug-lilypond or add an issue in the tracker, then translate back the reply from developers. -@item @rweb{Help us}: this page should be translated very freely, +@item @rcontrib{Help us}: this page should be translated very freely, and possibly not at all: ask help for contributing to LilyPond for tasks that LilyPond community in your language is able and going to handle. @end itemize @@ -1669,19 +1880,19 @@ script @command{texi-langutils.py} and the makefile target are updated. Some pieces of text manipulated by build scripts that appear in the output are translated in a @file{.po} file -- just like LilyPond output -messages -- in @file{Documentation/@/po}. The Gettext domain is named +messages -- in @file{Documentation/po}. The Gettext domain is named @code{lilypond-doc}, and unlike @code{lilypond} domain it is not managed through the Free Translation Project. Take care of using typographic rules for your language, especially in -@file{macros@/.itexi}. +@file{macros.itexi}. If you wonder whether a word, phrase or larger piece of text should be translated, whether it is an argument of a Texinfo command or a small piece sandwiched between two Texinfo commands, try to track whether and where it appears in PDF and/or HTML output as visible text. This piece -of advice is especially useful for translating @file{macros@/.itexi}. +of advice is especially useful for translating @file{macros.itexi}. Please keep verbatim copies of music snippets (in @code{@@lilypond} blocs). However, some music snippets containing text that shows in @@ -1707,15 +1918,15 @@ When you encounter @end example @noindent -in the source, open @file{Documentation/@/snippets/@/@var{filename}@/.ly}, +in the source, open @file{Documentation/snippets/@var{filename}.ly}, translate the @code{texidoc} header field it contains, enclose it with @code{texidoc@var{MY-LANGUAGE} = "} and @code{"}, and write it into -@file{Documentation/@/@var{MY-LANGUAGE}/@/texidocs/@/@var{filename}@/.texidoc}. +@file{Documentation/@var{MY-LANGUAGE}/texidocs/@/@var{filename}.texidoc}. Additionally, you may translate the snippet's title in @code{doctitle} header field, in case @code{doctitle} is a fragment option used in @code{@@lilypondfile}; you can do this exactly the same way as @code{texidoc}. For instance, -@file{Documentation/@/@var{MY-LANGUAGE}/@/texidocs/@/@var{filename}@/.texidoc} +@file{Documentation/@var{MY-LANGUAGE}/texidocs/@/@var{filename}.texidoc} may contain @example @@ -1725,11 +1936,6 @@ Spanish translation blah " @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. @@ -1842,7 +2048,7 @@ to make your translation up to date. @seeCommittishesUpdate Global state of the translation is recorded in -@file{Documentation/@/translations@/.itexi}, which is used to generate +@file{Documentation/translations.itexi}, which is used to generate Translations status page. To update that page, do from @file{Documentation/} @@ -1850,7 +2056,7 @@ Translations status page. To update that page, do from make translation-status @end example -This will also leave @file{out/@/translations@/-status@/.txt}, which contains +This will also leave @file{out/translations-status.txt}, which contains up-to-dateness percentages for each translated file, and update word counts of documentation files in this Guide. @@ -1892,8 +2098,8 @@ that such files should be updated, run from @file{Documentation/} make ISOLANG=@var{MY_LANGUAGE} skeleton-update @end example -@file{.po} message catalogs in @file{Documentation/@/po/} may be updated -by issuing from @file{Documentation/} or @file{Documentation/@/po/} +@file{.po} message catalogs in @file{Documentation/po/} may be updated +by issuing from @file{Documentation/} or @file{Documentation/po/} @example make po-update @@ -1914,8 +2120,8 @@ make ISOLANG=@var{MY_LANGUAGE} snippet-update @end example This script overwrites music snippets in -@file{@var{MY_LANGUAGE/@/foo/@/every@/.itely}} with music snippets from -@file{@var{foo/@/every@/.itely}}. It ignores skeleton files, and keeps +@file{@var{MY_LANGUAGE/foo/every.itely}} with music snippets from +@file{@var{foo/every.itely}}. It ignores skeleton files, and keeps intact music snippets preceded with a line starting with @code{@@c KEEP LY}; it reports an error for each @file{.itely} that has not the same music snippet count in both languages. Always use this script @@ -1924,11 +2130,6 @@ the changes it made with @command{git diff} before committing; if you 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/}): @@ -1963,27 +2164,21 @@ by doing 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 . 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 ; -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. +Most of the changes in the LSR snippets included in the documentation concern +the syntax, not the description inside @code{texidoc=""}. This implies that +quite often you will have to update only the committish of the matching +.texidoc file. This can be a tedious work if there are many snippets to be +marked as up do date. You can use the following command to update the +committishes at once: + +@example +cd Documentation/LANG/texidocs +sed -i -r 's/[0-9a-z]@{40@}/NEW-COMMITTISH/' *.texidoc +@end example @seealso @ref{LSR work}. @@ -2020,9 +2215,9 @@ The following tasks are listed in decreasing priority order. @item Update macros.itexi. For each obsolete macro definition, if it is possible to update macro usage in documentation with an automatic text or regexp substitution, -do it and delete the macro definition from macros.itexi; otherwise, +do it and delete the macro definition from @file{macros.itexi}; otherwise, mark this macro definition as obsolete with a comment, and keep it in -macros.itexi until the documentation translation has been updated and +@file{macros.itexi} until the documentation translation has been updated and no longer uses this macro. @item Update @file{*.tely} files completely with @@ -2091,7 +2286,9 @@ useful) and paste with @key{C-y} or @key{C-v}. @item Update sections finished in the English documentation; check sections status at +@smallexample @uref{http://lilypondwiki.tuxfamily.org/index.php?title=Documentation_coordination}. +@end smallexample @item Update documentation PO. It is recommended not to update strings which come from documentation that is currently deeply revised @@ -2153,31 +2350,44 @@ This policy explains how to manage Git branches and commit translations to Git. @itemize -@item Translation changes matching master branch are preferably made on -@code{lilypond/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{lilypond/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{lilypond/translation} Git branch may be merged into -master only if LilyPond (@command{make all}) and documentation -(@command{make doc}) compile successfully. +@item @code{translation} Git branch may be merged into +@code{staging} branch only if LilyPond (@command{make all}) and +documentation (@command{make doc}) compile successfully. -@item @code{master} Git branch may be merged into -@code{lilypond/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. +@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 @@ -2186,7 +2396,7 @@ without updating translations}. A number of Python scripts handle a part of the documentation translation process. All scripts used to maintain the translations -are located in @file{scripts/@/auxiliar/}. +are located in @file{scripts/auxiliar/}. @itemize @item @file{check_translation.py} -- show diff to update a translation, @@ -2202,21 +2412,21 @@ in the sources; WARNING only use this script once for each file, when support fo "makeinfo --html" has been dropped. @end itemize -Other scripts are used in the build process, in @file{scripts/@/build/}: +Other scripts are used in the build process, in @file{scripts/build/}: @itemize @item @file{mass-link.py} -- link or symlink files between English documentation and documentation in other languages. @end itemize -Python modules used by scripts in @file{scripts/@/auxiliar/} or @file{scripts/@/build/} (but -not by installed Python scripts) are located in @file{python/@/auxiliar/}: +Python modules used by scripts in @file{scripts/auxiliar/} or @file{scripts/build/} (but +not by installed Python scripts) are located in @file{python/auxiliar/}: @itemize @item @file{manuals_definitions.py} -- define manual names and name of cross-reference Texinfo macros, @item @file{buildlib.py} -- common functions (read piped output of a shell command, use Git), -@item @file{postprocess_html.py} (module imported by @file{www_post@/.py}) -- add footer and +@item @file{postprocess_html.py} (module imported by @file{www_post.py}) -- add footer and tweak links in HTML pages. @end itemize