]> git.donarmstrong.com Git - lilypond.git/commitdiff
Update macro calls
authorFrancisco Vila <francisco.vila@hispalinux.es>
Mon, 24 Mar 2008 09:15:23 +0000 (10:15 +0100)
committerFrancisco Vila <francisco.vila@hispalinux.es>
Mon, 24 Mar 2008 09:15:23 +0000 (10:15 +0100)
Still some ruser calls remain in original

Documentation/es/user/working.itely

index c8e2fa9e5f3ee9e6966bd16be1b62f063540330e..fecc756ac20eefa137f74e19175fae25e57be034 100644 (file)
@@ -1,7 +1,7 @@
 @c -*- coding: utf-8; mode: texinfo; -*-
 @c This file is part of lilypond.tely
 @ignore
-    Translation of GIT committish: 8f4d2068a0c7698ac66797b874b25a427b0d0f27
+    Translation of GIT committish: e1c119e97fca9bce4bb8749e56bf2952598589f6
 
     When revising a translation, copy the HEAD committish of the
     version that you are working on.  See TRANSLATION for details.
@@ -69,19 +69,21 @@ o corregir problemas:
 
 @itemize @bullet
 @item @strong{Incluya los números de @code{\version} en todos los archivos}.  Dese cuenta de que todas las
-plantillas contienen una cadena como @code{\version "2.11.38"}.  Le recomendamos
-mucho que siempre incluya la @code{\version}, sin importar cuán
-pequeño pueda ser su archivo.  Desde la experiencia personal podemos decirle que es bastante frustrante
-intentar recordar el número de versión de LilyPond que estaba usando hace unos años.
-@code{convert-ly} requiere que declare
-qué versión de LilyPond utilizó.
-
-@item @strong{Incluya comprobaciones}: @ruser{Bar check}, @ruser{Octave check} y
-@ruser{Barnumber check}.  Si
-incluye comprobaciones de vez en cuando, en caso de que cometa un error podrá localizarlo mucho más rápidamente.
-¿Con qué frecuencia es @q{de vez en cuando}?  Depende de la complejidad
-de la música.  Para una música muy sencilla, quizá tan sólo una o dos veces.  Para
-una música muy compleja, quizá a cada compás.
+plantillas contienen información sobre la @code{\version}.  Le
+recomendamos mucho que siempre incluya la @code{\version}, sin
+importar cuán pequeño pueda ser su archivo.  Desde la experiencia
+personal podemos decirle que es bastante frustrante intentar recordar
+el número de versión de LilyPond que estaba usando hace unos años.
+@code{convert-ly} requiere que declare qué versión de LilyPond
+utilizó.
+
+@item @strong{Incluya comprobaciones}: @ruser{Bar and barnumber checks},
+@ruser{Octave check}.  Si incluye comprobaciones de vez en cuando, en
+caso de que cometa un error podrá localizarlo mucho más rápidamente.
+¿Con qué frecuencia es @q{de vez en cuando}?  Depende de la
+complejidad de la música.  Para una música muy sencilla, quizá tan
+sólo una o dos veces.  Para una música muy compleja, quizá a cada
+compás.
 
 @item @strong{Un compás por cada línea de texto}.  Si hay algo muy complicado, ya sea
 en la propia música
@@ -109,8 +111,8 @@ e identificadores.  Si especifica @code{c4 d e} al principio de una frase
 si reelabora la música más tarde.
 
 @item @strong{Separe los trucos} de las definiciones musicales.  Consulte
-@ruser{Saving typing with variables and functions} y
-@ruser{Style sheets}.
+@ref{Saving typing with variables and functions} y
+@ref{Style sheets}.
 
 @end itemize
 
@@ -168,12 +170,11 @@ g4 c'8. e16
 @}
 @end example
 
-@item @strong{Separe los trucos de las definiciones musicales}.  Ya se mencionó
-en @ruser{General suggestions}, pero para proyectos
-grandes es vital.  Quizá tengamos que cambiar la
-definición de @code{fthenp}, pero en ese caso sólo lo tendremos que
-hacer una vez, y aún podremos evitar tocar nada
-dentro de @code{violin}.
+@item @strong{Separe los trucos de las definiciones musicales}.
+Ya se mencionó con anterioridad, pero para proyectos grandes es vital.
+Quizá tengamos que cambiar la definición de @code{fthenp}, pero en ese
+caso sólo lo tendremos que hacer una vez, y aún podremos evitar tocar
+nada dentro de @code{violin}.
 
 @example
 fthenp = _\markup@{
@@ -283,9 +284,9 @@ padText =
 @end lilypond
 
 La utilización de identificadores también es una buena forma de reducir el trabajo si
-la sintaxis de entrada de LilyPond cambia (ver @ruser{Updating old files}).  Si
+la sintaxis de entrada de LilyPond cambia (véase @ref{Updating old files}).  Si
 tiene una sola definición (como p.ej. @code{\dolce}) para todos sus
-archivos (ver @ruser{Style sheets}), y después la sintaxis se modifica, sólo tendrá
+archivos (ver @ref{Style sheets}), y después la sintaxis se modifica, sólo tendrá
 que actualizar su definición @code{\dolce} única,
 en lugar de tener que hacer cambios en cada uno de los archivos @code{.ly}.
 
@@ -294,14 +295,14 @@ en lugar de tener que hacer cambios en cada uno de los archivos @code{.ly}.
 @subsection Style sheets
 
 La salida que produce LilyPond se puede modificar profundamente; consulte
-@ruser{Tweaking output} para leer detalles sobre este asunto.  Pero ¿qué ocurre si tiene muchos
+@ref{Tweaking output} para leer detalles sobre este asunto.  Pero ¿qué ocurre si tiene muchos
 archivos a los que les quiere aplicar sus propios trucos?  O ¿qué ocurre si, sencillamente,
 quiere separar los trucos de la propia música?  Todo esto
 es bastante fácil de conseguir.
 
 Veamos un ejemplo.  No se preocupe si no entiende
 las partes que tienen todos los @code{#()}.  Esto se explicará en
-@ruser{Advanced tweaks with Scheme}.
+@ref{Advanced tweaks with Scheme}.
 
 @lilypond[quote,verbatim,ragged-right]
 mpdolce = #(make-dynamic-script (markup #:hspace 1 #:translate (cons 5 0)
@@ -322,7 +323,7 @@ tempoMark = #(define-music-function (parser location markp) (string?)
 @end lilypond
 
 Existen varios problemas con la salida que se superpone; los arreglaremos utilizando
-las técnicas descritas en @ruser{Moving objects}.  Pero también haremos algo respecto a
+las técnicas descritas en @ref{Moving objects}.  Pero también haremos algo respecto a
 las definiciones @code{mpdolce} y @code{tempoMark}.  Éstas producen la salida que
 deseamos, pero quizá las querríamos utilizar en otra pieza.
 Podríamos simplemente copiarlas y pegarlas al principio de cada archivo,
@@ -633,7 +634,7 @@ Ahora empiece poco a poco descomentando cada vez más fracciones de la
 parte del @code{bajo} hasta que encuentre la línea del problema.
 
 Otra técnica de depuración muy útil es la construcción de
-@ruser{Minimal examples}.
+@ref{Minimal examples}.
 
 
 @node Minimal examples