Mudlet: Configure un servicio de traducción basado en la web para Mudlet

Creado en 9 abr. 2017  ·  45Comentarios  ·  Fuente: Mudlet/Mudlet

Necesitamos hacer que sea muy fácil para las personas contribuir a traducir Mudlet; eso significa algo basado en la web donde la única barrera es simplemente iniciar sesión. Puede haber un servicio basado en la web existente que podría ofrecernos una licencia de código abierto para configurar .

Alternativas disponibles:
Launchpad : sin embargo, su futuro es cuestionable
Transifex - proyecto de demostración aquí: https://www.transifex.com/mudlet/mudlet/dashboard/

low

Comentario más útil

Chicos, la prueba de crowdin expirará en 4 días, así que necesito un sí/no, parece que estamos contentos con él hasta ahora.

Todos 45 comentarios

Hay POEditor como integración con github, que permite traducir XLIFF
archivos (que supuestamente son compatibles con qt linguist). Y tienen un sistema operativo
licencia.

Otra opción es Qordoba, que no parece costar nada y de forma nativa
admite archivos ts.

Nunca usé ningún servicio/aplicación de traducción, por lo que no tengo preferencias.

Vadim Peretokin [email protected] schrieb am So., 9 de abril de 2017,
13:14:

Necesitamos que sea muy fácil para las personas contribuir a traducir Mudlet

  • eso significa algo basado en la web donde la única barrera es simplemente iniciar sesión.
    Es posible que exista un servicio basado en la web que podría ofrecernos una
    licencia de código abierto para obtener la configuración.

Alternativas disponibles:
Launchpad https://translations.launchpad.net/ - su futuro es
cuestionable sin embargo


Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Mudlet/Mudlet/issues/856 , o silencia el hilo
https://github.com/notifications/unsubscribe-auth/ABAeDUJoAsg-zvnOq1YUvuIqn-fbRwcCks5ruL2WgaJpZM4M3_u1
.

Re: XLIFF the _Qt Linguist Manual: Traductores_ Qt Doc notas:

__Traducir cadenas__
Abra archivos de fuente de traducción (TS) en Qt Linguist para traducir. Los archivos TS son archivos XML legibles por humanos que contienen frases fuente y sus traducciones. Los archivos TS generalmente se crean y actualizan mediante luupdate. Si no tiene un archivo TS, consulte Release Manager para obtener información sobre cómo generar uno.
También puede usar Qt Linguist para traducir archivos en el formato de archivo de intercambio de localización XML (XLIFF) internacional que generan otros programas. Sin embargo, para proyectos Qt estándar, solo se usa el formato de archivo TS. La versión mínima admitida para archivos de formato XLIFF es 1.1.

Ahora existen plataformas de traducción basadas en la web que tienen enormes ventajas sobre las aplicaciones de escritorio: no es necesario instalar ningún software, sugiere traducciones para el texto ya traducido, etc.

@SlySven He leído esto, por eso dije lo que dije. Se lee como no totalmente compatible o una ocurrencia tardía, por lo que supuestamente agregué (nunca lo probé).

@vadi2 Los productos que mencioné son plataformas basadas en la web. Pero aún necesitará usar qt linguist para que el marco de traducción de Qt pueda usar la salida de esas plataformas. Lo que también nos une a los formatos admitidos TS archivos y XLIFF .

He jugado con Linguist y, por lo que puedo decir, la interfaz de usuario es bastante buena (soy un fan: heart_eyes :), replica los diálogos de la interfaz de usuario {y muestra el código fuente donde se origina la cadena de texto para C++ que se origina en QStrings } para que pueda ver una buena idea de cómo se verán en los diferentes idiomas y puede trabajar en múltiples traducciones simultáneamente. Solo espero que Qt sea más rígido al no reordenar el contenido de los archivos TS innecesariamente para mantener bajo el ruido de git cuando un colaborador actualiza un archivo, a diferencia de, digamos, QGridLayouts en archivos .ui. * suspiro *

En cuanto a la necesidad de usar Qt Linguist, creo que, dado que usamos las bibliotecas Qt en general, es probable que nos comprometamos con ellas (como en los niveles de compromiso de _Pig_ en lugar de _Chicken_ en un _bacon-and-egg sarnie_) además de volvernos nativos gettext sería _más difícil_ en una buena forma, creo.

Parece que estoy interesado en ver la exportación de Qt Linguist a algo basado en la web, con la opción para que las personas instalen y obtengan una vista previa de sus traducciones en tiempo real si así lo desean. Veré los servicios que mencionaste

También tenía Transifex en mente, pero parece que ya no funciona tan bien.

Otra plataforma de traducción web: https://hosted.weblate.org/projects/tilix/translations/

Así es como el proyecto Mozilla maneja la localización y la traducción: https://developer.mozilla.org/en-US/docs/Mozilla/Localization/Quick_start_guide/Translation_phase

Otra gran mirada en profundidad a varias alternativas y el proceso en general en esta tesis de maestría sobre “Traducciones en software libre”: https://larjona.wordpress.com/translations-in-libre-software/

Gracias @Kebap , he leído el documento que has vinculado. Estoy interesado en Weblate y Transifex. Los revisaré.

Me gustaría que esto tenga la barrera de entrada más baja posible y que descarte la traducción basada en escritorio donde la persona tiene que descargar e instalar software, luego buscar los archivos correctos antes de tener la oportunidad de comenzar a trabajar.

Weblate parece agradable y de código abierto, pero su versión alojada también está inactiva en este momento, al igual que todas las traducciones alojadas como para el proyecto Tilix. No es bueno. También desconfío de alojar más cosas en nuestro servidor porque ya se está ejecutando al límite.

Voy a probar la demostración de Transifex. Son compatibles con el código abierto y parecen ser una tienda mucho más grande, por lo que es mucho menos probable que se caigan, a diferencia de Weblate.

Dicho esto, si la integración de Weblates Git realmente funciona, será mucho mejor usarlo, ya que _debería_ actualizar automáticamente el nuevo texto fuente de Git y tal vez volver a confirmarlo. Transifex, por otro lado, requiere que cargue manualmente los archivos para traducir.

Si bien Transifex admite archivos .ts de forma nativa, parece ahogarse al cargarlos. Sin embargo, el uso de ts2po y la carga de archivos .po funcionaron.

Parece que puede tener actualizaciones bidireccionales automáticas entre Transifex y Github con algún middleware: https://docs.transifex.com/integrations/github-txgh

Pude descargar un .po con la traducción intacta de Transifex, pero po2ts ahoga en el archivo con un error de codificación de Python:

po2ts: WARNING: Error processing: input ./for_use_mudlet_rupo_1_ru.po, output ./for_use_mudlet_rupo_1_ru.ts, template None: 'ascii' codec can't encode characters in position 1994-1999: ordinal not in range(128)

Dejaré el proyecto Transifex en https://www.transifex.com/mudlet/mudlet/dashboard si alguien más quiere traducir @Kebap @keneanung. Probaré Weblate a continuación.

Weblate es agradable: tiene una tonelada de opciones de inicio de sesión de terceros, por lo que unirse es realmente sencillo.

@vadi2 escribió:

Pude descargar un .po con la traducción intacta de Transifex, pero po2ts se ahoga en el archivo con un error de codificación de Python:

Creo que leí en alguna parte que su versión de po2ts solo funciona con una especificación anterior del archivo .ts y necesitaba una actualización (al final, supongo). Observo que proviene del Translation Toolkit de Traduzca el código fuente de House página de internacionalización de mixxx .

En realidad, ese error de "codificación" suena como si estuviera tratando de producir un archivo .ts donde la codificación es ASCII y NO UTF-8, por lo que está vomitando en el punto donde necesita usar algunos caracteres (en una cadena _traducida_) que no son ASCII...

¡Esa página se actualizó por última vez hace cuatro años! El proceso para desarrolladores está fuera
de fecha, creo. Esa es una documentación de traducción bastante impresionante.
¡sin embargo!

El martes 19 de septiembre de 2017 a las 6:18 p. m. Stephen Lyons [email protected] escribió:

@vadi2 escribió:

Pude descargar un .po con la traducción intacta de Transifex,
pero po2ts se ahoga con el archivo con un error de codificación de Python:

Creo que leí en alguna parte que su versión de po2ts solo funciona con un viejo
especificación del archivo .ts y actualización necesaria (al final, supongo) - I
tenga en cuenta que proviene del Kit de herramientas de traducción
http://toolkit.translatehouse.org/ de la fuente de Translate House Github
código https://github.com/translate/translate y la última versión es
2.2.5 (no sé qué están usando) al momento de escribir. Encontrado una
página web de otro proyecto (no estoy seguro de que esté basado en GitHub, pero el
el proceso general para ellos parecía el tipo de cosas que tendremos que hacer: mixxx
página de internacionalización
https://mixxx.org/wiki/doku.php/internacionalización .


Estás recibiendo esto porque fuiste asignado.

Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Mudlet/Mudlet/issues/856#issuecomment-330592819 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/AAGxjEdeBPs-7fDkUwfoLjUt48eJJhl0ks5sj-lagaJpZM4M3_u1
.

Weblate no parece estar en una buena posición. Todavía no he recibido una respuesta para mi aplicación alojada y el proyecto no recibe muchas actualizaciones. Volver a Transifex lo es.

Consejos sobre cómo configurar Transifex con Qt: https://forum.qt.io/topic/36750/qt5-ts-files-and-transifex-continuous-translation-localization

https://bugreports.qt.io/browse/QTBUG-1136 :

finalmente, el lingüista está esencialmente en soporte vital: cedimos el terreno a los ISV que se especializan en esta área.

Qt Linguist es una tecnología sin salida: no obtendrá ninguna función en el futuro, por lo que tenemos que usar una plataforma basada en la web aquí.

Veré cómo poner en marcha las traducciones de Transifex ahora que #1334 está disponible.

Solo para reiterar lo que mencioné en la referencia cruzada de Kebap de que crowdin también parecía una opción válida para un proyecto de código abierto como el nuestro, y pueden manejar archivos Qt .ts y también tienen integración con pseudolocalización también debería ayúdenos a prevenir problemas en la GUI porque no hemos estructurado el texto correctamente ( creo ) y definitivamente nos ayudará a asegurarnos de dejar suficiente margen para idiomas con cadenas más largas que en-US ...

crowdin se ve bien, veamos cómo se compara con Transifex, tengo un proyecto de prueba aquí .

@SlySven que la

peek 2018-05-18 13-36

Lo descubrí: crowdin también tiene esa opción. Simplemente seleccione "ocultar" en la configuración de etiquetas del editor :

selection_143

Esto significa que ya no tenemos que hacer el cambio de código que @SlySven ha estado haciendo; podemos usar HTML tal cual en las cadenas de origen, y tanto los codificadores como los traductores no sufren inconvenientes.

Estoy contento con la sugerencia de utilizar @crowdin las traducciones @SlySven 's. @Kebap , @SlySven , ¿ qué opinan ?

Una vez que estemos de acuerdo, repasaré el proyecto en crowdin para que sea oficial, solicitaré una licencia de código abierto y comenzaremos a correr la voz para los traductores.

Oye,

¡Soy parte del equipo de Crowdin y con gusto ayudaré con la configuración adicional si es necesario! Siéntase libre de mencionarme si surge alguna pregunta.

Estoy bien con crowdin también. Su interfaz de usuario ha sido confusa al principio, pero estoy seguro de que nos acostumbraremos.

Confieso que no he mirado de cerca el Transifex, ya que lo apagué mentalmente porque entendí que no manejaba bien/directamente el formato Qt .ts actual. ¿Ha cambiado eso o estaba equivocado? en esa creencia?

Una cosa sobre Crowdin que veo en las confirmaciones recientes de git es que estaba cargando varios archivos .ts que se habían configurado localmente para un idioma específico. En cierto modo, lo solucionó ahora enviando un solo archivo, un archivo mudlet_en.ts , pero eso todavía no me parece del todo correcto. Es posible que desee eliminar o comentar los TRANSLATIONS = líneas en el mudlet.pro archivo y tener un script de shell que se ejecuta (en la base de la fuente):

lupdate -recursive ./src/ -ts ./translations/mudlet.ts

para generar un solo archivo específico que no sea de idioma para pasar al proceso de traducción de Crowdin y hacer que produzca los archivos mudlet_xx_YY.ts que queremos (ya cambié una configuración en Crowdin para especificar el _xx_YY language+locale sufijos donde originalmente parecía estar configurado solo en _xx idioma uno). Eso aún dará como resultado un conjunto de archivos que luego se copiarán nuevamente en el mismo directorio listo para lrelease .

Por cierto, dejar el archivo simple sin sufijo es útil porque significa que las partes interesadas en idiomas minoritarios pueden copiarlo y cambiarle el nombre para que funcione en privado si así lo desean para un idioma diferente, descubierto, con el Qt Linguist proporcionado. {Tal vez uno pirata para el 19 de septiembre, por ejemplo!!!}

Creo que los pasos anti-ofusticación de HTML que he tomado parecen haberse vuelto un poco menos necesarios ya que el complemento Qt Designer parece haberse vuelto un poco menos ansioso por manipular el HTML en las últimas dos versiones de Qt. Todavía no estoy totalmente convencido de que no alterará las cosas y cambiará las cosas, por ejemplo, forzando el uso de las fuentes particulares que la última persona que editó tiene en sus sistemas en lugar de dejar que sea una fuente genérica que puede trabajar en todas las plataformas. Echaré otro vistazo e informaré eso aquí porque afectará la forma en que registramos dicho HTML en nuestro trabajo.

Confieso que no he mirado de cerca el Transifex, ya que lo apagué mentalmente porque entendí que no manejaba bien/directamente el formato Qt .ts actual. ¿Ha cambiado eso o estaba equivocado en esa creencia?

Yo también lo estaba, parece que ha cambiado: https://docs.transifex.com/formats/qt-ts

No planeo usar el complemento Qt Designer, por lo que cualquier manipulación que haga no es relevante: crowdin maneja las traducciones lo suficientemente bien por sí solo, y su representación HTML con el estilo "ocultar" es tolerable.

Oh, todavía lo está haciendo, insertando tablas y un DTD, entonces, lo que es más fácil de leer y analizar para los humanos, esto:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">
<html><head><meta name="qrichtext" content="1" /><style type="text/css">
p, li { white-space: pre-wrap; }
</style></head><body style=" font-family:'FreeSans'; font-size:9pt; font-weight:400; font-style:normal;">
<p align="center" style=" margin-top:12px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;"><span style=" font-size:large; font-weight:600;">Welcome to Mudlet!</span></p>
<p align="center" style=" margin-top:12px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">Click on one of the MUDs on the list to play.</p>
<p align="center" style=" margin-top:12px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">To play a game not in the list, click on <img src=":/icons/list-add_small.png" /><span style=" color:#555753;">New</span>, fill in the <span style=" font-style:italic;">Profile Name</span>, <span style=" font-style:italic;">Server address</span>, and <span style=" font-style:italic;">Port</span> fields in the <span style=" font-style:italic;">Required</span> area.</p>
<p align="center" style=" margin-top:12px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">After that, click <img src=":/icons/dialog-ok-apply_small.png" /><span style=" color:#555753;">Connect</span> to play.</p>
<p style=" margin-top:12px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">Have fun!</p>
<p align="right" style=" margin-top:12px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">The Mudlet Team <img src=":/icons/mudlet_main_16px.png" /></p></body></html>

o esto, que hace lo mismo en lo que a nosotros respecta:

<html><head/><body><center><big><b>Welcome to Mudlet!</b></big></center></p>
<p><center>Click on one of the MUDs on the list to play.<center></p>
<p><center>To play a game not in the list, click on <img src=":/icons/list-add_small.png"/> <span style="color:#555753;">New</span>, fill in the <i>Profile Name</i>, <i>Server address</i>, and <i>Port</i> fields in the <i>Required</i> area.<center></p>
<p><center>After that, click <img src=":/icons/dialog-ok-apply_small.png"/> <span style=" color:#555753;">Connect</span> to play.</center></p>
<p>Have fun!</p>
<p align="right">The Mudlet Team <img src=":/icons/mudlet_main_16px.png"/></p></body></html>

Técnicamente, todo esto es texto enriquecido de Qt, que es solo un subconjunto de HTML (entonces, ¿por qué forzar la inclusión de la estricta DTD de HTML 4.0?)

Incluso mostrando < y > aquí en lugar de &lt; y &gt; en el archivo sin procesar que verán los traductores, creo que está claro cuál va a sea ​​más fácil trabajar con él en ausencia de un widget de visualización de texto enriquecido HTML/Qt...

Creo que leí en alguna parte que los idiomas CJK realmente no deberían usar efectos de fuente en negrita o cursiva (en su lugar, creo que usan el equivalente de un acento de punto en un borde del glifo), por lo que en esos casos el marcado podría estar involucrado en el proceso de traducción...

La ejecución de scripts de shell no es portátil (para Windows), por lo que prefiero no hacerlo. ¿El archivo mudlet_en.ts actual parece estar funcionando bien?

Es viernes, así que lleguemos a una conclusión sobre esto en los próximos días para que podamos comenzar con los próximos pasos, que creo que serían:

1) proceso para que los traductores informen cadenas confusas: si un traductor no puede entenderlo, es probable que nuestros usuarios tampoco lo hagan
2) proceso de traducción real y cómo funcionaría con nuestro flujo de trabajo

Recomendaría primero pensar más en los detalles de los procesos que necesitamos, y solo luego decidir qué herramienta se adapta mejor a ellos.

Por lo que puedo ver en este momento, tenemos algunas fuentes principales de texto diferentes:

  • Cliente Mudlet en sí mismo
  • Sitio web de Mudlet
  • Wiki Mudlet
  • "otros" textos espontáneos deben incluirse manualmente

Luego, los procesos para cada uno son muy similares, pero deben revisarse por separado:

  • Descubra una forma de diferenciar los textos obsoletos de los textos actuales relevantes que necesitan traducción.
  • Obtenga textos de las fuentes (ver arriba). ¿Se puede automatizar con alguna herramienta? ¿Quién debe ser responsable?
  • Obtener textos en la herramienta de traducción.
  • Herramienta de traducción interna (bueno, esto es de esperar, pero también necesita una buena interfaz y flujos de trabajo)
  • Los traductores informan las cadenas confusas al equipo de Mudlet con información sobre cómo deben ajustarse.
  • El equipo de Mudlet actualiza el texto en la fuente. Ya sea por informes, o por evolución natural.
  • Los textos actualizados de la fuente necesitan actualizaciones en la herramienta de traducción. Exportar e importar de nuevo, más diff.
  • Los textos traducidos estarán terminados. Exportarlos desde la herramienta de traducción. ¿Otra vez automatización?
  • Importar texto traducido a la fuente.
  • Visualización de traducciones en fuente. Aquí necesitaremos algún tipo de interruptor de cambio de idioma en cada fuente.

Noté algunos complementos para Wordpress y Mediawiki, así como la integración en Crowdin y Transifex, pero no tuve mucho tiempo para investigar todo esto con más detalle.

Me encantaría un proceso más automatizado para todos los pasos anteriores, y elegiría la herramienta que mejor se adapte.

En cuanto al código fuente/diálogo (formularios):

  • Descubra una forma de diferenciar los textos obsoletos de los textos actuales relevantes que necesitan traducción.
  • Obtenga textos de las fuentes (ver arriba). ¿Se puede automatizar con alguna herramienta? ¿Quién debe ser responsable?

    • Ambos se realizan con el comando lupdate que extrae los textos fuente de, adivina qué, el código fuente y agrega/actualiza los registros de ellos en el archivo, lo que creo que debería ser neutral en cuanto al idioma, mudlet.ts (el actual mudlet_en.ts señales a algunos partidos que posee específicamente traducciones del idioma inglés - mientras que - con la forma en que va a utilizar como el código fuente ==> medio de transferencia fecha de este apiñamiento se va a utilizar para todos pero el Inglés (americano ) caso. Si no se invoca con la opción --no-obsolete , las cadenas existentes pero ahora desaparecidas no se eliminarán, que es lo que querremos al menos durante las etapas de desarrollo. La razón por la que propongo generar una separada para el en-US locale porque será muy corto y solo contiene cadenas para plurales, es decir, lugares donde tendríamos cadenas de origen como "eliminar %n habitación(es)" de modo que, en ese caso, "eliminar 1 habitación" o Se utilizan "borrar 2 habitaciones".

  • Obtener textos en la herramienta de traducción.

    • El proceso de actualización de la rama de desarrollo debería hacer que suceda lo anterior y que los .ts actualizados se carguen desde (sugiero) la compilación de linux CI (porque es más fácil para nosotros crear una secuencia de comandos)

  • Herramienta de traducción interna (bueno, esto es de esperar, pero también necesita una buena interfaz y flujos de trabajo)
  • Los traductores informan las cadenas confusas al equipo de Mudlet con información sobre cómo deben ajustarse.

    • Parece que crowdin permite que cualquier persona haga un comentario o plantee un problema sobre cualquier cadena de origen que será al menos visible para el administrador (pero puede estar abierto a más partes)

  • El equipo de Mudlet actualiza el texto en la fuente. Ya sea por informes, o por evolución natural.

    • Incluyendo lugares donde el texto fuente es confuso o está mal escrito en la forma esperada en_US, por ejemplo, es posible que haya usado licencia (en-GB sustantivo , cf licencia como verbo en-GB) pero siempre es licencia en en-US para ambas formas.

  • Los textos actualizados de la fuente necesitan actualizaciones en la herramienta de traducción. Exportar e importar de nuevo, más diff.

    • vuelva a ejecutar lupdate , pero esto debería suceder de forma natural a través de secuencias de comandos de CI en las actualizaciones de la rama de 'desarrollo'

  • Los textos traducidos estarán terminados. Exportarlos desde la herramienta de traducción. ¿Otra vez automatización?

    • Uno de nosotros puede "Descargar traducciones" como un conjunto completo de archivos mudlet_xx_YY.ts manualmente desde Crowdin y enviarlos al directorio /translations ; recuerde que estos archivos no se actualizan hasta lupdate excepto, quizás, para los plurales, solo mudlet_en_US.ts , en su lugar, se generan en Crowdin a partir del archivo mudlet.ts .

  • Importar texto traducido a la fuente.

    • No es exactamente lo que se requiere, la aplicación no lee los textos de traducción de los archivos .ts . En cambio, una vez que reviso el código y lo publico, la aplicación mudlet leerá las traducciones en tiempo de ejecución cargando el archivo binario mudlet_xx_YY.qm (junto con el Qt apropiado, que observo que ya estamos distribuir con las versiones del instalador!) Así que inicialmente me imagino que uno de nosotros ejecutará lrelease para convertir los archivos .ts en los archivos correspondientes .qm y enviarlos al repositorio de git como bien. Finalmente, Vadim ha sugerido que enviaremos las versiones de lanzamiento con un conjunto de archivos .qm incluidos como archivo de recursos. Esto es apropiado para las versiones del instalador, pero los empaquetadores de Linux esperarán almacenarlos, por ejemplo, en /usr/share/mudlet/translations solo lectura (junto con los archivos lua externos de Mudlet). Tengo un código prototipo que permitirá que se manejen ambos arreglos, pero al permitir que el usuario cargue archivos de traducción desde otro lugar (posiblemente desde el directorio /translations en el código fuente) permitiría el desarrollo independiente de traducciones para otros idiomas minoritarios por partes interesadas con la herramienta Qt original Linguist - también permitiría a los desarrolladores trabajar en casos privados/de prueba.

  • Visualización de traducciones en fuente. Aquí necesitaremos algún tipo de interruptor de cambio de idioma en cada fuente.

    • A partir de la experimentación, usar QLangaugeEvent es más complejo de lo que necesitamos, ya que se activa cada vez que se llama a QQTranslator::load(...) . Descubrí que es más simple tener la clase emit mudlet emit a (void) signal_translatorChangeCompleted(const QString&, const QString&) donde los argumentos de los códigos xx_YY actuales y anteriores (idioma_PAÍS/REGIÓN) no se usan en gran medida excepto por IIRC el Host que genera un evento lua para script /controladores de eventos del paquete con los que trabajar. Esa señal se envía a cada clase con textos de GUI persistentes a un slot_guiLanguageChange() donde llama al retranslateUi(this) requerido que se define en cada clase que también usa setupUi(this) siempre que configure el opción en Qt IDE correctamente (no sé cómo funciona esto cuando se usa qmake directamente):

      qt_options

      esa llamada cambiará las traducciones en cada cadena traducible en los formularios/diálogo y luego tenemos que regenerar todos los textos de la GUI que creamos en tiempo de ejecución, teniendo en cuenta las condiciones que puedan haber causado que se hayan juntado diferentes textos. Esto no es tan malo como parece porque solo necesitamos alterar la cadena persistente , es decir, existe desde hace mucho tiempo, porque los textos transitorios usarán automáticamente la nueva traducción cada vez que se use tr(...) para crearlos.

Esto no es todo lo que tengo sobre este tema, pero puedo ver cómo la mayoría de los pasos deberían ir para los textos de la GUI de la aplicación...

Gracias por esos detalles SlySven! Me parece, ¿quizás has hecho esto antes? ¿Para otra aplicación? ¿Con Corwdin? Eso facilitaría mucho la traducción de la propia aplicación Mudlet.

Por otro lado, todavía tenemos las mismas preguntas para las otras fuentes de texto en el universo de Mudlet, como la documentación wiki, el sitio web de Mudlet y textos adicionales que pueden necesitar incorporarse de forma manual, como se explica en mi última publicación anterior.

No he revisado completamente la respuesta anterior, pero Crowdin tiene la integración de Github que no tiene en cuenta: https://github.com/Mudlet/Mudlet/pull/1692 es un PR generado automáticamente, no tendremos que hacerlo cualquier carga o descarga manual; simplemente combine los PR. ¡Por lo tanto, el proceso será bastante más simple de lo descrito!

Chicos, la prueba de crowdin expirará en 4 días, así que necesito un sí/no, parece que estamos contentos con él hasta ahora.

Hubo un ¡hurra de mí!

¡Hola! ;)

He intentado https://crowdin.com/ ... para traducirlo de bien, no sé si es bueno para una rápida retroalimentación, solicitudes y así sucesivamente ... como "contestualization" para una traducción o un ejemplo ...

¿Qué pasa con la sección de comentarios en crowdin?

Hola @Joker-ITA,

En realidad, hay varias formas de agregar contexto adicional para los traductores:

1) En el editor, haga clic en "Editar contexto" debajo de la cadena para proporcionar más información a los traductores;
2) Puede dejar un comentario para cualquier cadena en el editor (en el panel derecho, escriba su comentario);
3) Agregue contexto para cualquier cadena a través de la configuración del proyecto -> pestaña Cadenas;
4) Apuesto a que tiene algunos términos específicos que los traductores habituales pueden no entender, por lo que tiene sentido crear un glosario y subirlo a Crowdin. Más información Puede ser incluso una hoja de cálculo de Excel con 2 columnas: Término y descripción;
5) Si tiene comentarios dentro de los archivos (es decir, XML de Android, cadenas de iOS, .properties, .yml, Google Chrome JSON), se importarán automáticamente junto con el archivo;
6) Puede cargar la captura de pantalla en Crowdin y etiquetar cualquier cadena en ella: https://support.crowdin.com/adding-screenshots/
7) Si hablamos de la aplicación web l10n, tiene sentido probar nuestra función en contexto para permitir que los traductores traduzcan directamente en su sitio web.

Son solo formas importantes de contextualizar textos para traducir 😄

@Kebap escribió:

Gracias por esos detalles SlySven! Me parece, ¿quizás has hecho esto antes? ¿Para otra aplicación? ¿Con Corwdin? Eso facilitaría mucho la traducción de la propia aplicación Mudlet.

Solo manualmente usando las propias herramientas de Qt (pasé un par de semanas en el sur de Francia en los últimos años trabajando en los detalles). Todavía usaremos dos de ellos - lupdate & lrelease - pero estamos reemplazando Qt Linguist (siendo la herramienta que agrega las traducciones a los textos originales presentes en un número de .ts archivos generados por lupdate para cada traducción, antes de que lrelease convierta en el idioma/ubicación específico mudlet_xx_YY.qm archivos necesarios, nuevamente uno por traducción de idioma/ubicación ofrecido) con Crowdin que tomará un solo archivo mudlet.ts y generará los archivos mudlet_xx_YY.ts lugar.

Una diferencia importante entre usar linguist y lo que haremos con Crowid es que podemos salir adelante sin:

TRANSLATIONS =

línea en el archivo de proyecto para Crowid.

En realidad, creo que necesitaremos dos archivos: mudlet.ts para todas las configuraciones regionales y que pasarán por el proceso de Crowdin y mudlet_en_US.ts que se extraerán con la opción -pluralonly y solo tendrán algunas traducciones para convertir mensajes como tr("deleted %n room(s)", "", roomCount) a "deleted 1 room" o "deleted 2 rooms" dependiendo del valor de roomCount y probablemente las pueda hacer su servidor...

Genial, vamos con Crowdin :)

Ajustaré el nombre del archivo como sugiere

Respondiendo a las preguntas de @Kebap , teniendo en cuenta la respuesta de @SlySven :

  • Descubra una forma de diferenciar los textos obsoletos de los textos actuales relevantes que necesitan traducción.

    • lupdate herramienta

  • Obtenga textos de las fuentes (ver arriba). ¿Se puede automatizar con alguna herramienta? ¿Quién debe ser responsable?
  • Obtener textos en la herramienta de traducción.

    • ejecutamos manualmente lupdate y los comprometemos a development ; Travis podría automatizar esta parte a diario

    • crowdin los recoge automáticamente debido a la integración de github

  • Herramienta de traducción interna (bueno, esto es de esperar, pero también necesita una buena interfaz y flujos de trabajo)

    • interfaz de traducción de crowdin

  • Los traductores informan las cadenas confusas al equipo de Mudlet con información sobre cómo deben ajustarse.

    • escribe un problema en crowdin

  • El equipo de Mudlet actualiza el texto en la fuente. Ya sea por informes, o por evolución natural.
  • Los textos actualizados de la fuente necesitan actualizaciones en la herramienta de traducción. Exportar e importar de nuevo, más diff.

    • multitud lo recoge

  • Los textos traducidos estarán terminados. Exportarlos desde la herramienta de traducción. ¿Otra vez automatización?
  • Importar texto traducido a la fuente.
  • Visualización de traducciones en fuente. Aquí necesitaremos algún tipo de interruptor de cambio de idioma en cada fuente.

    • @SlySven hará magia aquí :)

¿Cuál es la necesidad de tener un archivo de traducción separado con solo los plurales?

Las instrucciones de traducción están disponibles en https://wiki.mudlet.org/w/Translating_Mudlet

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

Kebap picture Kebap  ·  18Comentarios

vadi2 picture vadi2  ·  19Comentarios

vadi2 picture vadi2  ·  28Comentarios

druuimai picture druuimai  ·  26Comentarios

hluaces picture hluaces  ·  29Comentarios