Re: Doc: NR Moved Appendix C to CG (issue 6948070)
https://codereview.appspot.com/6948070/diff/3001/Documentation/contributor.texi File Documentation/contributor.texi (right): https://codereview.appspot.com/6948070/diff/3001/Documentation/contributor.texi#newcode70 Documentation/contributor.texi:70: On 2012/12/25 08:05:45, Trevor Daniels wrote: Drop the blank line Done. https://codereview.appspot.com/6948070/diff/3001/Documentation/notation.tely File Documentation/notation.tely (left): https://codereview.appspot.com/6948070/diff/3001/Documentation/notation.tely#oldcode88 Documentation/notation.tely:88: @node LilyPond grammar On 2012/12/25 08:05:45, Trevor Daniels wrote: You'll need to find and drop the menu item corresponding to this node, else the docs won't build. Done. https://codereview.appspot.com/6948070/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR Moved Appendix C to CG (issue 6948070)
LGTM, apart from a couple of nitpicks which
I missed earlier. No need to post a new
patch-set.
https://codereview.appspot.com/6948070/diff/6001/Documentation/notation/notation-appendices.itely
File Documentation/notation/notation-appendices.itely (left):
https://codereview.appspot.com/6948070/diff/6001/Documentation/notation/notation-appendices.itely#oldcode1545
Documentation/notation/notation-appendices.itely:1545: (BNF) in
@ref{LilyPond grammar}. This file is used to build the
Our standard is two spaces after full stops in
mono-spaced text.
https://codereview.appspot.com/6948070/diff/6001/Documentation/notation/notation-appendices.itely
File Documentation/notation/notation-appendices.itely (right):
https://codereview.appspot.com/6948070/diff/6001/Documentation/notation/notation-appendices.itely#newcode1534
Documentation/notation/notation-appendices.itely:1534: @cindex grammar,
for LilyPond
I think the comma is wrong here. grammar for Lilypond
is perfectly sensible.
https://codereview.appspot.com/6948070/diff/6001/Documentation/notation/notation-appendices.itely#newcode1547
Documentation/notation/notation-appendices.itely:1547: parser during the
program build by the parser generator, Bison. It is
Same here.
https://codereview.appspot.com/6948070/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: CG Clarifying about Examples with overrides (issue 7013043)
I'm happy with this with the change below. The formatting of this section (and the CG in general) has never been systematically reviewed, so there's no point in being strict about it here. The text is understandable even though it doesn't fit into the surrounding material in the best possible way. https://codereview.appspot.com/7013043/diff/3003/Documentation/contributor/doc-work.itexi File Documentation/contributor/doc-work.itexi (right): https://codereview.appspot.com/7013043/diff/3003/Documentation/contributor/doc-work.itexi#newcode149 Documentation/contributor/doc-work.itexi:149: @contributions that contain examples using overrides or tweaks Not sure what you intended here. Does the @ mean there is an omitted texinfo command? Maybe this line should just be deleted. https://codereview.appspot.com/7013043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: CG Clarifying about Examples with overrides (issue 7013043)
https://codereview.appspot.com/7013043/diff/1/Documentation/contributor/doc-work.itexi File Documentation/contributor/doc-work.itexi (right): https://codereview.appspot.com/7013043/diff/1/Documentation/contributor/doc-work.itexi#newcode155 Documentation/contributor/doc-work.itexi:155: The correct way to add [changes like this] to the documentation is to On 2012/12/26 07:32:01, J_lowe wrote: On 2012/12/25 09:10:01, bealingsplayfordnews wrote: Why the [] ? This is a standard way to to clarify the antecedent. Also you will see it used to denote missing text [ ... ] or more commonly to denote a mistake or inaccuracy in a quote without it being attributed to the author of the text it is being quoted in (i.e '[sic]'). Anyway, enough of that, I have rewritten the sentence. Actually, the _only_ usage of [...] I know in text passages is an editorial addition, signifying material added by someone different from the original author. In particular, [sic] means as the editor, I am perfectly aware that this is wrong, thank you very much. But since this is a literal quotation, I am not at liberty correcting it. Another frequent use is to make explicit what object a pronoun in a quoted section is referring to if the scope of the quotation does not allow deducing it. Also, when only sentence parts are quoted and the result would be ungrammatical, editorial insertions used for creating a grammatical sentence again will be marked with [...]. https://codereview.appspot.com/7013043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: CG Clarifying about Examples with overrides (issue 7013043)
hello, On 26 December 2012 11:00, d...@gnu.org wrote: https://codereview.appspot.com/7013043/diff/1/Documentation/contributor/doc-work.itexi File Documentation/contributor/doc-work.itexi (right): https://codereview.appspot.com/7013043/diff/1/Documentation/contributor/doc-work.itexi#newcode155 Documentation/contributor/doc-work.itexi:155: The correct way to add [changes like this] to the documentation is to On 2012/12/26 07:32:01, J_lowe wrote: On 2012/12/25 09:10:01, bealingsplayfordnews wrote: Why the [] ? This is a standard way to to clarify the antecedent. Also you will see it used to denote missing text [ ... ] or more commonly to denote a mistake or inaccuracy in a quote without it being attributed to the author of the text it is being quoted in (i.e '[sic]'). Anyway, enough of that, I have rewritten the sentence. Actually, the _only_ usage of [...] I know in text passages is an editorial addition, signifying material added by someone different from the original author. In particular, [sic] means as the editor, I am perfectly aware that this is wrong, thank you very much. But since this is a literal quotation, I am not at liberty correcting it. Another frequent use is to make explicit what object a pronoun in a quoted section is referring to if the scope of the quotation does not allow deducing it. That's the 'antecedent' thingy I referred to. Also, when only sentence parts are quoted and the result would be ungrammatical, editorial insertions used for creating a grammatical sentence again will be marked with [...]. I thought I might get responses like this, which is why I rewrote the sentence. Life is too short. Merry Christmas ;) James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: CG Clarifying about Examples with overrides (issue 7013043)
https://codereview.appspot.com/7013043/diff/3003/Documentation/contributor/doc-work.itexi File Documentation/contributor/doc-work.itexi (right): https://codereview.appspot.com/7013043/diff/3003/Documentation/contributor/doc-work.itexi#newcode149 Documentation/contributor/doc-work.itexi:149: @contributions that contain examples using overrides or tweaks On 2012/12/26 10:27:39, Trevor Daniels wrote: Not sure what you intended here. Does the @ mean there is an omitted texinfo command? Maybe this line should just be deleted. No that's a typo. :( It should be @subheading contributions that contain... I didn't get a chance to test this patch yet. Thanks for spotting. https://codereview.appspot.com/7013043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: CG Clarifying about Examples with overrides (issue 7013043)
James pkx1...@gmail.com writes: On 26 December 2012 11:00, d...@gnu.org wrote: Documentation/contributor/doc-work.itexi:155: The correct way to add [changes like this] to the documentation is to Why the [] ? This is a standard way to to clarify the antecedent. Another frequent use is to make explicit what object a pronoun in a quoted section is referring to if the scope of the quotation does not allow deducing it. That's the 'antecedent' thingy I referred to. Well, ok, but again I know it only when something is inserted into a quotation, where original author and editor differ. Our manual pretends to be a single text, so one would use () instead of [] for clarifying interjections. I thought I might get responses like this, which is why I rewrote the sentence. Smart move. Life is too short. But at least it is getting longer all the time. Merry Christmas The same to you and many more. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: CG Clarifying about Examples with overrides (issue 7013043)
https://codereview.appspot.com/7013043/diff/3003/Documentation/contributor/doc-work.itexi
File Documentation/contributor/doc-work.itexi (right):
https://codereview.appspot.com/7013043/diff/3003/Documentation/contributor/doc-work.itexi#newcode158
Documentation/contributor/doc-work.itexi:158: @ref{Introduction to LSR}.
Thanks for the update. I still think it's worth a simple reminder here:
'Dont' forget to tag the snippet with docs'.
https://codereview.appspot.com/7013043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR Moved Appendix C to CG (issue 6948070)
https://codereview.appspot.com/6948070/diff/6001/Documentation/notation/notation-appendices.itely
File Documentation/notation/notation-appendices.itely (left):
https://codereview.appspot.com/6948070/diff/6001/Documentation/notation/notation-appendices.itely#oldcode1545
Documentation/notation/notation-appendices.itely:1545: (BNF) in
@ref{LilyPond grammar}. This file is used to build the
On 2012/12/26 10:09:45, Trevor Daniels wrote:
Our standard is two spaces after full stops in
mono-spaced text.
Done.
https://codereview.appspot.com/6948070/diff/6001/Documentation/notation/notation-appendices.itely
File Documentation/notation/notation-appendices.itely (right):
https://codereview.appspot.com/6948070/diff/6001/Documentation/notation/notation-appendices.itely#newcode1534
Documentation/notation/notation-appendices.itely:1534: @cindex grammar,
for LilyPond
On 2012/12/26 10:09:45, Trevor Daniels wrote:
I think the comma is wrong here. grammar for Lilypond
is perfectly sensible.
Done.
https://codereview.appspot.com/6948070/diff/6001/Documentation/notation/notation-appendices.itely#newcode1547
Documentation/notation/notation-appendices.itely:1547: parser during the
program build by the parser generator, Bison. It is
On 2012/12/26 10:09:45, Trevor Daniels wrote:
Same here.
Done.
https://codereview.appspot.com/6948070/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: CG Clarifying about Examples with overrides (issue 7013043)
Hello,
On 26 December 2012 12:52, philehol...@googlemail.com wrote:
https://codereview.appspot.com/7013043/diff/3003/Documentation/contributor/doc-work.itexi
File Documentation/contributor/doc-work.itexi (right):
https://codereview.appspot.com/7013043/diff/3003/Documentation/contributor/doc-work.itexi#newcode158
Documentation/contributor/doc-work.itexi:158: @ref{Introduction to LSR}.
Thanks for the update. I still think it's worth a simple reminder here:
'Dont' forget to tag the snippet with docs'.
https://codereview.appspot.com/7013043/
Is there any case where a snippet would not have the docs tag?
James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: CG Clarifying about Examples with overrides (issue 7013043)
On 2012/12/26 13:15:05, J_lowe wrote: Is there any case where a snippet would not have the docs tag? James Some statistic from the last LSR-update: The 2.12.3-LSR contained 645 snippets. 291 were tagged docs. There are many LSR-snippets showing nice code/features, but not all of them are worth to be integrated in /Documentation/snippets for different reasons. OTOH, some snippets from the docs should also be removed, imho. I think someone should review the tags of each single snippet. Perhaps during the next upgrade. https://codereview.appspot.com/7013043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: CG Clarifying about Examples with overrides (issue 7013043)
- Original Message -
From: James pkx1...@gmail.com
To: pkx1...@gmail.com; tdanielsmu...@googlemail.com;
philehol...@googlemail.com; d...@gnu.org; lilypond-devel@gnu.org;
re...@codereview-hr.appspotmail.com
Sent: Wednesday, December 26, 2012 1:15 PM
Subject: Re: Doc: CG Clarifying about Examples with overrides (issue
7013043)
Hello,
On 26 December 2012 12:52, philehol...@googlemail.com wrote:
https://codereview.appspot.com/7013043/diff/3003/Documentation/contributor/doc-work.itexi
File Documentation/contributor/doc-work.itexi (right):
https://codereview.appspot.com/7013043/diff/3003/Documentation/contributor/doc-work.itexi#newcode158
Documentation/contributor/doc-work.itexi:158: @ref{Introduction to LSR}.
Thanks for the update. I still think it's worth a simple reminder here:
'Dont' forget to tag the snippet with docs'.
https://codereview.appspot.com/7013043/
Is there any case where a snippet would not have the docs tag?
James
Yes. Probably about 80% of them don't (I could work it out, but CBA at
present). These are for snippets which are viewable/searchable on the LSR,
but not as part of the documentation. Generally, we scrutinise those tagged
with docs more carefully for syntax and formatting. If they're not tagged
with docs, we're more lenient.
If they don't have this tag, they're not exported to the snippets/docs
tarball and won't appear in snippets or be available for doc writers. And
since the process is 1. contributor submits; 2. LSR meister approves; 3.
Tarball is grabbed; 4. Makelsr is run; 5. Git is updated; the time between
1 and 5 can be considerable, and so they effectively get lost.
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Question re looking up settings in current \midi block.
First of all, a very Merry Christmas to you all.
Unfortunately I've had to spend the holidays in hospital, but I'm now a
much happier bunny now I have my notebook and have sorted out a mobile
broadband link.
I'm trying to prototype something so we can specify names and/or
suffixes for midi files and would like to see if I can add property
checks for things in the \midi block like
\midi {
filename = Coronation-Anthem
file-suffix = Zadok-the-Priest}
}
I know ly:output-def-lookup is my friend, but how do I get hold of the
currently active midi block so I can look up the property?
Sorry if this seems an obvious question, and I'd probably get the answer
if I was at home, but I'm out on a limb a bit here.
Thanks in advance for your help,
Cheers,
Ian Hulin
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New Catalan PO file for 'lilypond' (version 2.15.95)
Le 25/12/2012 23:30, Francisco Vila disait : El 25/12/2012 19:31, Federico Bruni escribió: Il 25/12/2012 19:23, David Kastrup ha scritto: What actually worries me is: All other PO files for your package are available in: http://translationproject.org/latest/lilypond/ And this shows: The current template for this domain is lilypond-2.15.95.pot which sounds seriously outdated. I think that it's ok. We usually update this file just before the release of a new stable. As you can see here: http://translationproject.org/domain/lilypond.html translated files are always some development version and the minor number is quite high (just before the release of stable). I think that it's up to Jean-Charles uploading the new pot file. Then we translators get the notification and update the file for the coming release. As a matter of fact, I'm trying to see how to get rid of those entries containing a full personal path in the pot file (parser.yy and lexer.yy get doubled). It seems to be due to the out of source tree build and how make and gettext deal with recursive and upwards relative directories. Since I'm not a programmer neither very comfortable with all the building machinery we have... with just 1.5 hour a day of diving in this soup. Secondly I think to add to the file names their path relatively to $(configure-srcdir), what might help to find the source more evidently than choosing between flower, lily, ly, python, scm or scripts. As for how can we stop it, I think no matter how frequently this translator uploads new files, we can apply once or two times a release, like we do in other languages, especially before a stable release. I applied it to git, is there something more to do with a new language? I think that the Catalan translator (Walter Garcia-Fontes) makes regular commits to the FTP. If you have a look at the LP's domain page, his last update from Xmas noon reached 279 translated chains, compared to the 189 that Paco pushed on the translation branch. Might be should we wait that he reaches a certain percentage before uploading again, or sending him a mail asking him how he feels about it? Cheer, and beware your lever with all the good things we eat and drink these days! Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
New Catalan PO file for 'lilypond' (version 2.15.95)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'lilypond' has been submitted by the Catalan team of translators. The file is available at: http://translationproject.org/latest/lilypond/ca.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: http://translationproject.org/latest/lilypond/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/lilypond.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: CG Clarifying about Examples with overrides (issue 7013043)
LGTM https://codereview.appspot.com/7013043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Rewrite of Midi.c in Python (issue 7016046)
Reviewers: benrg, Message: Actually, I didn't rewrite it - as the comment above suggests - this was from Ben Rudiak-Gould. I am helping him at least get some discussion review of his code submission. This patch has not been patchy-tested and I have just included everything (i.e. also the .mid files) that were provided by Ben. I have put them in the place that I thought might be appropriate but I don't really know if this is right or not. Description: Rewrite of Midi.c in Python I rewrote midi.c in Python and tested it on the largest midi file in IMSLP [1]. On my laptop it takes about 200 ms instead of 50 ms to load the file, but that's a small fraction of midi2ly's four-second runtime, and there are a lot of optimizations that can be done in midi2ly itself. (For example, memoizing the creation of Duration objects saves about 500 ms.) I think getting rid of the sole occupant of usr/lib/lilypond/current/python is worth it. Please review this at https://codereview.appspot.com/7016046/ Affected files: A scripts/midi.py A scripts/test-all-valid-sequences.mid A scripts/test-error-empty.mid A scripts/test-error-initial-repeat.mid A scripts/test-error-mthd-bad-magic.mid A scripts/test-error-mthd-length-5.mid A scripts/test-error-mthd-truncated-1.mid A scripts/test-error-mthd-truncated-2.mid A scripts/test-error-mthd-truncated-3.mid A scripts/test-error-mtrk-bad-magic.mid A scripts/test-error-mtrk-truncated-1.mid A scripts/test-error-mtrk-truncated-2.mid A scripts/test-error-mtrk-truncated-3.mid ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Report unterminated ties hanging at end of input (issue 7019044)
Reviewers: zefram_fysh.org,
Message:
Issue 3062 - patch created by 'Zefram', but submitted by James
Description:
Report unterminated ties hanging at end of input
Issue 3062
LP doesn't report unterminated ties that are left hanging at the end
of input. Compare { a2~ r2 } (which warns) with { a2~ } (which
doesn't).
Contrast against the handling of slurs, where both { a2( r2 } and { a2(
}
warn.
Please review this at https://codereview.appspot.com/7019044/
Affected files:
M lily/tie-engraver.cc
Index: lily/tie-engraver.cc
diff --git a/lily/tie-engraver.cc b/lily/tie-engraver.cc
index
07eb9196c78101a2c58ca5d4b1dabbc77cef9ad8..aa8544bcca0a05fc5a13090f82f6619f09678134
100644
--- a/lily/tie-engraver.cc
+++ b/lily/tie-engraver.cc
@@ -88,6 +88,7 @@ protected:
void typeset_tie (Grob *);
void report_unterminated_tie (Head_event_tuple const );
bool has_autosplit_end (Stream_event *event);
+ virtual void finalize ();
public:
TRANSLATOR_DECLARATIONS (Tie_engraver);
};
@@ -131,6 +132,14 @@ Tie_engraver::has_autosplit_end (Stream_event *event)
}
void
+Tie_engraver::finalize ()
+{
+ vectorHead_event_tuple::iterator it = heads_to_tie_.begin ();
+ for (; it heads_to_tie_.end (); it++)
+report_unterminated_tie (*it);
+}
+
+void
Tie_engraver::process_music ()
{
bool busy = event_;
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
canonicalise notional octave of tonic (issue 7019045)
Reviewers: zefram_fysh.org, Message: Patch submitted on behalf of zef...@fysh.org Description: canonicalise notional octave of tonic Nothing deliberately looks at the octave part of the pitch object storing the tonic of a key-change event; it's not really a meaningful concept. But comparison with equal? sees the octave, so internal_event_assignment() reckoned two key changes differing only in this meaningless field to be different, and therefore not permitted to occur at the same time. This triggered false warnings of two simultaneous key-change events when two instruments sharing a staff differ in the transposition used in their music source. To fix this, always set the octave part of the tonic pitch to the same value. This is done when transposing, and since \key operates by invoking transposition this is the only place that needs to canonicalise. The canonical octave is number -1; that is, the octave obtained by a note name with no octave suffix, and so the octave that most commonly occurred under the non-canonicalising system. Please review this at https://codereview.appspot.com/7019045/ Affected files: M lily/music.cc Index: lily/music.cc diff --git a/lily/music.cc b/lily/music.cc index 7a38d7af41d84851151b65e2c5bcbdaa4cc4e010..be1fb2ed131cb0451ab4e373db8e46d52dd9982a 100644 --- a/lily/music.cc +++ b/lily/music.cc @@ -226,6 +226,10 @@ transpose_mutable (SCM alist, Pitch delta) transposed = transposed.normalized (); } + if (prop == ly_symbol2scm (tonic)) +transposed = Pitch (-1, transposed.get_notename (), +transposed.get_alteration ()); + new_val = transposed.smobbed_copy (); } else if (prop == ly_symbol2scm (element)) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 3063 (issue 7017045)
Reviewers: zefram_fysh.org, Message: Submitted for zef...@fysh.org by James Description: Issue 3063 articulate grace notes with time stealing This change makes \articulate handle grace notes itself, rendering them to ordinary notes. There are a couple of tweakable parameters controlling the rendering. This prevents \articulate causing the many going back in MIDI time errors that it used to. (Inserting a short rest after each note makes it way too easy for following grace notes to need to steal more time from the preceding rhythmic event than it has.) In fact, when such errors occur in the absence of \articulate, \articulate can now fix them. Please review this at https://codereview.appspot.com/7017045/ Affected files: M ly/articulate.ly ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue 3049: Parser outputs Lyric events for illegal note names (issue 7017044)
LGTM. https://codereview.appspot.com/7017044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Dual license the files under mf/ using OFL. (issue 6970046)
Hanwen - this has now 'push' status - in case you are not following the tracker http://code.google.com/p/lilypond/issues/detail?id=3044 https://codereview.appspot.com/6970046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
New Catalan PO file for 'lilypond' (version 2.15.95)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'lilypond' has been submitted by the Catalan team of translators. The file is available at: http://translationproject.org/latest/lilypond/ca.po (We can arrange things so that in the future such files are automatically e-mailed to you when they arrive. Ask at the address below if you want this.) All other PO files for your package are available in: http://translationproject.org/latest/lilypond/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/lilypond.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. coordina...@translationproject.org ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
