Introdución á tradución de software

De Proxecto trasno

Revisión feita por Miguelbranco (Conversa | contribucións) ás 21:16, 4 novembro 2012
(dif) ← Revisión máis antiga | Revisión actual (dif) | Revisión máis nova → (dif)
Faltan puntos por rematar. Antento ao ler a páxina


Índice

Conceptos previos

O inglés como lingua da computación

O fin do período colonial e o resultado das grandes guerras do século XX fixeron que a lingua de uso internacional, que ata ven entrado o pasado século fora o francés, pasara a ser o inglés, pois os Estados Unidos de Norte América colócanse coma a nova gran potencia mundial. Se a finais do século XIX e comezos do XX os primeiros grandes avances na enxeñaría e informática comezaron no mundo anglo-xermano, despois da primeira gran guerra os avances prodúcense no lado dos EUA. O resultado da segunda guerra mundial, que pon na quebra as economías europeas, e o resultado da guerra fría, permítenlle aos EUA consolidarse coma un potencia tecnolóxica. Con isto, non é de estrañar que o inglés sexa a lingua estándar na computación.

Internacionalización e localización

As aplicacións informáticas son desenvolvidas adaptadas cultural e lingüisticamente ao inglés americano; dende o texto que o usuario ve e os caracteres dese texto, as datas, o fuso horario, os formatos numéricos, os nomes, as direccións, ás unidades de medida... Por isto existe a necesidade de adaptar cada aplicación informática ás realidades culturais e lingüísticas de cada rexión. As aplicacións non adaptadas, non localizadas, impiden o uso desa aplicación a persoas que non coñecen o inglés e este é a razón fundamental pola que se localiza.

O proceso de internacionalización (que se abrevia como i18n) é o proceso polo cal se adapta unha aplicación para que permita o emprego doutras linguas, tipografías ou outras convencións locais.

O proceso de axustar o software xa internacionalizado a unha lingua ou rexión cultural concreta chámase localización e abreviase como l10n. A i18n das aplicacións é un requisito previo á localización. Por medio da localización créanse versión da aplicación sen necesidade de cambiar o código fonte da aplicación. Isto conséguese externalizando as mensaxes de texto ou imaxes específicas que logo os localizadores se encargarán de cambialos segundo a lingua ou os convenios culturais de cada rexión.

O proceso de globalización (g11n) emprégase habitualmente para englobar os procesos de internacionalización e localización. O proceso abrangue ao deseño, implementación e localización. Nalgún momento dado empregouse a abreviatura g11n para referirse á galeguización, mais a coincidencia da abreviatura coa de globalization fai desaconsellable o seu emprego.


O identificador locale

As linguas están recollidas nunha serie de estándares internacionais co fin de identificalas. A serie ISO 639 recolle asignan códigos identificacións cada lingua descrita. Estes códigos son empregados en varios ámbitos informáticos.

A ISO 639 consiste da 639-1, 639-2, 639-3 e 639-5. Foron redactados en diferentes momentos con variacións debido a unha ou outra necesidade, como a de ampliar sistema de codificación ata poder acoller as arredor de 6000 linguas vivas que se estima existen, ademais de linguas extintas e artificias. A ISO 639 identifica a cada idioma cun código de dúas letras mentres que a 639-2 define un código de tres letras. Así o galego recibe os identificadores gl e glg na 639-1 e 639-2, respectivamente. Outros exemplos importantes a ter en conta son:

ISO 639-1 ISO 639-2  Name
glglgGalician
ptporPortuguese
esspaSpanish
enengEnglish

Un "locale" denota unha lingua específica xunto cos convenios culturais de data, moeda, formato de número.... Explicado máis formalmente, o locale é o subconxunto das variables ambientais que teñen impacto nun usuario e que dependen de convencións lingüísticas ou culturais de cada rexión. O locale inclúe o seguinte:

  1. Lingua
  2. Formatos numéricos
  3. Convencións de data e hora
  4. Fusos horarios
  5. Cambios de horario de verán (de aforro enerxético)
  6. Moeda

É fácil percibir que non abonda con especificar unha lingua para identificar un locale. Un exemplo atopámolo coas diferenzas entre o inglés británico e o americano ou entre o portugués continental e o brasileiro. Inda que non existan necesariamente diferenzas dialectais, si existen diferenzas, por exemplo, por razóns xeográficas que fan que haxa que adaptar datas, fusos horarios ou similares. Así que ademais da lingua é necesario especificar o país ou rexión de fala da lingua.

O locale galego é gl_ES, onde ES é o identificador do estado español, que é de onde deriva o noso sistema de semana, data, hora.... Outros locales a ter presentes son:

Lingualocale
galegogl_ES
inglés americanoen_US
inglés británicoen_GB
portugués continental  pt_ES
portugués brasileiropt_BR
español peninsulares_ES

O locale en_US actúa habitualmente como predefinido na maioría dos sistemas, pois é o de orixe.

Cada lingua ten ademais un sistema de escritura que pode variar. As linguas poden ter sistemas alfabéticos, coas súas diferentes tipografías, ou sistemas iconográficos pero os ordenadores traballan con díxitos. Con isto, cada carácter tipográfico leva un número asociado nun estándar de representación específico. Esta asociación chámase código de caracteres. Códigos de caracteres (eng. charset) hai múltiples, coma o ASCII ou a ISO-8859-1. O sistema Unicode é un estándar industrial de representación de códigos de caracteres deseñado para acoller a todos os símbolos e textos posibles te todos os sistemas de escritura do mundo. O Unicode Transformation Format (UTF) é de amplo uso en programas internacionalizados. Os formatos UTF-8 e UTF-16 son probablemente os máis empregados. O UTF-8 recolle correctamente o código de caracteres do galego pois é compatible coas escrituras latinas e o ASCII.

Ciclo de desenvolvemento e Sistemas de control de versións

Here goes some rough intro to CVS, and some very brief intro to basic svn and git commands

En moitos casos, senón en todos, os ficheiros de tradución hai que obtelos directamente dende os repositorios do proxecto empregando e logo remitilos mediante algún sistema de control de versións. Inda que algúns proxectos están a implantar sistemas para xestionar isto por medio da web, é máis que recomendable coñecer o básico dos principais CVS e así poder entender as instruccións que se nos poidan dar.

Sistemas amplamente empregados nos proxectos son SVN e Git, inda que é posible que nos encontremos con outros sistemas coma Bazaar ou Mercurial.

SVN

É imperativo afacerse cunha copia de SVN e instalala. Dependendo do sistema operativo, o proceso pode variar lixeiramente.

  • En Windows e Mac OSX, descárguese o executable dende o proxecto SVN
  • En Debian
aptitude install subversion
  • En openSUSE
zypper install subversion
  • En Fedora
 
yum install subversion

Todas as distribucións Linux e BSD inclúen nos repositorios subversion.

Git

Fluxo da localización e Gettext

{POT TEMPLATES YET TO BE MENTIONED}


Poderíase pensar que o fluxo de localización segue un patrón no que o desenvolvedor envía as traducións a un ficheiro que logo o localizador de cada idioma traduce, tendo como resultado tantos paquetes de programa cun ficheiro de lingua asociado como o número de linguas ás que se localizara. Isto ben pode ser o caso da tradución dun documento de texto ou unha páxina HTML, que produce un ficheiro completo para cada lingua. Porén, as tradución de software non se realizan dun xeito estático senón que se fan de xeito dinámico. As traducións dun programa debúxanse en tempo de execución. En realidade as aplicacións prográmanse para que escollan as cadeas de texto que aparecen en cada momento dende un ficheiro coas traducións a lingua (hai un por lingua) que o usuario especificou nas súas preferencias. Isto é o que se chama tradución dinámica'.

Independentemente de que a tradución se faca dun xeito dinámico ou estático, hai un ficheiro de cadeas en inglés para ser traducidas. Inda que este ficheiro simplemente contén texto precisase que todos os localizadores empreguen o mesmo formato de texto e poidan eles e os desenvolvedores manter o sistema de tradución continuamente ao longo do desenvolvemento da aplicación. Para evitar estes problemas no software libre desenvolveuse un formato de ficheiro específico para o proceso. Existen varias ferramentas, independentes, que se programaron para traducir, validar e converter este formato a outros formatos, independentemente de que sexa texto da interface gráfica, documentación, páxinas man, notas de lanzamento ou contido web.

No sistema de tradución Gettext este formato é o PO, que é o formato máis amplamente empregado para a localización de software libre.Este formato está pensado para

  • Tradución estáticas intermedias: datos de texto estático, como a documentación de software, que se converte do formato orixinal a PO, tradúcese e convertese de novo ao formato orixinal. Co este resultado prodúcense os documentos finais que o usuario vaia a ver.
  • Traducións dinámicas intermedias: algunhas aplicación manteñen as cadeas da interface no seu propio formato, como é o caso de Mozilla ou OpenOffice. Estes formatos reconvértense en ficheiro de tradución PO para que sexan traducidos e logo vólvense a converter no formato de orixe para que sexan empregados en tempo real polas aplicacións.
  • Traducións nativas dinámicas: moitas aplicacións empregan o formato PO como formato nativo para as cadeas da interface co cal non hai necesidade de conversións intermedias. Isto inclúe aos entornos de escritorio KDE e Gnome, as ferramentas GNU etc. Para poder empregalos en tempo real os ficheiros PO compílanse a ficheiros binarios MO.

É importante esta distinción xa que dependendo do uso, poden aparecer elementos incrustados asociados ao código que se traduce. Para as cadeas da interface poden aparecer directivas de formato namentres na documentación pode aparecer marcado do tipo HTML. Asi que o tradutor ten coñecer que se está a traducir con ese ficheiro PO.

O formato PO é un formato compacto, facilmente lexible e editable sen necesidade de ferramentas especializadas. Isto implica que inda que hai ferramentas especializadas, pódese empregar un simple editor de texto para facer a tradución. Inda así os tradutores deben coñecer a estrutura do formato!.

Características básicas do formato PO

O formato PO é un formato de texto simple que leva a extensión .po . O ficheiro PO contén un número de mensaxes, en parte segmentos de texto independentes para traducir, que foron agrupados nun só ficheiro por algún motivo lóxico de estruturación da tradución. Por exemplo, unha aplicación soa, calquera, probablemente agrupe todas as mensaxes de texto da interface nun só ficheiro PO, toda a documentación outro. Igualmente, esta aplicación podería subdividir a tradución en varios ficheiros PO por módulos, a documentación dividida por capítulos etc. Os ficheiros PO tamén se coñecen coma catálogos de mensaxes.

Corpo do ficheiro

Un segmento intermedio dun ficheiro PO ten unha estrutura coma a seguinte:

#: finddialog.cpp:38
msgid "Globular Clusters"
msgstr ""
⁠
#: finddialog.cpp:39
msgid "Gaseous Nebulae"
msgstr ""
⁠
#: finddialog.cpp:40
msgid "Planetary Nebulae"
msgstr ""

Cada mensaxe contén a etiqueta msgid seguida do texto en inglés e entre comiñas. A etiqueta msgstr marca a cadea que se supón que é a tradución á lingua de destino, a lingua á que se traduce; igualmente entre comiñas. Unha vez se realiza a tradución o segmento sería coma o seguinte:

#: finddialog.cpp:38
msgid "Globular Clusters"
msgstr "Cústers globulares"
⁠
#: finddialog.cpp:39
msgid "Gaseous Nebulae"
msgstr "Nebulosas gaseosas"
⁠
#: finddialog.cpp:40
msgid "Planetary Nebulae"
msgstr "Nebulosa planetaria"

É posible deixar traducións sen realizar e tecnicamente non supón un problema. Mais nese caso o usuario final verá unha interface parcialmente traducida, onde as cadeas que non se traduciron móstranse en inglés.

Cada mensaxe no ficheiro PO contén un comentario de referencia á orixe, que é a liña que comeza co #: . Informa onde se atopa esa frase no código fonte da aplicación, ou a parte onde se atopa se é un documento de calquera outra clase.

Pódese dicir, inda que non sempre é certo, que cada mensaxe no ficheiro PO está identificada inequivocamente pola cadea msgid. Isto implica que se hai que informar sobre dunha cadea en concreto,por exemplo, porque haxa un erro tipográfico no texto inglés; hai que dar a información msgid da cadea da que se fala. Igualmente, non pode haber dúas mensaxes coa mesma msgid no mesmo ficheiro PO. Se unha mesma cadea aparece varias veces no código fonte recollerase nunha soa no ficheiro PO e cun comentario #: no que se pon a lista de todos os puntos do código onde esa cadea aparece. Os programadores ponde introducir comentarios para informar os tradutores do contexto. Exemplos disto:

#. i18n: A classical test phrase, with all letters of the English alphabet.
#. Replace it with a sample text in your language, such that it is
#. representative of language's writing system.
#: kdeui/fonts/kfontchooser.cpp:382
msgid "The Quick Brown Fox Jumps Over The Lazy Dog"
msgstr "" 

onde se nos di que esa frase non está pensada para que se traduza literalmente.

#. Tag: title
#: skycoords.docbook:73
msgid "The Horizontal Coordinate System"
msgstr ""

ou esta onde se nos informa de que a frase corresponde a un título.

Igualmente os tradutores poden introducir comentarios nas súas traducións:

# Wikipedia says that ‘etrurski’ is our name for this script.
#: viewpart/UnicodeBlocks.h:151
msgid "Old Italic"
msgstr "etrurski"

Cabeceiro

O formato PO leva un cabeceiro no que se fan unha serie de declaracións, entre elas e como para calquera texto, o formato de codificación. O máis recomendable é usar unha codificación UTF-8, o cal é estritamente necesario se van aparecer caracteres non ASCII.

Un exemplo de cabeceiro:

# translation of someprogram.po to galician
# Copyright (C) 2009 Free Software Foundation, Inc.
# Nome do Tradutor <correo@dotradutor.com>, 2009.
msgid ""
msgstr ""
"Project-Id-Version: kmail\n"
"Report-Msgid-Bugs-To: http://some.web.org\n"
"POT-Creation-Date: 2009-12-23 06:57+0100\n"
"PO-Revision-Date: 2009-10-06 18:46+0200\n"
"Last-Translator: Nome do Tradutor <correo@dotradutor.com>\n"
"Language-Team: Galician <proxecto@trasno.net>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Lokalize 1.0\n"
"Plural-Forms: nplurals=2; plural=n != 1;\n"

A entrada "Plural-Forms" cuantifica o número de plurais que a lingua de destino ten. Algunhas cadeas precisarán de varias traducións en función do número de plurais de cada lingua. Esta entrada ten sempre a forma:

Plural-Forms: nplurals=2; plural=n == 1 ? 0 : 1;

onde nplurals é o numero de plurais e ten que se corresponder cun valor enteiro natural: e onde plurals é a expresión en sintaxe da linguaxe C. Esta entrada admite a variable n. ALgúns exemplos sinxelos dependendo dos plurais de cada lingua:

Número de plurais Plural-Form Exemplos de linguas
0nplurals=1; plural=0Xaponés, Coreano, Turco
1nplurals=2; plural=n != 1 Inglés, Alemán, Galego, Portugés, Castelán
2nplurals=2; plural=n>1Francés, Portugués brasileiro
3nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n != 0 ? 1 : 2Letón

Directivas de formato

Cando algún programa, poñamos un xestor de ficheiros, nos informa de "Quere eliminar o ficheiro apuntamentos.txt?", ese "apuntamentos.txt" foi engadido en tempo de execución da aplicación. Nestes casos o texto orixinal que ve o tradutor conterá directivas de formato, subcadeas que a aplicación substitúe por argumentos apropiados no momento e que lle serven para construír a mensaxe que o usuario ve. Obsérvese:

#: skycomponents/constellationlines.cpp:106
#, kde-format
msgid "No star named %1 found."
msgstr "Non se atopou o nome da estrela %1."

A directiva de formato nesta mensaxe é %1. As directivas de formato dependen da aplicación que se considere. Por exemplo, namentres en KDE se soe empregar %1 e Gnome sóese facer uso de %s pois é habitual para aplicacións en C. Outra directiva frecuente é %d e emprégase con enteiros. Un caso de directiva en Python:

#: skycomponents/constellationlines.cpp:106
#, python-format
msgid "No star named %(starname)s found."
msgstr "Nema zvezde po imenu %(starname)s."

aquí a directiva é %(starname)s.

As directivas non deben ser cambiadas pois senón a aplicación non fará a substitución e moi probablemente derivará nun peche desta. Cada directiva da cadea orixinal debe atoparse intacta na cadea traducida. As directivas de formato poden precisar de se colocar na frase na posición que lle corresponda gramaticalmente na lingua de orixe. Tamén se hai varias directivas haberá que reordenalas para que sigan a estrutura gramatical correcta da lingua de destino:

#: kxsldbgpart/libxsldbg/xsldbg.cpp:256
#, kde-format
msgid "%1 took %2 ms to complete."
msgstr "Levoulle %2 acabar a %1."

Cando hai varias directivas de formato iguais na cadea que están numeradas ou nomeadas pódese, habitualmente, eliminar os duplicados na tradución. Isto pode ser o caso no que se intruduce un pronome para referirse a ese elemento ao que se refire a directiva:

#: hypothetical.cpp:100
#, kde-format
msgid "%1 is the blah, blah, blah. With %1 you can blah, blah."
msgstr "%1 é bla bla bla. Con el podes bla bla bla."

e inversamente, pódese repetir a directiva inda cando non apareza repetida na cadea en inglés.

Marcado de texto

As aplicación ás veces mostran texto en texto non simple; isto é, con negriñas, cursivas, tamaños de letra máis grande etc. O tradutor este texto encóntrao cun determinado tipo de marcadok, con as palabras, frases ou paragrafos enteiros están incluídos dentro de etiquetas especiais. Exemplos disto:

msgid "<b>Name:</b>"
msgstr ""
msgid "<qt>Current map:<br/><b>%1</b></qt>"
msgstr ""

⁠ Neste caso o marcado é do tipo XML as etiquetas están para nun formato do estilo <etiqueta>...</etiqueta>, onde ... é o texto que é etiquetado. As etiquetas ... poñen o texto en negriña, por exemplo.

Outros marcados habituais da documentación son do estilo <title>...</title> e pertencen ai formato XML Docbook.

Polo xeral, hai que reproducir exactamente o tipo de etiquetas tal que aparecen na cadea de orixe e baixo ningunha circunstancia traducir a etiqueta en si (ese <title> ou <emphasis>). Pódese, iso si, modificar o marcado do texto, sempre e cando se saiba correctamente o que se fai.

Nos PO de interfaces gráficas aparecen partes no texto orixinal que semellan marcado do tipo XML:

#: utils/katecmds.cpp:180
#, kde-format
msgid "Missing argument. Usage: %1 <value>"
msgstr ""

Ese <value> non é unha etiqueta senón que texto que o usuario ve. En realidade é unha marca de substitución que lle indica ao usuario que argumento debería ir nese lugar. As marcas de substitución son susceptibles de ser traducidas máis hai que ter tino de non traducir unha etiqueta de marcado de texto cando por confundila cunha marca de substitución.

Cando se atopen marcas que non se coñecen deberíase buscar información para saber que función teñen e que uso se lle dá.

XLIFF stuff and translation memories

All about XLIFF... tough not relevant in FLOSS l10n *yet*(?). So very very brief intro; then it's all 'bout memories coz ya know, we all use 'em

Aplicacións para a tradución

Editores de texto vs ferramentas especializadas

Aplicacións de escritorio

Aplicacións en liña

Ferramentas persoais