1 \input texinfo @c -*-texinfo-*-
2 @setfilename internals.info
3 @settitle LilyPond internals
6 @node Top, LilyPond internals, (dir), (dir)
11 * LilyPond internals::
21 @node LilyPond internals, , Top, Top
26 * Request_engraver:: Request_engraver
30 @chapter Getting involved
32 Please help us make LilyPond a better program. You can help LilyPond in
33 several ways. Not all tasks requiring programming or understanding the
34 full source code. You can write to the mailing list
35 (@email{gnu-music-discuss@@gnu.org} for more information)
37 @unnumberedsubsec Users
39 Mutopia needs your help. The mutopia project is a collection of public
40 domain sheet music. You can help the project by entering music and
41 submitting. Point your browser to the
42 @uref{http://sca.uwaterloo.ca/Mutopia, Mutopia webpage}
44 @unnumberedsubsec Font designers
46 Our set of glyphs (the Feta font) is far from complete. If you know a
47 little MetaFont you can contribute a glyph
49 @unnumberedsubsec Writers
51 The documentation of LilyPond and related utilities needs a lot of work.
53 @unnumberedsubsec Translators
55 LilyPond is completely ready for internationalized messages, but there
56 are only three translations so far.
58 @unnumberedsubsec Hackers
60 There are lots of possibilities of improving the program itself. There are
61 both small projects and big ones. Most of them are listed in the TODO
62 file. A interesting and very big project is writing a GUI frontend to
66 @chapter LilyPond internals
69 This documents some aspects of the internals of GNU LilyPond. Some of
70 this stuff comes from e-mail I wrote, some from e-mail others wrote,
71 some are large comments taken away from the headers. This page may be
72 a little incoherent. Unfortunately, it is also quite outdated. A
73 more thorough and understandable document is in the works.
75 You should use @code{doc++} to take a peek at the sources.
77 @node Overview, mudela, Top, Top
80 GNU LilyPond is a "multi-pass" system. The different passes have been
81 created so that they do not depend on each other. In a later stage
82 some parts may be moved into libraries, or seperate programs, or they
83 might be integrated in larger systems.
89 No difficult algorithms. The .ly file is read, and converted to a list
90 of @code{Scores}, which each contain @code{Music} and paper/midi-definitions.
92 @item Interpreting music
94 The music is walked through in time-order. The iterators which do the
95 walking report Music to Translators which use this information to
96 create elements, either MIDI or "visual" elements. The translators
97 form a hierarchy; the ones for paper output are Engravers, for MIDI
100 The translators swallow Music (mostly atomic gobs called Requests),
101 create elements, broadcast them to other translators on higher or same
102 level in the hierarchy:
104 The stem of a voice A is broadcast to the staff which contains A, but
105 not to the stems, beams and noteheads of a different voice (say B) or
106 a different staff. The stem and noteheads of A are coupled, because
107 the the Note_heads_engraver broadcasts its heads, and the Stem_engraver catches
110 The engraver which agrees to handle a request decides whether to to
111 honor the request, ignore it, or merge it with other requests. Merging
112 of requests is preferably done with other requests done by members of
113 the same voicegroups (beams, brackets, stems). In this way you can put
114 the voices of 2 instruments in a conductor's score so they make chords
115 (the Beam requests of both instruments will be merged).
119 Breakable stuff (eg. clefs and bars) are copied into pre and
124 Some dependencies are resolved, such as the direction of stems, beams,
125 and "horizontal" placement issues (the order of clefs, keys etc,
126 placement of chords in multi-voice music),
128 @item Break calculation:
130 The lines and horizontal positions of the columns are determined.
134 Through some magical interactions with Line_of_score and Super_elem
135 (check out the source) the "lines" are produced.
137 All other spanners can figure across which lines they are spread. If
138 applicable, they break themselves into pieces. After this, each piece
139 (or, if there are no pieces, the original spanner itself) throws out
140 any dependencies which are in the wrong line.
144 Some items and all spanners need computation after the Paper_column
145 positions are determined. Examples: slurs, vertical positions of
152 @node mudela, Request_engraver, Overview, Top
155 [FIXME: implementation has been generalised, so this is out of date]
157 Most information is stored in the form of a request. In music
158 typesetting, the user might want to cram a lot more symbols on the
159 paper than actually fits. To reflect this idea (the user asks more
160 than we can do), the container for this data is called Request.
162 In a lot of other formats this would be called an 'Event'
165 @item @code{Barcheck_req}
166 Checks during music processing if start of this voice element
167 coincides with the start of a measure. Handy to check if you left out
169 @item @code{Note_req}
170 LilyPond has to decide if the ball should be hanging left or
171 right. This influences the horizontal dimensions of a column, and this
172 is why request processing should be done before horizontal spacing.
173 Other voices' frivolities may cause the need for accidentals, so this
174 is also for the to decide. The engraver can decide on positioning based on
175 ottava commands and the appropriate clef.
176 @item @code{Rest_req}
178 @item @code{Span_req}
179 This type of request typically results in the creation of a @code{Spanner}
180 @item @code{Beam_req}
182 Engraver has to combine this request with the stem_request, since the
183 number of flags that a stem wants to carry will determine the
186 Each dynamic is bound to one note (a crescendo spanning multiple
187 notes is thought to be made of two "dynamics": a start and a stop).
188 Dynamic changes can occur in a smaller time than the length of its
189 note, therefore each @code{Dynamic} request carries a time, measured
190 from the start of its note.
193 @node Request_engraver, , mudela, Top
194 @section Request_engraver
196 In the previous section the idea of Request has been explained, but
197 this only solves one half of the problem. The other half is deciding
198 which requests should be honored, which should merged with other
199 requests, and which should be ignored. Consider this input
203 \type Staff < % chord
204 @{ \meter 2/4; [c8 c8] @}
205 @{\meter 2/4; [e8 e8] @}
210 Both the cs and es are part of a staff (they are in the same
211 Voice_group), so they should share meters, but the two [ ] pairs
214 The judge in this "allocation" problem a set of brokers: the requests
215 are transmitted to so-called engravers which respond if they want to
216 accept a request eg, the @code{Notehead_engraver} will accept
217 @code{Note_req}s, and turn down @code{Slur_req}s. If the Music_iterator
218 cannot find a engraver that wants the request, it is junked (with a
221 After all requests have been either assigned, or junked, the Engraver
222 will process the requests (which usually means creating an @code{Item}
223 or @code{Spanner}). If a @code{Request_engraver} creates something, it
224 tells the enclosing context. If all items/spanners have been created,
225 then each Engraver is notified of any created Score_element, via a
228 @unnumberedsubsec example:
240 Note_request (duration 1/4)
241 Stem_request (duration 1/4)
245 Note_request will be taken by a @code{Notehead_engraver}, stem_request
246 will be taken by a @code{Stem_beam_engraver}. @code{Notehead_engraver}
247 creates a @code{Notehead}, @code{Stem_beam_engraver} creates a
248 @code{Stem}. Both announce this to the Staff_engraver. Staff_engraver
249 will tell @code{Stem_beam_engraver} about the @code{Notehead}, which
250 will add the @code{Notehead} to the @code{Stem} it just created.
252 To decide on merging, several engravers have been grouped. Please
253 check @file{init/engraver.ly}.
255 @node Backend, , , Top
259 @section The backend of LilyPond
266 * Graphic elements:: blah
267 * Position and width Callbacks:: blah
268 * Score_element properties:: blah
269 * Score elements:: blah
276 @node Graphic elements, , , Backend
278 Music notation is composed of a sets of interrelated glyphs. In
279 Lilypond every glyph usually is represented by one object, a so-called
280 Graphic Object. The primary relations between graphic objects involve
284 @item consecutive notes are printed left to right, grouped in a staff
285 @item simultaneous notes are horizontally aligned (internally grouped in
287 @item the staccato mark is horizontally centered on the note it applies
291 The abstract encoding of such relations is done with the concept
292 @dfn{reference point}. The reference point (in X direction) of the
293 staccato mark is the note it applies to. The (X) position of the
294 staccato mark is stored relative to the position of the note head. This
295 means that the staccato will always maintain a fixed offset wrt to the
296 note head, whereever the head is moved to.
298 In the same vein, all notes on a staff have their Y positions stored
299 relative to an object that groups the staff. If that object is moved,
300 the absolute Y positions of all objects in that spanner change along, in
301 effect causing the staff and all its contents to move as a whole.
303 Each graphic object stores a pointer and an relative offset for each
304 direction: one for the X-axis, one for the Y-axis. For example, the X
305 parent of a Note_head usually is a Note_column. The X parent of a
306 Note_column usually is either a Collision or a Paper_column. The X
307 parent of a Collision usually is a Paper_column. If the Collision
308 moves, all Note_heads that have that Collision as parent also move, but
309 the absolute position of the Paper_column does not change.
311 To build a graphical score with Graphic_elements, conceptually, one
312 needs to have one Root object (in Lilypond: Line_of_score), and
313 recursively attach objects to the Root. However, due to the nature
314 of the context selection mechanisms, it turns out to be more
315 advantageous to construct the tree the other way around: first small
316 trees (note heads, barlines etc.) are created, and these are
317 subsequently composed into larger trees, which are finally hung on a
318 Paper_column (in X direction) or Line_of_score (in Y direction).
320 The structure of the X,Y parent relations are determined by the
321 engravers and notation contexts:
323 The most important X-axis parent relation depends on the timing: notes
324 that come earlier are attached to Paper_column that will be positioned
327 The most important Y-axis relation depends on containment of contexts:
328 notes (created in a Thread or Voice context) are put in the staff where
329 the originating context lives in.
331 Graphical_axis_groups are special graphic objects, that are designed to
332 function as a parent. The size of a Graphical_axis_groups group is the
333 union of its children.
335 @node Position and width Callbacks, , , Backend
337 The positions are, as explained relative to a parent reference
338 point. Most positions are not known when an object is created, so these
339 are calculated as needed. This is done by adding a callback for a
340 specific direction, eg
344 my_translate (Score_element * ptr, Axis a)
350 my_element->add_offset_callback (my_translate, Y_AXIS)
353 When a call is made to @code{my_element->relative_position (obj,
354 Y_AXIS)}, @code{my_translate} will be called. The result is that
355 my_element will be translated up by 5 pt. There are numerous callbacks,
358 @item to offset element by staff-spaces (See class
359 @code{Staff_symbol_referencer}).
360 @item to align elements next to other groups of elements (See class
361 @code{Side_position_interface})
365 Offset callbacks can be stacked. The callbacks will be executed in the
366 order that they were added.
368 Width and height are similarly implemted using extent callbacks. There
369 can be only one callback for each axis. No callback (the 0 ptr) means:
370 "empty in this direction".
372 @node Score_element properties, , , Backend
374 Score elements can have other properties besides positioning, for
375 example, text strings (for text objects) style settings, glyphs, padding
376 settings (for scripts). These settings are stored in element properties.
378 Properties are stored as GUILE association lists, with symbols as keys.
379 Element properties can be accessed using the C++ functions
382 SCM get_elt_property (SCM) const;
383 void set_elt_property (const char * , SCM val);
384 void set_immutable_elt_property (const char * , SCM val);
385 void set_immutable_elt_property (SCM key, SCM val);
386 void set_elt_property (SCM , SCM val);
387 void set_elt_pointer (const char*, SCM val);
388 SCM remove_elt_property (const char* nm);
391 All lookup functions identify undefined properties with GUILE
392 end-of-list (ie. @code{'()} in Scheme or @code{SCM_EOL} in C)
394 Implementation wise, there are two kinds of properties:
397 @item mutable properties:
398 element properties that change from object to object. The storage of
399 these are private to a Score element. Typically this is used to store
400 lists of pointers to other objects
402 @item immutable properties:
403 element properties that are shared across objects. The storage is
404 shared, and hence is read-only. Typically, this is used to store
405 function callbacks, and values for shared element properties are read
406 from @file{ly/engraver.ly}.
410 The following is from lily 1.3.80, and it shows the settings for the bar
411 numbers: Bar numbers are breakable, and visible at the beginning of the
412 line. The setting for @code{molecule-callback} indicates that Bar_number
413 is implemented as a text.
415 basicBarNumberProperties = #`(
416 (molecule-callback . ,Text_item::brew_molecule)
418 (visibility-lambda . ,begin-of-line-visible)
424 In 1.3.81 an music expression was added to add to the immutable property
428 \pushproperty #'(basicBarNumberProperties)
429 #'visibility-lambda #end-of-line-visible
432 This will add the entry @code{`(visibility-lambda .
433 ,end-of-line-visible)} to the immutable property list for bar numbers,
434 in effect overriding the setting from @file{ly/engraver.ly}. This can be
438 \popproperty #'(basicBarNumberProperties)
442 Note that you must accompany these statements with a proper context
443 selection in most cases.
450 @node Score elements, , , Backend
452 [FIXME: we want to get rid of dependencies in the implementation.]
454 Besides relative positions there are lots of other relations between
455 elements. Lilypond does not contain other specialized relation
456 management (Like the relative positioning code). Instead, objects can
457 be connected through dependencies, which sets the order in which objects
460 Example: the direction of a beamed stem should equal the direction of
461 the beam. When the stem is a added to the beam, a dependency on the
462 beam is set in the stem: this means that @code{Beam::do_pre_processing
463 ()} (which does various direction related things) will be called before
464 @code{Stem::do_pre_processing ()}.
466 The code that manages dependencies resides in the class
467 @code{Score_element}, a derived class of @code{Graphical_element}. The
468 bulk of the code handles line breaking related issues.
470 To sketch the problems with line breaking: suppose a slur spans a line
474 c4( c'''' c | \break d d )d
477 In this case, the slur will appear as two parts, the first part spanning
478 the first three notes (the @code{c}s), the second spanning the last
479 three (the @code{d}s). Within Lilypond this is modeled as breaking the
480 slur in parts: from the Original slur, two new clones of the old slur
481 are made. Initially both clones depend on the six notes. After the
482 hairy code in Score_element, Spanner and Item which does substitutions
483 in sets of dependencies, the first clone depends on the first three
484 notes, the second on the last three.
486 The major derived classes of Score_element are Item and Spanner.
487 An item has one horizontal position. A spanner hangs on two items.
489 @node Items, , , Backend
494 An item is a score element that is associated with only one
495 Paper_column. Examples are note heads, clefs, super and superscripts, etc.
496 Item is a derived class of Score_element.
498 The shape of an item is known before the break calculations, and line
499 spacing depends on the size of items: very wide items need more space
500 than very small ones.
502 An additional complication is the behavior of items at linebreaks. For
503 example, when you do a time signature change, you get only one symbol.
504 If it occurs at a linebreak, the new time signature must be printed both
505 before and after the linebreak. Other `breakable symbols' such as
506 clefs, and bar lines also exhibit this behavior.
508 if a line of music is broken, the next line usually gets a clef. So in
509 TeX terms, the clef is a postbreak. The same thing happens with meter
510 signs: Normally the meter follows the bar. If a line is broken at that
511 bar, the bar along with the meter stays on the "last" line, but the next
512 line also gets a meter sign after the clef. To support this,
513 breakable items are generated in the three versions: original
514 (unbroken), left (before line break) and right (after line break).
515 During the line spacing, these versions are used to try how the spacing
518 Once the definitive spacing is determined, dependencies (and various
519 other pointers) are substituted such that all dependencies point at the
520 active items: either they point at the original, or they point at left
523 @node Spanners, , , Backend
526 Spanners are symbols that are of variable shape, eg. Slurs, beams, etc.
527 Spanners is a derived class of Score_element.
529 The final shape can only be determined after the line breaking process.
530 All spanners are spanned on two items, called the left and right
531 boundary item. The X reference point is the left boundary item.
534 @node Future work, , , Backend
537 There are plans to unify Spanner and Item, so there will no longer be
538 such a clear distinction between the two. Right now, Score_elements are
539 always either Item or either Spanner.
541 @node Coding standards, , , Top
543 @chapter CodingStyle - standards while programming for GNU LilyPond
545 Functions and methods do not return errorcodes: they never crash, but
546 report a programming_error and try to carry on.q
549 @unnumberedsubsec Languages
551 C++ and Python are preferred. Perl is forbidden. Python code should
552 use an indent of 8, using TAB characters.
554 @unnumberedsubsec Filenames
556 Definitions of classes that are only accessed via pointers
557 (*) or references (&) shall not be included as include files.
563 ".cc" Implementation files
564 ".icc" Inline definition files
565 ".tcc" non inline Template defs
571 (setq auto-mode-alist
572 (append '(("\\.make$" . makefile-mode)
573 ("\\.cc$" . c++-mode)
574 ("\\.icc$" . c++-mode)
575 ("\\.tcc$" . c++-mode)
576 ("\\.hh$" . c++-mode)
577 ("\\.pod$" . text-mode)
583 The class Class_name_abbreviation is coded in @file{class-name-abbr.*}
585 @unnumberedsubsec Indentation
587 Standard GNU coding style is used. In emacs:
590 (add-hook 'c++-mode-hook
591 '(lambda() (c-set-style "gnu")
596 If you like using font-lock, you can also add this to your @file{.emacs}:
599 (setq font-lock-maximum-decoration t)
600 (setq c++-font-lock-keywords-3
602 c++-font-lock-keywords-3
603 '(("\\b\\([a-zA-Z_]+_\\)\\b" 1 font-lock-variable-name-face)
604 ("\\b\\([A-Z]+[a-z_]+\\)\\b" 1 font-lock-type-face))
608 @unnumberedsubsec Classes and Types
614 @unnumberedsubsec Members
618 Type Class::member_type_
619 Type Class::member_type ()
622 the @code{type} is a Hungarian notation postfix for @code{Type}. See below
624 @unnumberedsubsec Macros
626 Macros should be written completely in uppercase
628 The code should not be compilable if proper macro declarations are not
631 Don't laugh. It took us a whole evening/night to figure out one of
632 these bugs, because we had a macro that looked like
633 @code{DECLARE_VIRTUAL_FUNCTIONS ()}.
635 @unnumberedsubsec Broken code
637 Broken code (hardwired dependencies, hardwired constants, slow
638 algorithms and obvious limitations) should be marked as such: either
639 with a verbose TODO, or with a short "ugh" comment.
641 @unnumberedsubsec Comments
643 The source is commented in the DOC++ style. Check out doc++ at
644 @uref{http://www.zib.de/Visual/software/doc++/index.html}
649 C style comments for multiline comments.
650 They come before the thing to document.
656 Long class documentation.
659 TODO Fix boring_member ()
670 short memo. long doco of member ()
671 @@param description of arguments
674 Rettype member (Argtype);
678 data_member_ = 121; // ugh
685 Unfortunately most of the code isn't really documented that good.
687 @unnumberedsec Hungarian notation naming convention
689 Proposed is a naming convention derived from the so-called
690 @emph{Hungarian Notation}. Macros, @code{enum}s and @code{const}s are all
691 uppercase, with the parts of the names separated by underscores.
693 The hungarian notation is to be used when variables are not declared
694 near usage (mostly in member variables and functions).
696 @unnumberedsubsec Types
700 unsigned char. (The postfix _by is ambiguous)
714 Zero terminated c string
719 @unnumberedsubsec User defined types
727 Slur* slur_p = new Slur;
731 @unnumberedsubsec Modifiers
733 The following types modify the meaning of the prefix.
734 These are preceded by the prefixes:
742 const. Note that the proper order is @code{Type const}
743 i.s.o. @code{const Type}
745 A const pointer. This would be equivalent to @code{_c_l}, but since any
746 "const" pointer has to be a link (you can't delete a const pointer),
749 temporary pointer to object (link)
751 pointer to newed object
756 @unnumberedsubsec Adjective
758 Adjectives such as global and static should be spelled out in full.
759 They come before the noun that they refer to, just as in normal english.
763 foo_global_i: a global variable of type int commonly called "foo".
767 static class members do not need the static_ prefix in the name (the
768 Class::var notation usually makes it clear that it is static)
772 Variable loop: an integer
774 Temporary variable: an unsigned integer
776 Variable test: a character
777 @item @code{first_name_str}
778 Variable first_name: a String class object
779 @item @code{last_name_ch_a}
780 Variable last_name: a @code{char} array
782 Variable foo: an @code{Int*} that you must delete
784 Variable bar: an @code{Int*} that you must not delete
787 Generally default arguments are taboo, except for nil pointers.
789 The naming convention can be quite conveniently memorised, by
790 expressing the type in english, and abbreviating it
794 static Array<int*> foo
798 @code{foo} can be described as "the static int-pointer user-array", so you get
807 @unnumberedsec Miscellaneous
809 For some tasks, some scripts are supplied, notably creating patches, a
810 mirror of the website, generating the header to put over cc and hh
811 files, doing a release.
815 @node Making patches, , , Top
818 @unnumberedsec Track and distribute your code changes
820 This page documents how to distribute your changes to GNU lilypond
822 We would like to have unified context diffs with full pathnames. A
823 script automating supplied with Lily.
825 Distributing a change normally goes like this:
828 @item make your fix/add your code
829 @item Add changes to CHANGES, and add yourself to Documentation/topdocs/AUTHORS.texi
830 @item generate a patch,
831 @item e-mail your patch to one of the mailing lists
832 gnu-music-discuss@@gnu.org or bug-gnu-music@@gnu.org
835 Please do not send entire files, even if the patch is bigger than the
836 original. A patch makes it clear what is changed, and it won't
837 overwrite previous (not yet released) changes.
839 @unnumberedsec Generating a patch
844 make -C lilypond-x.y.z/ distclean
845 make -C lilypond-x.y.z.NEW/ distclean
846 diff -urN lilypond-x.y.z/ lilypond-x.y.z.NEW/
849 Complicated (but automated) version:
851 In @file{VERSION}, set MY_PATCH_LEVEL:
861 In @file{CHANGES}, enter a summary of changes:
868 Then, from the top of Lily's source tree, type
874 These handy python scripts assume a directory structure which looks
879 lilypond -> lilypond-x.y.z # symlink to development directory
880 lilypond-x.y.z/ # current development
881 patches/ # patches between different releases
882 releases/ # .tar.gz releases
886 (Some scripts also assume this lives in @file{$HOME/usr/src}).
889 @unnumberedsec Applying patches
892 If you're following LilyPond development regularly, you probably want to
893 download just the patch for each subsequent release.
894 After downloading the patch (into the patches directory, of course), simply
899 gzip -dc ../patches/lilypond-0.1.74.diff.gz | patch -p1 -E
903 and don't forget to make automatically generated files:
907 autoconf footnote(patches don't include automatically generated files,
908 i.e. file(configure) and files generated by file(configure).)
914 @node Localisation, , , Top
916 @chapter Localisation - User messages in LilyPond
918 @section Introduction
920 This document provides some guidelines for uniformising user messages.
921 In the absence of other standards, we'll be using these rules when coding
922 for for LilyPond@footnote{
923 In addition to the C++ coding standards that come with Lily
924 }. Hopefully, this can be replaced by general GNU
925 guidelines in the future.
927 Not-preferred messages are marked with @code{+}.
928 By convention, agrammatical examples are marked with @code{*}.
936 Every message to the user should be localised (and thus be marked
937 for localisation). This includes warning and error messages.
940 Don't localise/gettextify:
943 @item @code{programming_error ()}s
944 @item @code{programming_warning ()}s
946 @item output strings (PostScript, TeX)@footnote{
947 This may seem ridiculously obvious, however, makeinfo-3.12s localises
948 output strings. Sending bug report now ---jcn
955 Messages to be localised must be encapsulated in @code{_ (STRING)}
956 or @code{_f (FORMAT, ...)}. Eg:
959 warning (_ ("Need music in a score"));
960 error (_f ("Can't open file: `%s'", file_name));
963 In some rare cases you may need to call @code{gettext ()} by hand.
964 This happens when you pre-define (a list of) string constants for later
965 use. In that case, you'll probably also need to mark these string
966 constants for translation, using @code{_i (STRING)}. The @code{_i}
967 macro is a no-op, it only serves as a marker for @file{xgettext}.
970 char const* messages[] = @{
971 _i ("enable debugging output"),
972 _i ("ignore mudela version"),
979 puts (gettext (messages [i]));
984 @file{flower/getopt-long.cc} and @file{lily/main.cc}.
987 Don't use leading or trailing whitespace in messages.
990 Messages containing a final verb, or a gerund (@code{-ing}-form)
991 always start with a capital. Other (simpler) messages start with
995 The word `foo' is not declared.
997 Not declaring: `foo'.
1001 To avoid having a number of different messages for the same situation,
1002 we'll use quoting like this @code{"message: `%s'"} for all strings.
1003 Numbers are not quoted:
1006 _f ("Can't open file: `%s'", name_str)
1007 _f ("Can't find charater number: %d", i)
1011 Think about translation issues.
1012 In a lot of cases,it's better to translate a whole message.
1013 The english grammar mustn't be imposed on the translator.
1017 _ ("Stem at ") + moment.str () + _(" doen't fit in beam")
1024 _f ("Stem at %s doen't fit in beam", moment.str ())
1028 Split up multi-sentence messages, whenever possible. Instead of
1031 warning (_f ("out of tune! Can't find: `%s', "Key_engraver"));
1033 warning (_f ("Can't find font `%s', loading default",
1041 warning (_ ("out of tune:");
1042 warning (_f ("Can't find: `%s', "Key_engraver"));
1044 warning (_f ("Can't find font: `%s', font_name));
1045 warning (_f ("Loading default font"));
1049 If you must have multiple-sentence messages, use full punctuation.
1050 Use two spaces after end of sentence punctuation.
1051 No punctuation (esp. period) is used at the end of simple messages.
1054 _f ("Non-matching braces in text `%s', adding braces", text)
1055 _ ("Debug output disabled. Compiled with NPRINT.")
1056 _f ("Huh? Not a Request: `%s'. Ignoring.", request)
1060 Don't modularise too much; a lot of words cannot be translated
1062 It's probably safe to treat most occurences of words like
1063 stem, beam, crescendo as separately translatable words.
1066 When translating, it is preferrable to put interesting information
1067 at the end of the message, rather than embedded in the middle.
1068 This especially applies to frequently used messages, even if this
1069 would mean sacrificing a bit of eloquency. This holds for original
1070 messages too, of course.
1073 en: can't open: `foo.ly'
1074 + nl: kan `foo.ly' niet openen (1)
1075 kan niet openen: `foo.ly'* (2)
1076 niet te openen: `foo.ly'* (3)
1079 The first nl message, although gramatically and stylishly correct,
1080 is not friendly for parsing by humans (even if they speak dutch).
1081 I guess we'd prefer something like (2) or (3).
1084 Please don't run make po/po-update with GNU gettext < 0.10.35