Published using Google Docs
Proxecto de servizo web centralizado de corpus lingüístico e plugin para gtranslator
Updated automatically every 5 minutes

Proxecto de servizo web centralizado de corpus lingüístico e plugin para gtranslator

Proxecto de servizo web centralizado de corpus lingüístico e plugin para app de escritorio

Historia previa

Problemática

Proposta de solución

Ferramenta de administración en liña

Engadido para gtranslator

Resumo

Historia previa

 

Problemática

Os tradutores de software libre empregan ficheiros PO do estándar Gettext para internacionalizar aplicativos. Estes ficheiros son corporas semellantes a este formato:

#: ../Alacarte/MainWindow.py:180

msgid "Show"

msgstr "Mostrar"

#: ../Alacarte/MainWindow.py:188

msgid "Item"

msgstr "Elemento"

Cada tradutor de software libre pode chegar a traducir millóns de cadeas como as anteriores, de maior ou menor lonxitude, e estas cadeas pódense reutilizar para facer suxestións.

Como se pode ver na anterior captura ao traducir un aplicativo na parte superior dereita da pantalla aparecen suxestións de traducións para a cadea que o tradutor actualmente quere traducir. Se o tradutor estima oportuno con premer no seu teclado Ctrl+NUMERO dita suxestión cópiase directamente como texto traducido da cadea e pode continuar coa tradución.

Ao finalizar dito ficheiro é moi importante que comparta este ficheiro co resto de tradutores de software libre de dito idioma xa que isto creará unha base de datos moi grande de cadea-orixinal/cadea-traducida que poden reutilizar para usalas como «memorias de traducción» noutros proxectos de localización.

Un exemplo de compartición de memoria de tradución: http://www.mancomun.org/no_cache/actualidade/detalledenova/nova/memoria-de-traducion-de-gnome-228/

O formato estándar para intercambio de ditas memorias é o TMX. Un formato baseado en XML moi sinxelo.

Proposta de solución

Aplicativo en liña desenvolvido con PHP, compre usar un framework para facilitar o traballo de mantemento do aplicativo.

O realmente interesante é que poidamos ter un servizo centralizado (unha web) onde poder subir os TMX e que o sistema o analice e inserte nunha base de datos, tendo en conta a que proxecto, versión e aplicativo pertence. Ao telos nun sistema centralizado queremos ter varias formas de acceder a él.

poñeremos como exemplo o aplicativo http://corpus.trasno.net/:

  1. Poder ter unha especie de buscador onde poder obter unha lista de cadeas orixinais-traducidas. Exemplo: http://corpus.trasno.net/
  2. Poder ter un servizo web para a integración con varios apps: (REST a ser posíbel. http://en.wikipedia.org/wiki/Representational_State_Transfer). Exemplo: http://corpus.trasno.net/search/tab
  3. Debe permitir a busca rápida contextual para permitir suxestións. O sistema debería permitir obter unha lista de cadeas que son semellantes ou poden valerlle ao tradutor como base de tradución. Estas cadeas deberían xerarse en vivo e ter un rating ou porcentaxe de semellanza coa cadea que se quere traducir.
  4. Todo o anterior debería poder accederse tamén mediante servizo web. http://corpus.trasno.net/search/tab.tbx

Ferramenta de administración en liña

Esta ferramenta deberá ter dúas partes ben diferenciadas.

Poñamos como exemplo o proxecto de escritorio GNOME.

Polo tanto o sistema debería poder xestionar as distintas duplas cadea-orixinal/cadea-traducida tendo en conta o anterior.

En concepto é exactamente o mesmo que o anterior pero no lugar de ter que navegar en liña ou usar unha caixa de busca nunha páxina web, deberíase ter acceso mediante un servizo web. De tal forma que calquera aplicativo poida obter unha listaxe de cadeas que poidan empregarse para traducir.

Isto pódese entender mellor con un caso práctico:

Fulano X quere traducir a cadea “This button closes the window” pero quere obtelo mediante un servizo REST.

O que debería facer o Fulano X é consultar ao servizo REST cos seguintes parámetros (estes non teñen que ser os parámetros finais).

O sistema polo tanto debería ter unha saída semellante á seguinte:

<?xml version='1.0' encoding='utf-8'?>

<!DOCTYPE tmx SYSTEM "tmx14.dtd">

<tmx version="1.4">

  <header  creationtool="Translate Toolkit - po2tmx" creationtoolversion="1.4.0-rc2" segtype="sentence" o-tmf="UTF-8" adminlang="en" srclang="en" datatype="PlainText"/>

  <body>

    <tu>

      <tuv xml:lang="en">

        <seg>This button closes the window</seg>

      </tuv>

      <tuv xml:lang="gl">

        <seg>Este botón pecha a xanela</seg>

      </tuv>

    </tu>

  </body>

</tmx>

Comom podes ver aínda non se exporta ningun dato de % de acerto ou semellante pero podemos ir vendo onde meter máis cousas.

Xa que xml é moi pesado e supón unha alta taxa de transferencia sería interesante que o servizo tamén exportara JSON. A mesma resposta de antes en JSON podería ser:

{"en":"This button closes the window","gl":["Este boton pecha a xanela"]}

Como se pode apreciar a cantidade de información é a mesma porén os wrappers pesan menos. A vantaxe e que php tenhen funcións de de/conversión json bastante boas e integradas no core.

 
Engadido para gtranslator

Engadido programado en python ou C. https://webstats.gnome.org/Gedit/Plugins#howto

Tendo o anterior servizo web correndo e se temos conexión a internet debería ser ben sinxelo crear un engaiddo para gtranslator que dea suxestións para a cadea que imos traducir. De tal forma que poidamos empregala.

O fluxo de execución sería:

  1. O usuario preme sobre unha cadea que quere traducir ou avanza co botón Alt+AvPax
  2. O engadido por detrás consulta ao servizo web e este devólvelle unha lista de cadeas candidatas de tradución para o idioma no que estamos a traducir.
  3. O engadido completa a interface dun xeito semellante a:
  4. Finalmente o usuario cun dobre clic ou cun atallo de teclado copia dita cadea para usala na tradución.

O engadido de gtranslator debería poder ter unha interface de configuración para especificarlle algúns parámetros de configuración que poidan obterse desde o servidor: versións dispoñíbeis, proxectos dispoñíbeis. De tal forma que os resultados que o servidor devolve sexan discriminados polos anteriores parámetros.

Para este engadido estaría ben ter a opinion de Ignacio Casal (nacho en gnome punto org) xa que é o actual mantedor do aplicativo.

Este engadido debería facerse despois de que gnome3 saia xa que actualmente estase migrando a novas APIs e están cambiando bastante. Polo tanto sería o máis prudente agardar a que se estabiblice.

Gtranslator ten actualmente unha boa api para crear engadidos.

NOTA: o engadido debería xestionar de forma correcta unha caché das consultas que realizou e facer predicted requests para evitar tempos de espera grandes.

Resumo

Tecnoloxías