patch::: 1.2.9.jcn1

pl 9.jcn1
	- included last Localisation.texi
	- set-lily: de catalog too

diff --git a/CHANGES b/CHANGES
index 6acfa15ad880b0fc8e8c1a785f62bbc4b6cb5ceb..638bacedf40d7cecff57c9441cfec103323e251c 100644 (file)
--- a/CHANGES
+++ b/CHANGES
@@ -1,3 +1,7 @@
+pl 9.jcn1
+       - included last Localisation.texi
+       - set-lily: de catalog too
+

 pl 8.hwn1
        - Erwin Dieterich: german translation.
        - dependency helper funcs simplified.
 pl 8.hwn1
        - Erwin Dieterich: german translation.
        - dependency helper funcs simplified.

diff --git a/Documentation/Localisation.texi b/Documentation/Localisation.texi
index 74506249af6eaf5b52a3f875c443ce54c432428b..672cbf65920118d7bf7881e87d6414e49c451ab9 100644 (file)
--- a/Documentation/Localisation.texi
+++ b/Documentation/Localisation.texi
@@ -7,58 +7,17 @@
 
 @chapter Localisation - User messages in LilyPond
 
 
 @chapter Localisation - User messages in LilyPond
 

-@section ISSUES
+@section Introduction

 
 

-The current default is marked with @code{+}.
+This document provides some guidelines for uniformising user messages.
+In the absence of other standards, we'll be using these rules when coding
+for for LilyPond@footnote{
+In addition to the C++ coding standards that come with Lily
+}.  Hopefully, this can be replaced by general GNU
+guidelines in the future.  

 
 

-@itemize @bullet
-
-@item
-How to do two-part messages like these?  Better spread over multiple lines?
-@example
-    warning (_f ("out of tune!  Can't find: `%s\', "Key_engraver"));
-or
-+   warning (_ ("out of tune:");
-    warning (_f ("Can't find: `%s\', "Key_engraver"));
-
-    warning (_f ("Can't find font `%s', loading default font", name.ch_C ()));
-or
-+   warning (_f ("Can't find font: `%s', name.ch_C ()));
-    warning (_f ("Loading default font"));
-@end example
-
-@item
-How to do messages with punctuation:
-@example
-Logical:
-+   warning ( _("Huh?  Not a Request: `%s'", s);
-Guidelines say:
-    warning ( _("huh?  not a Request: `%s'", s);
-@end example
-
-@item
-No punctuation (esp. period) at end of message.
-
-But what about multiple-sentence, or full-sentence (including other
-punctuation) messages?
-@example
-+   _ ("Debug output disabled.  Compiled with NPRINT.")
-+   _ ("Non-matching braces in text `%s', adding braces")
-@end example
-
-@item
-@example
-    en: can't open: `foo.ly'
-    nl: kan `foo.ly' niet openen (1)
-+   kan niet openen: `foo.ly'*   (2)
-    niet te openen: `foo.ly'*    (3)
-@end example
-
-The first nl message, although gramatically and stylishly correct,
-is not friendly for parsing by humans (even if they speak dutch).
-I guess we'd prefer something like (2) or (3)...
-
-@end itemize
+Not-preferred messages are marked with @code{+}.
+By convention, agrammatical examples are marked with @code{*}.

 
 
 @section Guidelines
 
 
 @section Guidelines


@@ -66,37 +25,64 @@ I guess we'd prefer something like (2) or (3)...
 @itemize @bullet
 
 @item
 @itemize @bullet
 
 @item

-Every user message should be localised.
+Every message to the user should be localised (and thus be marked
+for localisation).  This includes warning and error messages.

 
 @item
 Don't localise/gettextify:
 
 @item
 Don't localise/gettextify:

+

 @itemize @minus
 @item @code{programming_error ()}s
 @item @code{programming_warning ()}s
 @item debug strings
 @itemize @minus
 @item @code{programming_error ()}s
 @item @code{programming_warning ()}s
 @item debug strings

-@item output strings (PostScript, TeX)
+@item output strings (PostScript, TeX)@footnote{
+This may seem ridiculously obvious, however, makeinfo-3.12s localises
+output strings.  Sending bug report now ---jcn
+}

 @end itemize
 
 @end itemize
 

+
+

 @item
 @item

-Strings to be localised must be encapsulated in @code{_ (STRING)}
+Messages to be localised must be encapsulated in @code{_ (STRING)}

 or @code{_f (FORMAT, ...)}.  Eg:
 or @code{_f (FORMAT, ...)}.  Eg:

+

 @example
 warning (_ ("Need music in a score"));
 @example
 warning (_ ("Need music in a score"));

-error (_f ("Can't open file: `%s'"));
+error (_f ("Can't open file: `%s'", file_name));

 @end example
 
 @end example
 

-Only in very rare cases you may need to call @code{gettext ()} by hand.
-In that case, you'll probably also need to mark some string constants for
-translation, using @code{_i (STRING)}.  See @file{flower/getopt-long.cc}
-and @file{lily/main.cc}.
+In some rare cases you may need to call @code{gettext ()} by hand.
+This happens when you pre-define (a list of) string constants for later
+use.  In that case, you'll probably also need to mark these string
+constants for translation, using @code{_i (STRING)}.  The @code{_i}
+macro is a no-op, it only serves as a marker for @file{xgettext}.
+
+@example
+char const* messages[] = @{
+  _i ("enable debugging output"),
+  _i ("ignore mudela version"),
+  0
+@};
+
+void
+foo (int i)
+@{
+  puts (gettext (messages [i]));
+@}
+@end example
+
+See also
+@file{flower/getopt-long.cc} and @file{lily/main.cc}.

 
 @item
 
 @item

-Don't use leading or trailing whitespace in strings.
+Don't use leading or trailing whitespace in messages.

 
 @item
 Messages containing a final verb, or a gerund (@code{-ing}-form)
 always start with a capital.  Other (simpler) messages start with
 a lowercase letter:
 
 @item
 Messages containing a final verb, or a gerund (@code{-ing}-form)
 always start with a capital.  Other (simpler) messages start with
 a lowercase letter:

+

 @example
 The word `foo' is not declared.
 `foo': not declared.
 @example
 The word `foo' is not declared.
 `foo': not declared.


@@ -107,6 +93,7 @@ Not declaring: `foo'.
 To avoid having a number of different messages for the same situation,
 we'll use quoting like this @code{"message: `%s'"} for all strings.
 Numbers are not quoted:
 To avoid having a number of different messages for the same situation,
 we'll use quoting like this @code{"message: `%s'"} for all strings.
 Numbers are not quoted:

+

 @example
 _f ("Can't open file: `%s'", name_str)
 _f ("Can't find charater number: %d", i)
 @example
 _f ("Can't open file: `%s'", name_str)
 _f ("Can't find charater number: %d", i)


@@ -117,19 +104,48 @@ Think about translation issues.
 In a lot of cases,it's better to translate a whole message.
 The english grammar mustn't be imposed on the translator.
 So, iso
 In a lot of cases,it's better to translate a whole message.
 The english grammar mustn't be imposed on the translator.
 So, iso

+

 @example
 _ ("Stem at ") + moment.str () + _(" doen't fit in beam")
 @end example
 @example
 _ ("Stem at ") + moment.str () + _(" doen't fit in beam")
 @end example

+

 @noindent
 have
 @noindent
 have

+

 @example
 _f ("Stem at %s doen't fit in beam", moment.str ())
 @end example
 
 @item
 @example
 _f ("Stem at %s doen't fit in beam", moment.str ())
 @end example
 
 @item

-Use two spaces after end of sentence punctuation:
+Split up multi-sentence messages, whenever possible.  Instead of
+
+@example
+warning (_f ("out of tune!  Can't find: `%s', "Key_engraver"));
+
+warning (_f ("Can't find font `%s', loading default", 
+             font_name));
+@end example
+
+@noindent
+rather say:
+
+@example
+warning (_ ("out of tune:");
+warning (_f ("Can't find: `%s', "Key_engraver"));
+
+warning (_f ("Can't find font: `%s', font_name));
+warning (_f ("Loading default font"));
+@end example
+
+@item
+If you must have multiple-sentence messages, use full punctuation.
+Use two spaces after end of sentence punctuation.
+No punctuation (esp. period) is used at the end of simple messages.
+

 @example
 @example

-_ ("Huh?  Not a Request")
+   _f ("Non-matching braces in text `%s', adding braces", text)
+   _ ("Debug output disabled.  Compiled with NPRINT.")
+   _f ("Huh?  Not a Request: `%s'.  Ignoring.", request)

 @end example
 
 @item
 @end example
 
 @item


@@ -138,6 +154,24 @@ without context.
 It's probably safe to treat most occurences of words like
 stem, beam, crescendo as separately translatable words.
 
 It's probably safe to treat most occurences of words like
 stem, beam, crescendo as separately translatable words.
 

+@item
+When translating, it is preferrable to put interesting information 
+at the end of the message, rather than embedded in the middle.
+This especially applies to frequently used messages, even if this
+would mean sacrificing a bit of eloquency.  This holds for original
+messages too, of course.
+
+@example
+    en: can't open: `foo.ly'
++   nl: kan `foo.ly' niet openen (1)
+    kan niet openen: `foo.ly'*   (2)
+    niet te openen: `foo.ly'*    (3)
+@end example
+
+The first nl message, although gramatically and stylishly correct,
+is not friendly for parsing by humans (even if they speak dutch).
+I guess we'd prefer something like (2) or (3).
+

 @item
 Please don't run make po/po-update with GNU gettext < 0.10.35
 
 @item
 Please don't run make po/po-update with GNU gettext < 0.10.35
 

diff --git a/VERSION b/VERSION
index 8dc760251ca40669c92ce14c64342bf07cb66b5e..eaef5028d4274f86e4b046740e620d488e427b5b 100644 (file)
--- a/VERSION
+++ b/VERSION
@@ -2,7 +2,7 @@ PACKAGE_NAME=LilyPond
 MAJOR_VERSION=1
 MINOR_VERSION=2
 PATCH_LEVEL=9
 MAJOR_VERSION=1
 MINOR_VERSION=2
 PATCH_LEVEL=9

-MY_PATCH_LEVEL=
+MY_PATCH_LEVEL=jcn1

 
 # use the above to send patches: MY_PATCH_LEVEL is always empty for a
 # released version.
 
 # use the above to send patches: MY_PATCH_LEVEL is always empty for a
 # released version.

diff --git a/buildscripts/set-lily.sh b/buildscripts/set-lily.sh
index 1c3e20a79b1f92c38cfecf4ded07ab6ae5fd5017..f0de4b2a01c725f307cfed8b3bd2beeea6ae6fb0 100755 (executable)
--- a/buildscripts/set-lily.sh
+++ b/buildscripts/set-lily.sh
@@ -61,7 +61,7 @@ showln -sf $sources/lilypond $prefix/share/lilypond
 
 
 BUILDDIR=`pwd`
 
 
 BUILDDIR=`pwd`

-LOCALES="it nl"
+LOCALES="de it nl"

 for i in $LOCALES; do
        dir=$BUILDDIR/share/locale/$i/LC_MESSAGES
        if test ! -x $dir ; then
 for i in $LOCALES; do
        dir=$BUILDDIR/share/locale/$i/LC_MESSAGES
        if test ! -x $dir ; then