Antes que nada, gracias por el largo y detallado comentario. Me he enterado de unas cuantas cosas. Por ejemplo de que el problema con componentes "raritos" es común a todos los programas. Lo he mencionado en alguna historia anterior: fue un error de diseño dar tanta libertad a los programadores de componentes para usar y abusar del DFM.
Mi consejo es que no uses el ITE. Yo sí lo he usado para más que pruebas y no va. Si te metes por ese camino, vas a tener problemas y van a salir cuando sea demasiado tarde. El que avisa no es traidor :-) No sé si has visto el enlace, pero ya he escrito sobre el Translation Manager antes. Ese programa tiene agujeros por todas partes. El que he probado yo es el externo, pero el integrado no creo que sea mejor, al contrario.
Respecto a cómo lo hacemos, no he dado la información completa, y eso es en parte porque no hemos creado una herramienta completa, sino que se ha quedado a medias. A ver si puedo aclarar un poco más.
Lo de que se pueda cambiar en tiempo de ejecución en vez de tener tres ejecutables, es perfectamente posible. ¿Que por qué no lo hemos hecho así? La base de datos es distinta para cada idioma, así que no se puede tener ejecutables para los dos idiomas, sino que a cada cliente se le manda el del suyo. Hay una manera de cargar un DFM distinto en tiempo de ejecución (con TForm.CreateNew) o simplemente se puede usar el mismo sistema que el Translation Manager y generar una DLL distinta para cada idioma. CreateNew habría sido laborioso, ya que hubiese tenido que repasar el código para cambiar la forma de creación de los formularios. Lo de generar la DLL no tenía incentivo, aunque igual a ti sí te interesaría. Si es así, puedes echar un vistazo a lo que hace el Translation Manager y hacer lo mismo.
Lo que quieres de poder comprobar en el IDE si ha quedado bien sin compilar también es posible apañarlo con un .BAT. Cambias los DFM del idioma por los del castellano, repasas los formularios y después vuelves a ponerlo como estaba. Pero evidentemente ya estamos en un terreno resbaladizo. ¿Qué ocurre si cambias el tamaño de algo para hacer sitio a una cadena más larga? Es donde se manifiesta que tenemos una heramienta a medias.
A nosotros nunca nos ocurre el problema de los tamaños, siempre son cambios de cadenas por otras, será porque hay espacio y no están los controles apiñados. En caso contrario habría que tenerlo montado bien: tener una base de datos con todas las propiedades, valor original, un flag para decidir si se va a traducir o no, un repositorio aparte, etcétera. Después de cada operación, bien sea importando, bien sea editando visualmente, habría que examinar los cambios, detectar las diferencias y actualizar la base de datos. Todo es factible, pero es laborioso, el tipo de trabajo que se espera de una herramienta de pago. Pero ya ves cómo está la cosa :-)
Lo que dices de que con mi sistema hay que tener ficheros de recursos adicionales no lo veo. Eso lo necesitas para cualquier sistema que tengas. Si usas resourcestring, puedes meter las cadenas en una DLL de idioma. Pero de nuevo: eso lo puedes hacer de todas formas.
En fin, no sé qué más te puedo contar, salvo que la herramienta del KDE en efecto está bien (la usé con Drupal hace tiempo) y que si quieres te envío el código del filtro de DFM como está (incompleto).
Información incompleta
Antes que nada, gracias por el largo y detallado comentario. Me he enterado de unas cuantas cosas. Por ejemplo de que el problema con componentes "raritos" es común a todos los programas. Lo he mencionado en alguna historia anterior: fue un error de diseño dar tanta libertad a los programadores de componentes para usar y abusar del DFM.
Mi consejo es que no uses el ITE. Yo sí lo he usado para más que pruebas y no va. Si te metes por ese camino, vas a tener problemas y van a salir cuando sea demasiado tarde. El que avisa no es traidor :-) No sé si has visto el enlace, pero ya he escrito sobre el Translation Manager antes. Ese programa tiene agujeros por todas partes. El que he probado yo es el externo, pero el integrado no creo que sea mejor, al contrario.
Respecto a cómo lo hacemos, no he dado la información completa, y eso es en parte porque no hemos creado una herramienta completa, sino que se ha quedado a medias. A ver si puedo aclarar un poco más.
Lo de que se pueda cambiar en tiempo de ejecución en vez de tener tres ejecutables, es perfectamente posible. ¿Que por qué no lo hemos hecho así? La base de datos es distinta para cada idioma, así que no se puede tener ejecutables para los dos idiomas, sino que a cada cliente se le manda el del suyo. Hay una manera de cargar un DFM distinto en tiempo de ejecución (con TForm.CreateNew) o simplemente se puede usar el mismo sistema que el Translation Manager y generar una DLL distinta para cada idioma. CreateNew habría sido laborioso, ya que hubiese tenido que repasar el código para cambiar la forma de creación de los formularios. Lo de generar la DLL no tenía incentivo, aunque igual a ti sí te interesaría. Si es así, puedes echar un vistazo a lo que hace el Translation Manager y hacer lo mismo.
Lo que quieres de poder comprobar en el IDE si ha quedado bien sin compilar también es posible apañarlo con un .BAT. Cambias los DFM del idioma por los del castellano, repasas los formularios y después vuelves a ponerlo como estaba. Pero evidentemente ya estamos en un terreno resbaladizo. ¿Qué ocurre si cambias el tamaño de algo para hacer sitio a una cadena más larga? Es donde se manifiesta que tenemos una heramienta a medias.
A nosotros nunca nos ocurre el problema de los tamaños, siempre son cambios de cadenas por otras, será porque hay espacio y no están los controles apiñados. En caso contrario habría que tenerlo montado bien: tener una base de datos con todas las propiedades, valor original, un flag para decidir si se va a traducir o no, un repositorio aparte, etcétera. Después de cada operación, bien sea importando, bien sea editando visualmente, habría que examinar los cambios, detectar las diferencias y actualizar la base de datos. Todo es factible, pero es laborioso, el tipo de trabajo que se espera de una herramienta de pago. Pero ya ves cómo está la cosa :-)
Lo que dices de que con mi sistema hay que tener ficheros de recursos adicionales no lo veo. Eso lo necesitas para cualquier sistema que tengas. Si usas resourcestring, puedes meter las cadenas en una DLL de idioma. Pero de nuevo: eso lo puedes hacer de todas formas.
En fin, no sé qué más te puedo contar, salvo que la herramienta del KDE en efecto está bien (la usé con Drupal hace tiempo) y que si quieres te envío el código del filtro de DFM como está (incompleto).