@c -*- coding: utf-8; mode: texinfo; documentlanguage: es -*-
@ignore
- Translation of GIT committish: 5da0af52c0f2f6f00347981549a0e54feff6d056
+ Translation of GIT committish: 3f5d679ade0f797d5f907569656223d09b09d5db
When revising a translation, copy the HEAD committish of the
version that you are working on. For details, see the Contributors'
@include included/acknowledge.itexi
@include included/authors.itexi
+@include included/gsoc.itexi
@include included/helpus.itexi
@node Comunidad
@divEnd
+
+
@node Google Summer of Code
@unnumberedsec Google Summer of Code
@translationof Google Summer of Code
-@divClass{column-center-top}
-@subheading ¿Qué es el Google Summer of Code (Verano del Código de Google)?
-
-@uref{https://summerofcode.withgoogle.com/, GSoC} es un programa
-global que ofrece a estudiantes una ayuda para que trabajen en
-proyectos de software de fuentes abiertas durante las vacaciones
-de verano. Durante tres meses, los estudiantes trabajan para
-completar una tarea dada como parte de la comunidad del proyecto y
-bajo la guía de mentores con experiencia. El programa es una
-excelente oportunidad para que los estudiantes obtengan
-experiencia en el desarrollo de software en el mundo real y hagan
-contribuciones que beneficie a todos. Atrae a colaboradores
-nuevos y anima a los estudiantes que ya participan en el
-desarrollo de LilyPond a que se impliquen aún más. LilyPond
-participa en el GSoC como parte del @uref{http://www.gnu.org/,
-proyecto GNU}.
-
-Hemos tenido participantes en el GSoC en 2012, 2015 y 2016 y
-animamos a los estudiantes a que envíen la solicitud para el
-programa de 2017.
-
-Si está interesado en presentarse al programa con LilyPond como
-proyecto, le rogamos que lea la información que aparece más abajo
-y que no dude en escribirnos a la lista de desarrolladores (véase
-@ref{Contacto}). El plazo de solicitud para estudiantes es desde
-el 20 de marzo hasta el 3 de abril de 2017, pero le recomendamos
-encarecidamente que se ponga en contacto con nuestra comunidad con
-antelación.
-
-@divEnd
-
-@divClass{column-center-middle-color2 bigger-subsubheadings}
-@subheading Lista de ideas del proyecto
-
-Más abajo aparece una lista de ideas para el proyecto GSoC (última
-actualización: enero de 2017), pero si tiene otras ideas para un
-proyecto que pueda completar en el plazo de tres meses del
-programa, se le invita a formular la sugerencia sobre nuestra
-lista de correo de desarrolladores (véase @ref{Contacto}).
-Existen varias áreas en las que LilyPond se puede mejorar, y
-nuestro equipo de desarrollo siempre está dispuesto a ayudar a los
-que desean enfrentarse a un proyecto similar a los que aparecen
-relacionados más abajo. Ya que la disponibilidad de los mentores
-varía de proyecto en proyecto y de un año a otro, lo más sensato
-es ponerse en contacto con nosotros lo antes posible.
-
-Hay una lista completa de todas las incidencias abiertas
-@uref{http://sourceforge.net/p/testlilyissues/issues/, aquí}.
-
-
-@subsubheading Mejora de la estructura interna de acordes
-
-La representación interna de los acordes de LilyPond no es lo
-bastante potente como para captar la nomenclatura de los acordes
-de jazz. Actualmente el acorde tiene una fundamental, un bajo y
-una inversión. Sería bueno poder manejar acordes múltiples o
-superpuestos, menor/mayor, etc. Para hacerlo, debe desarrollarse
-una representación interna con la capacidad de capturar la esencia
-de los acordes más complejos. Además, una vez que se haya
-desarrollado la representación interna, el formato de salida de
-los nombres de acorde puede mejorarse.
-
-@emph{Dificultad:} Fácil/intermedia
-
-@emph{Requisitos:} Scheme (Guile), pero el nivel necesario puede
-aprenderse fácilmente
-
-@emph{Conocimientos recomendados:} Teoría y nomenclatura de los acordes
-
-@emph{Mentor:} Carl Sorensen
-
-
-@subsubheading Adoptar el estándar SMuFL de codificación de tipografías
-
-Desde hace varios años circula un nuevo estándar para las fuentes
-tipográficas de música: @uref{http://www.smufl.org/, SMuFL}, que
-también se estudia como parte de un futuro estándar del W3C para
-la codificación de música. Como herramienta FLOSS, LilyPond
-debiera unirse a este estándar en lugar de usar una solución
-aislada como hace actualmente. La adopción de SMuFL ayudaría a
-integrar LilyPond con el mundo del software de notación musical y
-al final daría a los usuarios de LilyPond acceso a una más amplia
-selección de fuentes tipográficas de notación.
-
-Hacer que LilyPond cumpla el estándar SMuFL consiste en la
-reasignación de los glifos que se construyen a partir de código
-fuente de METAFONT, el ajuste de las métricas de los glifos a las
-especificaciones de SMuFL, y finalmente la actualización de la
-forma en que LilyPond localiza y posiciona los glifos. Como parte
-opcional de este proyecto, podría modificarse el mecanismo de
-carga de las fuentes por parte de LilyPond para que usara las
-fuentes de notación instaladas como fuentes del sistema en lugar
-de hacerlo dentro de la instalación de LilyPond.
-
-@emph{Dificultad:} Baja/media
-
-@emph{Requisitos:} C++ y disposición para familiarizarse con el funcionamiento interno de LilyPond.
-
-@emph{Conocimientos recomendados:} Interés y experiencia en el trabajo con archivos de fuentes tipográficas. Un poco de METAFONT.
-
-@emph{Mentores:} Werner Lemberg, Abraham Lee
-
-
-@subsubheading Añadir una variante especial de los glifos de fuente tipográfica
-
-@divClass{keep-bullets}
-@itemize
-
-@item
-Añadir variantes @q{sobre} y @q{entre} líneas del pentagrama.
-
-@item
-Variantes más bajas y estrechas de ciertos glifos, como
-alteraciones alccidentales. Otro ejemplo más específico sería una
-cabeza de nota breve de la notación antigua en dos variantes, una
-con un hueco pequeño dentro, y otra con un hueco grande.
-
-@end itemize
-@divEnd
-
-@emph{Dificultad:} fácil
-
-@emph{Requisitos:} MetaFont, C++, buen ojo para los detalles
-
-@emph{Conocimientos recomendados:} conocimientos básicos de LilyPond
-
-@emph{Mentor potencial:} Werner Lemberg
-
-
-@subsubheading Notación contemporánea
-
-LilyPond es muy bueno creando notación no estándar. Tener que
-@emph{codificar} cada uno de los elementos gráficos en lugar de
-simplemente @emph{dibujarlo} puede parecer engorroso pero de hecho
-es una gran virtud. Se pueden implementar funcionalidades
-notacionales nuevas con apariencia consistente, disposición
-automática y una interfaz sintáctica natural.
-
-Dentro del sistema de biblioteca
-@uref{https://github.com/openlilylib/oll-core, openLilyLib} el
-alumno creará una infraestructura fundamental y unos bloques
-constructivos para hacer más fácil la creación de notación
-contemporánea. Además (al menos) @emph{un} paquete en concreto se
-desarrollará para cubrir alguna notación contemporánea específica,
-como por ejemplo el estilo de algún compositor dado, técnicas de
-ejecución extendidas para un instrumento específico o una cierta
-categoría de efectos.
-
-@emph{Dificultad:} media
-
-@emph{Requisitos:} Scheme (interacción con las interioridades de LilyPond),
-técnicas de notación contemporánea
-
-@emph{Conocimientos recomendados:} habilidad para la elaboración de marcos de funcionamiento jerárquicos
-
-@emph{Mentores:} @strong{NN,} Urs Liska
-
-
-@subsubheading Reescritura de la extensión de LilyPond para LibreOffice con Python
-
-La extensión @uref{http://ooolilypond.sourceforge.net/,
-OOoLilyPond} hace posible incluir de forma muy práctica fragmentos
-de partitura de LilyPond dentro de documentos de
-OpenOffice.org/LibreOffice Writer, Draw e Impress, manteniendo al
-mismo tiempo la fuente y la imagen juntas. Después de muchos años
-sin desarrollo, se ha iniciado una tarea de hacer de nuevo que la
-extensión sea compatible con las versiones actuales de LibreOffice
-y de LilyPond.
-
-Sin embargo, según el ecosistema de LibreOffice ha cambiado
-significativamente, ahora es posible reescribir la extensión con
-Python y PyQt. Esto no solo será más potente en general, sino que
-permitirá la integración de funcionalidades de
-@uref{http://frescobaldi.org, Frescobaldi}, tales como el
-resaltado de sintaxis, facilidades durante la escritura,
-asistentes de partitura o transformaciones musicales.
-
-@emph{Dificultad:} baja/media
-
-@emph{Requisitos:} Python, PyQt, conceptos básicos de LilyPond y
-de extensiones de LibreOffice
-
-@emph{Conocimientos recomendados:} Familiaridad con la base de
-código de Frescobaldi o disposición para aprenderla durante el
-período fijado
-
-@emph{Mentor(es):} Joram Berger, Urs Liska, (Thorsten Behrens/LibreOffice)
-
-
-@subsubheading Pruebas y documentación automatizadas para openLilyLib
-
-@uref{https://github.com/openlilylib, openLilyLib} es un marco
-para extensiones de código de LilyPond que ofrece un repositorio
-de fragmentos de código o @qq{snipets} y una colección de paquetes
-integrados, tales como herramientas para la disposición de páginas
-o las anotaciones académicas. Es muy potente y prometedora, pero
-para que despegue realmente hacen falta dos funcionalidades:
-pruebas automatizadas y generación de la documentación.
-
-Las pruebas automatizadas son necesarias para asegurarse de que
-las modificaciones en una funcionalidad no quiebran el
-funcionamiento de otras partes de la biblioteca. Ya existe una
-cierta cantidad de pruebas automatizadas del repositorio de
-fragmentos de código, con el servidor Travis de Github, pero es
-necesario reconsiderarlo y extenderlo para que cubra también los
-paquetes sueltos.
+@gsocCurrent
-Para que sea utilizable por un más amplio abanico de usuarios de
-LilyPond al nivel del @qq{consumidor}, openLilyLib requiere una
-adecuada documentación. Esta documentación se debe generar a
-partir de las fuentes, por lo que se necesita un sistema que
-demande de los autores de los paquetes que documenten los archivos
-de entrada y que provean ejemplos de uso adicionales, desde los
-cuales se genera la documentación. Idealmente, pero no
-obligatoriamente, estaría implementado como un @code{hook} de Git, es
-decir, que funcione automáticamente al producirse cada una de las
-actualizaciones realizadas sobre el repositorio. No prescribimos
-ninguna de las herramientas o enfoques que se deben usar, pero el
-lenguaje de más amplio uso en el dominio de LilyPond es Python,
-por lo que habría cierta inclinación hacia esa opción. Como
-alternativa, estaría bien una solución en Scheme, de forma que la
-generación de documentación fuese, en efecto, disparada por la
-compilación de un determinado archivo de entrada de LilyPond. En
-general se recomienda hacer uso de conceptos y herramientas de
-otros lenguajes de eficacia probada.
-
-La salida final de la documentación debería ser una página HTML
-estática que se pueda ver localmente y/o subida a un sitio web.
-Pero sería beneficioso que la herramienta generase primero una
-representación intermedia (p.ej. un archivo JSON con archivos de
-medios adicionales) a partir de la cual una aplicación de página
-única pudiese recuperar el contenido para su presentación en la
-@uref{https://openlilylib.org, página web de openLilyLib}. El
-desarrollo de esta Aplicación de Página Única @emph{puede} formar
-parte del proyecto GSoC, pero es opcional.
-
-@emph{Dificultad:} media
-
-@emph{Requisitos:} Python o Scheme, generadores de web estáticos o
-tecnologías de aplicaciones web dinámicas (basadas en
-Node.js). Integración continua (se puede aprender mientras dura el
-período de vinculación)
-
-@emph{Mentores:} Urs Liska, Matteo Ceccarello
-
-
-@subsubheading MusicXML
-Mejora de las funciones de importación y exportación de MusicXML:
-
-File interchange between LilyPond and other applications using
-MusicXML is still a difficult matter. To import MusicXML it has
-to be converted manually by the @code{musicxml2ly} script. Export
-@emph{to} MusicXML is only available as a rudimentary feature
-inside Frescobaldi. In order to provide natural interchange
-between LilyPond and MusicXML based applications there's the need
-of actual import functionality and a dedicated export backend.
-
-Importing XML shall provide file, line and column to add origin
-attributes to generated objects. That way point and click can be
-made available in Frescobaldi or other supported IDEs.
-
-Exporting XML shall be realized with an exporter class like the
-MIDI export. This may be based on the work already done in
-@uref{https://github.com/DavidGarfinkle/Lilypond_MusicXMLexport, GSoC 2015}
-by David Garfinkle. It should be checked if it is possible to use
-another XML library than the one provided by guile-2 in order to
-have this feature available in current LilyPond (which is based on
-guile-1.8).
-
-@emph{Dificultad:} media
-
-@emph{Requisitos:} MusicXML, Python, Scheme, basic LilyPond knowledge
-
-@emph{Conocimientos recomendados:} Familiarity with other scorewriters (for cross-testing)
-
-@emph{Mentor:} Jan-Peter Voigt
-
-@divEnd
-
-
-@divClass{column-center-middle-color2}
-@subheading Información para los solicitantes o participantes
-
-In order to have a satisfying experience with GSoC applicants are
-strongly advised to thoroughly read the following recommendations.
-Some of these are relevant for the application process, others for
-the time within the project.
-
-@itemize
-
-@item
-Read all applicable information on the program's website,
-particularly the
-@uref{https://developers.google.com/open-source/gsoc/resources/manual,
-students' manual}. Make sure you fulfil all of Google's
-prerequisites and are willing to join the program as a full-time
-commitment over the coding period of three months.
-
-@item
-Please get in touch with us as soon as possible if you are
-interested in applying with a project. Mentor availability may
-change without notice, project proposals may need fine-tuning, and
-many other reasons might require us to reject or ignore an
-application that hasn't been discussed before.
-
-@item
-We do not know in advance how many “slots” we will have available
-for projects, so please be aware that you may find yourself in
-competition with other applicants or not. Interested or even
-enthusiastic response from our mentors is no guarantee of
-eventually being accepted, and @emph{not} being accepted does not
-necessarily indicate a negative evaluation of your application.
-If we have to decide between different applicants there may be
-various aspects to consider.
-
-@item
-Integration in the LilyPond community is a fundamental part of
-GSoC, and we expect our students to make substantial efforts to
-become community members. Within the @emph{bonding period} we
-expect you to write a blog post about your project (either on
-@uref{http://lilypondblog.org, Scores of Beauty} or on any other
-blog) and to be active on our mailing lists, introducing yourself
-but also communicating about unrelated tasks. This goes beyond
-the mere setting up of a working environment and familiarizing
-yourself with the relevant code, but we think it is crucial for
-the GSoC project to be mutually satisfying.
-
-@item
-If you are accepted to the program you will have one mentor
-explicitly assigned to your project. With this mentor you will
-have to agree upon a communication strategy, be it emails,
-chatrooms, issue trackers or voice/video chats. Regular
-communication is absolutely crucial for the success of a GSoC
-project so you are stricly required to keep talking to your
-mentor. But keep in mind that your mentor has explicitly taken
-over the responsibility for your project, and while unlike you he
-isn't paid for this activity you are still entitled to get regular
-attention from him.
-
-@item
-In order to get support from your mentor you have to give him a
-chance to follow your progress and efforts. Therefore it is
-important to regularly commit your changes to the versioning
-repository you are working on. Don't hesitate making unfinished
-code available because you are afraid of criticism, and don't
-suppress questions because you think they might be considered
-stupid. But ideally your code should at any time be accompanied
-by compatible testing code. Your mentor may not be able to
-properly assess your code by only @emph{reading} it without the
-opportunity to apply it in a real example.
-
-@end itemize
-
-Existe una lista de proyectos inactivos en el @ref{Desván}.
-Mantenemos en la lista los proyectos que aún se consideran
-valiosos, pero para los cuales no existe en la actualidad ningún
-mentor disponible.
-
-@divEnd
-
-@node Autores
-@unnumberedsec Autores
-@translationof Authors
+@node Authors
+@unnumberedsec Authors
@divClass{column-left-top}
@subheading Equipo de desarrollo actual
@divEnd
@divClass{column-center-middle-color2 bigger-subsubheadings}
-@subheading Sugerencias desactivadas para el proyecto Google Summer of Code
-
-La siguiente lista describe los proyectos de GSoC que han sido
-propuestos en años recientes y que aún se consideran valiosos pero
-para los cuales no disponemos de mentores libres.
-
-
-@subsubheading Mejora de las ligaduras de unión y de expresión
-
-Con frecuencia, las calidad gráfica de las ligaduras de unión y de
-expresión no es satisfactoria. No se manejan bien las ligaduras
-@q{interrumpidas} por cambios de clave o de pentagrama. El
-proyecto podría incluir y organizar ejemplos de mala salida,
-decidir sobre la salida perseguida y escibir código para
-mejorarla.
-
-@emph{Dificultad:} alta
-
-@emph{Requisitos:} C++, experiencia con heurística de la escritura
-
-@emph{Conocimientos recomendados:} LilyPond, sentido estético
-
-
-@subheading Notas de adorno
-
-Arreglar problemas con la sincronización de las notas de adorno.
-Las notas de adorno pueden interferir con la cuenta del tiempo de
-LilyPond y causar efectos extraños, especialmente cuando se usan
-varios pentagramas en los que algunos tienen notas de adorno y
-otros no. Este es uno de los más antiguos y emarazosos
-@uref{https://sourceforge.net/p/testlilyissues/issues/34/,bugs} de
-LilyPond.
-
-@emph{Dificultad:} media
-
-@emph{Requisitos:} C++, MIDI
-
-@emph{Conocimientos recomendados:} familiaridad con el
-funcionamiento interno de LilyPond
-
-
-@subsubheading Mejora del posicionamiento de las barras de corchea (y figuras menores)
-
-Para barras de corchea normales, de pentagrama cruzado,
-interrumpidas y en ángulo. El barrado debería depender del
-contexto y de las notas vecinas (véase la sección 2.2 de
-@uref{http://imslp.org/wiki/Repository_of_Music-Notation_Mistakes_%28Coulon%2C_Jean-Pierre%29,
-este libro}). Si es posible, reducir el tiempo de cálculo del
-barrado.
-
-@emph{Dificultad:} media
-
-@emph{Requisitos:} C++, experiencia con heurística de la escritura
-
-@emph{Conocimientos recomendados:} sentido estético
-
-
-@subsubheading Ayudar a mejorar el comportamiento de la compilación
-
-Las herramientas de análisis automático del código, como la
-detección de filtraciones de memoria de Valgrind o el perfilador
-de código Callgrind, proveen una información valiosa acerca de los
-posibles problemas de nuestro código de C++. La limpieza de estas
-advertencias nos permitiría rechazar automáticamente cualquier
-parche que introdujese más advertencias de las que hay
-actualmente.
-
-@emph{Dificultad:} media
-
-@emph{Requisitos:} C++
-
+@gsocInactive
@divEnd
@divClass{column-center-middle-color2}
projects / lilypond.git / commitdiff