Re: Add alias in Spanish for espanol note names language (issue 6811060)
Hello. Am I countdowned or rather needsworked? Thanks. https://codereview.appspot.com/6811060/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add alias in Spanish for espanol note names language (issue 6811060)
https://codereview.appspot.com/6811060/diff/4001/scm/define-note-names.scm File scm/define-note-names.scm (right): https://codereview.appspot.com/6811060/diff/4001/scm/define-note-names.scm#newcode964 scm/define-note-names.scm:964: (append language-pitch-names I will use two-spaces indenting here. Emacs indent-region inserted the tabs. https://codereview.appspot.com/6811060/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add alias in Spanish for espanol note names language (issue 6811060)
http://codereview.appspot.com/6811060/diff/4001/scm/define-note-names.scm File scm/define-note-names.scm (right): http://codereview.appspot.com/6811060/diff/4001/scm/define-note-names.scm#newcode961 scm/define-note-names.scm:961: ;; add two native utf-8 alisases. Pairs obey cp-like order: '(old new) It should be 'aliases', of course. http://codereview.appspot.com/6811060/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Spelling fixes in comments and documentation (issue 5562043)
All these changes are very minor and harmless. Changes in translated files lay on English comments. http://codereview.appspot.com/5562043/diff/1/Documentation/po/cs.po File Documentation/po/cs.po (right): http://codereview.appspot.com/5562043/diff/1/Documentation/po/cs.po#newcode10524 Documentation/po/cs.po:10524: #~ msgstr "Dudelsack-Definitionen" Do not bother about spelling of deprecated strings. Harmless, but useless. http://codereview.appspot.com/5562043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Undefined references in translated manuals (issue 2220). (issue 5539052)
Some of these changes are already pushed. I could kiss myself.
http://codereview.appspot.com/5539052/diff/1/Documentation/es/extending/scheme-tutorial.itely
File Documentation/es/extending/scheme-tutorial.itely (right):
http://codereview.appspot.com/5539052/diff/1/Documentation/es/extending/scheme-tutorial.itely#newcode888
Documentation/es/extending/scheme-tutorial.itely:888: usaríamos
@ref{Funciones de Scheme vacías}, o lo almacenaríamos en un
This change is already pushed in the lilypond/translation branch, commit
30d5b6092
http://codereview.appspot.com/5539052/diff/1/Documentation/es/notation/rhythms.itely
File Documentation/es/notation/rhythms.itely (right):
http://codereview.appspot.com/5539052/diff/1/Documentation/es/notation/rhythms.itely#newcode3120
Documentation/es/notation/rhythms.itely:3120: ensayo, consulte
@ref{Indicaciones de texto}. Para un control más
My commit 30d5b60 includes a change here as well to fix a wrong xref
(not sure if it was a broken xref).
http://codereview.appspot.com/5539052/diff/1/Documentation/es/notation/rhythms.itely#newcode3122
Documentation/es/notation/rhythms.itely:3122: @ref{Alineación de
objetos}.
This is new, I missed it.
http://codereview.appspot.com/5539052/diff/1/Documentation/es/notation/rhythms.itely#newcode3129
Documentation/es/notation/rhythms.itely:3129: @ref{Alineación de
objetos}.
Already pushed. See 30d5b609 in lilypond/translation branch. I guess
Git will smartly merge both change sets.
http://codereview.appspot.com/5539052/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 905: Gracefully ignore UTF-8 BOM in the middle of a file (issue 4908043)
On 2011/08/15 18:14:21, lemzwerg wrote: Could you please tell me what this patch is good for? A BOM not at the beginning of a file is no longer a BOM... I don't oppose to emitting a warning if U+FEFF is encountered, and we subsequently ignore it (since its use as zero width no-break space is deprecated), but only within strings... What am I missing? The BOM is invisible and you can not be sure whether it is inside a string or anywhere else. In my experience, it is very common that Windows users create/open/modify lilypond input files with the Notepad accessory, maybe inserting new charachters at the very beginning, thus inadvertently moving the BOM and obtaining failed compiles. Moreover, they are not able to fix the file because the BOM is invisible. So, the patch would be very useful in that makes the BOM transparent for the lilypond syntax and the user could forget it at last. http://codereview.appspot.com/4908043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Include and document the Articulate script by Peter Chubb. (issue4277067)
Uploading third patch.
http://codereview.appspot.com/4277067/diff/5001/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
http://codereview.appspot.com/4277067/diff/5001/Documentation/notation/input.itely#newcode1956
Documentation/notation/input.itely:1956: except those enabled by
@ref{The Articulate script} when it is used:
On 2011/04/05 02:41:19, Graham Percival wrote:
replace with
unless you use @ref{The Articulate script}:
But that's not completely true. Not all the following items are enabled
by Articulate. Done anyway
http://codereview.appspot.com/4277067/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Include and document the Articulate script by Peter Chubb. (issue4277067)
New patch coming soon after license update.
http://codereview.appspot.com/4277067/diff/1/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
http://codereview.appspot.com/4277067/diff/1/Documentation/notation/input.itely#newcode1690
Documentation/notation/input.itely:1690: more realistic MIDI output is
available by means of the Articulate
On 2011/03/20 17:30:46, Graham Percival wrote:
could "the Articulate script" be a @ref{} ?
Done.
http://codereview.appspot.com/4277067/diff/1/Documentation/notation/input.itely#newcode2307
Documentation/notation/input.itely:2307: @unnumberedsubsubsec Using the
Articulate script
On 2011/03/20 17:30:46, Graham Percival wrote:
IMO, the @unnumberedsubsubsec doesn't add anything. I suggest
omitting this
line entirely.
If you really really want that line there for some reason, then please
add a
@node right above it, to match the doc policy.
I agree it is unnecessary. I added no @nodes because previous sections
@unnumberedsubsubsec Unsupported in MIDI etc don't have a @node.
http://codereview.appspot.com/4277067/diff/1/Documentation/notation/input.itely#newcode2316
Documentation/notation/input.itely:2316: and in the @code{\score}
section do
On 2011/03/20 17:30:46, Graham Percival wrote:
I do not believe that you "have to" include the \unfoldRepeats
section. Could
you just change this to:
To create a MIDI file with all repeats played, add this to your
\score:
Here, I just copied the lines provided by Peter. \articulate is needed
AFAIK, \unfoldRepeats not essential but still could be for trills.
http://codereview.appspot.com/4277067/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: translations: manually update syntax (1358) (issue3092041)
Graham: here are my comments. I will not close the issue until all other
languages are revised, but for German it is done. Thanks
http://codereview.appspot.com/3092041/diff/1/Documentation/de/notation/fretted-strings.itely
File Documentation/de/notation/fretted-strings.itely (right):
http://codereview.appspot.com/3092041/diff/1/Documentation/de/notation/fretted-strings.itely#newcode11
Documentation/de/notation/fretted-strings.itely:11: @c \version
"2.13.39"
Original has 2.13.36 here; while this is technically correct,
translators prefer to have these strings in sync. The --to=2.13.36
option does this.
http://codereview.appspot.com/3092041/diff/1/Documentation/de/notation/staff.itely
File Documentation/de/notation/staff.itely (right):
http://codereview.appspot.com/3092041/diff/1/Documentation/de/notation/staff.itely#newcode682
Documentation/de/notation/staff.itely:682: Man kann auch den
@code{\Staff \RemoveEmptyStaves}-Befehl einsetzen,
Gernam translator already did this and all other changes on this file on
623a785573, dated 2010-11-06, the commit was entitled as an update, so
maybe the patch is redundant for this file at least.
http://codereview.appspot.com/3092041/diff/1/Documentation/de/notation/text.itely
File Documentation/de/notation/text.itely (right):
http://codereview.appspot.com/3092041/diff/1/Documentation/de/notation/text.itely#newcode1280
Documentation/de/notation/text.itely:1280: \musicglyph
#"accordion.discant"
same as for staff.itely before; all changes already applied
http://codereview.appspot.com/3092041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: translations: manually update syntax (1358) (issue3092041)
On 2010/11/13 17:22:44, Graham Percival wrote: Translation Meister: here's a fix for 1358. ok to push? I don't know why this issue has been hanging around for 3 week... I mean, editing .ly code and @funindex entries isn't precisely difficult! Push if you want to, but besides version strings all these changes are already done, see comment on staff.itely. It's not a matter of difficulty; rather the commit went unnoticed. The commit is in lilypond/translation branch and still (as of Nov 14th) not merged into master. http://codereview.appspot.com/3092041/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
