Proceso para la localización de la aplicación Delphi 2009 por traductores voluntarios?

Question

Tengo una aplicación científica freeware que es utilizada por miles de personas en casi 100 países. Muchos han ofrecido traducir gratis. Ahora que D2009 hace que esto sea más fácil (con herramientas de localización integradas y externas, además del soporte nativo de Unicode) me gustaría hacer que esto suceda para algunos idiomas y agregar constantemente tantos como soporte la energía del usuario.

Estoy pensando que voy a distribuir una hoja de cálculo con una lista de cadenas (docenas pero no cientos) para traducir, hacer que la devuelvan y comparar las presentaciones en el mismo idioma de 2-3 usuarios luego trabajar para resolver discrepancias por consenso. Luego incorporaré las localizaciones usando Integrated Translation Environment y distribuiré las actualizaciones localizadas.

¿Alguien ha delegado la traducción a los usuarios? ¿Algún atraso, específico de D2009 o de otro modo?

EDITAR: ¿Alguien ha comparado el soporte de localización integrado en D2009 versus dxgettext?

Answer 1

Nunca he sido amigo de las herramientas de localización patentadas para aplicaciones de software libre o de código abierto. Usando dxgettext, el puerto de Delphi GNU gettext parece una opción mucho mejor para mí:

• Integración en el programa (incluso mucho más tarde que su desarrollo) es fácil.
• La extracción de cadenas traducibles se puede realizar mediante programas de línea de comandos y, por lo tanto, se introduce fácilmente en una compilación automatizada.
• Se puede agregar una nueva traducción simplemente creando un nuevo directorio con la estructura correcta, copiando el archivo de traducción vacío en él y comenzando a traducir las cadenas. Esto es algo que cada usuario puede hacer por sí mismo, no es necesario involucrar al autor original para la creación de una nueva traducción. También hay gratificación instantánea con este proceso: una vez que se reinicia el programa, las nuevas traducciones se muestran de inmediato.
• Cambiar una traducción existente es incluso más fácil que crear una nueva. Por lo tanto, si un usuario encuentra ortografía u otros errores o necesita mejoras en la traducción, puede corregirlos fácilmente y enviar los cambios al autor.
• Las nuevas versiones de programa funcionan con traducciones antiguas, el sistema se degrada muy bien: las cadenas nuevas y sin traducir simplemente se muestran sin modificaciones.
• Las traducciones se pueden hacer utilizando solo bloc de notas, pero también hay varias herramientas gratuitas para crear y gestionar archivos de traducción; vea los enlaces en la página dxgettext. Ellos mismos están localizados, y tienen algunas ventajas sobre una hoja de cálculo, así:
  • La ubicación de las cadenas en el código fuente puede demostrar (sólo tiene sentido para las aplicaciones de código abierto, por supuesto).
  • Se muestra el porcentaje de cadenas traducidas.
  • Las modificaciones a cadenas ya traducidas también están resaltadas.
• Todo el sistema es maduro y resistente al futuro - He usado dxgettext para programas Delphi 4, y no debería haber cambios necesarios para Delphi 2009 incluso - los archivos de traducción siempre han sido codificados con UTF-8.

El uso de una hoja de cálculo para la traducción no me parece una solución factible una vez que tiene más de unos pocos idiomas. Supongamos que una nueva versión de programa agrega 2 cadenas nuevas y cambia 10 cadenas solo ligeramente: ¿no sería necesario agregar las nuevas cadenas y resaltar las cadenas modificadas en todas las varias docenas de hojas de cálculo y enviarlas nuevamente a sus traductores? Usando dxgettext solo envía por correo el archivo po cambiado a todos ellos.

Editar:

Hay un comentario interesante acerca de los problemas que puede haber con dxgettext y bibliotecas. Nunca experimenté esto, ya que he dejado de usar cadenas de recursos por completo. La mayor parte de nuestros programas están en alemán, y solo unos pocos están en inglés o traducidos a varios idiomas.

Nuestras bibliotecas internas usan "_ (...)" alrededor de todas las cadenas traducibles. Hay define ENGLISH y USEGETTEXT que se establecen por proyecto. Si se definen ENGLISH o USEGETTEXT, los textos en inglés se compilan en las DCU, de lo contrario, el texto en alemán se compila en las DCU. Si USEGETTEXT no está definido, "_()" se compila como una función que devuelve su parámetro tal como está, de lo contrario se utiliza la búsqueda de traducción de dxgettext.

Answer 2

Tengo ... Puede haber algunos desafíos.

• una cadena no significa mucho en sí misma, necesita un contexto.
• corolario, la misma cadena puede necesitar tener más de una traducción.
• screen real estate: tenga en cuenta la duración variable dependiendo del idioma, por ejemplo, el francés tiende a ser más detallado que el inglés.
• a menos que sea competente en un idioma determinado, no podrá evaluar las discrepancias.

Answer 3

He usado TsiLang Translation Suite para permitir que los usuarios finales traduzcan. Modifiqué el código para permitir el cifrado, de modo que si alguien hace un buen trabajo, puede proteger su nombre contra un archivo de traducción, pero en general la idea es que las personas puedan compartir sus traducciones y agregar/editar cualquier parte pequeña que deseen. Dado que todo sucede dentro de la aplicación, y con visibilidad instantánea, funciona muy bien.

Answer 4

Como ha mencionado, D2009 viene con herramientas de localización. ¿Por qué no simplemente usarlos? AFAIK puede distribuir el administrador de traducción externo (etm.exe). ¿Necesitas algo más?

Además, la localización es más que solo traducir texto. ETM también admite la traducción de recursos .dfm.

Answer 5

Para completar, aquí hay otra herramienta de localización de Delphi llamada Delphi Localizer. Recientemente encontré que parece estar bien diseñada y pulida. La herramienta es gratuita para uso comercial con la excepción de los proyectos gubernamentales (no estoy seguro de por qué la excepción).

FWIW He utilizado TsiLang Translation Suite en el pasado y actualmente estoy trabajando en otro proyecto utilizando las herramientas de localización incluidas con DevExpress VCL. Lo último se integra muy bien con sus componentes y con los componentes de terceros.