Traducción/Método de trabajo

Las personas encargadas de la edición de esta página consideran que aún necesario efectuar cambios, quizás importantes, en la misma.

Traducción

Método de trabajo - Guía de estilo - Estado de la traducción - Documentación - Herramientas

Weblate

Actualmente, la traducción se realiza usando Weblate. Es necesario hacerse una cuenta para poder hacer o modificar las traducciones. De lo contrario, solo se pueden dejar sugerencias que los traductores registrados podrán tener en cuenta o descartar cuando las vean.

Los sistemas anteriores (acceso directo al SVN y Vertaal) no tienen validez ya.

Colaboración entre traductores de SLE y comunitarios

[SECCIÓN EN PROCESO - BORRADOR]

openSUSE Leap comparte una base común con SUSE Linux Enterprise (SLE). Esto incluye la traducción de YaST y zypper. Por tanto, en la traducción participan tanto traductores contratados por SLE como traductores de la comunidad. La situación actual es que este solapamiento produce en ocasiones divergencias entre los términos usados al traducir por cada equipo de traducción. En estos momentos se está trabajando para mejorar la comunicación y cooperación entre ambos equipos de modo que no se terminen corrigiendo los unos a los otros.

¿Cada cuánto se publican las traducciones?

[SECCIÓN EN PROCESO] → Preguntar en la lista de correo

I18N

La internacionalización (abreviada como i18n por haber 18 letras entre la i y la n) se hace en Linux mediante las utilidades gettext (ejecute info gettext en una consola para ver la documentación). Durante el desarrollo se extraen los mensajes del código fuente original usando un programa que genera un fichero messages.pot. Partiendo de él, se crea un fichero message.po para cada idioma (bootloader.es.po por ejemplo); éste es el fichero que traducimos. Durante la compilación, este fichero es examinado y se genera un fichero binario (con extensión .mo o .gmo) que se instalará en algún sitio, tal como /usr/share/YaST2/locale/es/LC_MESSAGES/bootloader.mo. Durante la ejecución, el programa cargará el fichero de mensajes, substituyendo el texto inglés original por el texto traducido (si lo encuentra). Por ello, sólo con que cambien una simple coma en uno de los mensajes originales, la traducción de ese mensaje queda anulada, porque el texto original no coincide.

Más información:

• openSUSE Localization Work with PO Files
• Orden info gettext o equivalente en Konqueror.

Traducción

Usamos programas como emacs, poEdit o Lokalize para hacer nuestra parte del trabajo. Sobre todo los dos últimos son programas que automatizan alguna parte del mismo y que en ocasiones pueden dar problemas. Pero incluso programas como el mc o el editor mcedit pueden servir.

Tecnicismos de los ficheros .po

(Referencia: gettext.info, Node: PO Files)

El texto a traducir viene en ficheros de extensión .po, dividido en mensajes con este formato aproximado:

espacio en blanco
#  comentario del traductor
#. translators: help for 'help' option on command line
#: library/commandline/src/CommandLine.ycp:34
#, fuzzy
#| msgid "Print the help for the module"
msgid "Print the help for this module"
msgstr "Imprimir la ayuda para este módulo"

El campo msgid es el original en inglés y no se puede tocar aunque esté mal. ¡Jamás!. Es generado automáticamente por las herramientas gettext a partir de un fichero .pot. El campo msgstr marca la traducción. Los # son los comentarios y marcas.

El contenido del campo msgid puede variar en formato dependiendo del lenguaje de programación que se haya usado en el programa. De momento parece que todo lo que vemos usan los convencionalismos del C, pero podrían venir otros alguna vez.

Marcas en mensajes

El texto en los ficheros .po puede tener varias marcas de comentarios, que empiezan con un #:

#: Reference (generado por gettext, no tocar) marcan las fuentes, de dónde viene cada string.
#. Extracted comment (generado por gettext, no tocar). Son notas del programador hacia el traductor, y cuando existen son importantes.
#, Flag, lo genera el programa de traducción para sus propias marcas, como fuzzy.
#  Comentarios del traductor: los únicos que podemos crear o cambiar impunemente. Son nuestros.
#| msgid "Mensaje inglés de una versión anterior"
msgid "Mensaje inglés de la versión actual"
msgstr "mensaje traducido"

Ejemplo:

(línea en blanco)
#: lib/error.c:116
msgid "Unknown system error"
msgstr "Error desconocido del sistema"

Que es un mensaje marcado fuzzy

Son mensajes cuya parte inglesa ha cambiado ligeramente desde la versión anterior, y se marcan así para anularlo sin perder del todo la traducción; hasta que no se revise el programa mostrará el mensaje en inglés. También se marcan así los mensajes traducidos automáticamente.

msgctxt

A veces el bloque puede ser como esto:

msgctxt context one
msgid "some text"
msgstr "algún texto"

msgctxt context two
msgid "some text"
msgstr "algún otro texto"

La línea "msgctxt" diferencia mensajes del programa que en inglés son idénticos pero que podrían tener significado y traducción distinta.

Aceleradores

Algunas veces el texto inglés contiene letras antecedidas por el símbolo &, sobre todo en los textos de los menús. Éste símbolo marca la letra que corresponde a la tecla "aceleradora", la que sirve para acceder rápidamente al menú sin navegar por él.

Hay que marcar igualmente otra letra en el menú traducido, y hay que tener en cuenta que el mismo menú no tenga ninguna otra entrada con la misma letra marcada. Si se puede usar la misma letra que en inglés, mejor.

La complicación es saber cuales son todas las entradas del mismo menú, sin ejecutar el programa.

Plurales

En algunos casos, el mensaje inglés viene dividido en versiones singular y plural. Hay que estar atento y generar también sendas traducciones, y que sean consistentes. Y dad gracias, que hay idiomas con cuatro o cinco formas plurales.

Tiene este aspecto:

msgid "thing"
msgid_plural "things"
msgstr[0] "cosa"
msgstr[1] "cosas"

Marcas de variables

Los mensajes pueden contener cadenas como %i, que son reemplazadas en tiempo de ejecución por el contenido formateado de una variable. Es crucial mantener el mismo número y tipo de variable que en el original, o el programa puede caerse. La mayoría de las veces los errores serán detectados a tiempo automáticamente antes de aceptarse el fichero, pero no darlo por garantizado.

Marcas de formato

El texto puede contener marcas de formato como <b>negrita</b> que también hay que respetar escrupulosamente.

Otros errores

Hay multitud de errores que pueden colarse en la traducción, y que programas como Lokalize pueden detectar automáticamente. Por ejemplo, si el original inglés termina en ".", se detectará error si termina en "palabra" o "palabra. ". Hay que fijarse en cosas como la existencia de exclamaciones (en español hay que abrir y cerrar) o los retornos de carro forzados.

Si se usa una herramienta que permita la verificación del fichero, es importante perder un rato antes de dar por terminado el fichero en verificarlo para evitar posibles errores que deban ser reportados en Bugzilla (el servicio donde se comunican los errores y se hace su seguimiento).