Tenemos que crear una aplicación multidioma. Todos los textos de todos los formularios tienen que estar en el idioma de la empresa que entra. Tenemos varias opciones pero son muy costosas. ¿Alguien se ha planteado alguna vez esta posibilidad? ¿A alguien se le ocurre algo?...
Gracias por vuestra ayuda de antemano y felices fiestas a todos...
Aplicación multidioma
Moderador: vCoaches
Aplicación multidioma
vSaludos...
Amadís
Axos Soluciones Visuales
Software Gestión Distribución
Web: http://www.axosvisual.com
Amadís
Axos Soluciones Visuales
Software Gestión Distribución
Web: http://www.axosvisual.com
Algo dificil tu problema . La única solución que yo le veo hasta que en Velneo salga la versión multiidioma es que con condiciiones de visibilidad de los textos. tendrás que traducirlos todos y en una opción de inicio, guardarte en una variable el idiima elegidol Un cartel será visiible si ha seleccionado su idiioma previamente.
FELICES FIESTAS A TODOS
FELICES FIESTAS A TODOS
-
Adelo Herrero
- vAdviser
- Mensajes: 714
- Registrado: 21 Sep 2005, 14:42
vamos a ver si digo una tonteria para empezar el día 
Tienes la traducción de los campos en ficheros de texto que se podrían llamar ..."idioma.txt" con un formato similar a xml
<FOR_CLI>
CAMPO1
CAMPO2
CAMPO3
</FOR_CLI>
<FOR_F_PAGO>
CAMPO1
CAMPO2
</FOR_F_PAGO>
También necesitarás un chorro de variables globales del tipo:
$NOMBRE_CAMPO_1$, $NOMBRE_CAMPO_2$ ...
En el oninit del formulario tienes un proceso en el que:
1.- Abres el fichero del idioma (según empresa)
2.- vas a la etiqueta del formulario que estás abriendo y asignas a las variables el valor correspondiente.
Como es lógico, en el formulario, los nombres de campos serán las variables globales.
Que digo yo, que no lo he probado, pero supongo que funcionaría.
Por lo menos, si lo pruebas nos dices algo ¿vale?
Tienes la traducción de los campos en ficheros de texto que se podrían llamar ..."idioma.txt" con un formato similar a xml
<FOR_CLI>
CAMPO1
CAMPO2
CAMPO3
</FOR_CLI>
<FOR_F_PAGO>
CAMPO1
CAMPO2
</FOR_F_PAGO>
También necesitarás un chorro de variables globales del tipo:
$NOMBRE_CAMPO_1$, $NOMBRE_CAMPO_2$ ...
En el oninit del formulario tienes un proceso en el que:
1.- Abres el fichero del idioma (según empresa)
2.- vas a la etiqueta del formulario que estás abriendo y asignas a las variables el valor correspondiente.
Como es lógico, en el formulario, los nombres de campos serán las variables globales.
Que digo yo, que no lo he probado, pero supongo que funcionaría.
Por lo menos, si lo pruebas nos dices algo ¿vale?
Adelo Herrero Pérez
adelo@adinf.es
www.adinf.es
http://maps.google.es/maps?q=39.490701,-1.102329
Tel. +34 962 303 152
adelo@adinf.es
www.adinf.es
http://maps.google.es/maps?q=39.490701,-1.102329
Tel. +34 962 303 152
-
Adelo Herrero
- vAdviser
- Mensajes: 714
- Registrado: 21 Sep 2005, 14:42
Aclaración (por si acaso):
Ficha de empresa: Le decimos el nombre del fichero .txt que ha de leer, p.e. aleman.txt
De esta forma, si añadimos un nuevo idioma, solamente necesitamos crear otro fichero de "nombres de campo" o "literales en formularios, informes, etc." traducido y nuestro proceso será "transparente". Lo malo, es que si añadimos un campo nuevo en un formulario, necesitaremos actualizar cada fichero de idiomas, pero claro, no se puede tener todo.
Jo, ahora estoy intrigado, mmm voy a ver si algun cliente necesita una aplicación multiidioma y así lo pruebo
Ficha de empresa: Le decimos el nombre del fichero .txt que ha de leer, p.e. aleman.txt
De esta forma, si añadimos un nuevo idioma, solamente necesitamos crear otro fichero de "nombres de campo" o "literales en formularios, informes, etc." traducido y nuestro proceso será "transparente". Lo malo, es que si añadimos un campo nuevo en un formulario, necesitaremos actualizar cada fichero de idiomas, pero claro, no se puede tener todo.
Jo, ahora estoy intrigado, mmm voy a ver si algun cliente necesita una aplicación multiidioma y así lo pruebo
Adelo Herrero Pérez
adelo@adinf.es
www.adinf.es
http://maps.google.es/maps?q=39.490701,-1.102329
Tel. +34 962 303 152
adelo@adinf.es
www.adinf.es
http://maps.google.es/maps?q=39.490701,-1.102329
Tel. +34 962 303 152
Buenos dias:
Varias cosas:
1.- El sistema que propone Adelo funciona bien:
En su día hice algo parecido, pero guardo los textos en una tabla, en lugar de utilizar un txt. Se trataba de una opción de ofertas multi-idioma dentro de un CRM desarrollado completamente en inglés. La aplicación se usa en varios paises europeos y los clientes de cada pais demandan las ofertas en su idioma natal... así que hubo que romperse la cabeza para hacerlo.
En mi caso los textos están en una tabla y el idioma se selecciona a la hora de confeccionar (o imprimir, para los informes impresos también se puede utilizar) la oferta. Esto es así porque, p. ej., un comercial alemán puede hacer una oferta a un cliente holandés y no sirven los textos en alemán.
Como digo funciona bien para formularios e informes.
2.- Rejillas, búsquedas, localizadores, etc:
Pero si quieres que toda la aplicación sea multi-idioma, no te basta con cambiar los formularios y los informes. Tienes que poder cambiar los textos de todos los objetos (Localizadores, búsquedas, rejillas, etc) y esto es otra historia.
Como sabes los textos de las búsquedas, rejillas, localizadores, no son variables.
Puedes solventar el título de las rejillas añadiéndolas como retornos e indicando el texto en el idioma correcto. Esto implica que no podrás disparar búsquedas directamente desde los menús, tendrás que utilizar siempre procesos.
Si embargo los nombres de las búsquedas y localizadores no tienen solución. Están prefijados y no puedes cambiarlos en ejecución... en mi caso tengo la suerte de que la matriz de la multinacional es americana y el idioma oficial es el inglés. Por lo tanto escribo todo en inglés y problema resuelto, pero tu caso sería distinto.
3.- Menús del Irunner:
Pero además tienes otro problema de difícil solución: Los menús, mensajes de error, preguntas, etc del Irunner.
Todos estos textos están en castellano e incluidos dentro del EXE, con lo cual no podrás cambiarlos dinámicamente. Si te curras la aplicación para que los forms, rejillas e informes sean multi-idioma el ejecutor, hoy por hoy, no lo será.
En su día (previo permiso por escrito de Atica Software, S.L.) traduje al inglés una copia del Irunner de la versión 6.1.10. Esto lo hice con un editor de recursos y cambiando las cadenas a pedal. Lo necesitaba para poder cambiar la versión del motor a mi cliente y me puse a hacerlo.
El resultado de la aventura sigue funcionando hoy en día, pero la traducción no pudo ser completa... digamos que al 98%.
Determinadas cosas no pueden ser traducidas ni utilizando esta técnica:
- Nombres de los meses en los objetos calendario.
- Texto "Fichas" de la toolbar de las rejillas.
- Texto de los botones en los cuadros de diálogo estandard (aunque no se si esto varía en función del idioma del windows que ejecuta la aplicación).
...
La única opción que te queda es traducir el Irunner a tantos idiomas como vayas a manejar en la aplicación... árdua tarea, pero posible. A cada cliente le instalarias el Irunner adecuado según su idioma.
Tendrías que obtener permiso de Velneo para ello, ya que hacerlo sin permiso es ilegal.
Resumiendo: Con la versión actual puedes "simular" un comportamiento multi-idioma con mucho trabajo ( créeme que es mucho ) pero no será, ni mucho menos, un multi-idioma real.
Una vez soltado este tostón creo que lo mejor sería esperar a la versión 7. De todas formas es decisión vuestra el emprender el desarrollo o no.
Por mi parte puedo aportar el Irunner de la versión 6.1.10 en inglés. Se lo tendrías que pedir a Velneo, ya que yo tengo permiso para utilizarlo pero no para distribuirlo.
Varias cosas:
1.- El sistema que propone Adelo funciona bien:
En su día hice algo parecido, pero guardo los textos en una tabla, en lugar de utilizar un txt. Se trataba de una opción de ofertas multi-idioma dentro de un CRM desarrollado completamente en inglés. La aplicación se usa en varios paises europeos y los clientes de cada pais demandan las ofertas en su idioma natal... así que hubo que romperse la cabeza para hacerlo.
En mi caso los textos están en una tabla y el idioma se selecciona a la hora de confeccionar (o imprimir, para los informes impresos también se puede utilizar) la oferta. Esto es así porque, p. ej., un comercial alemán puede hacer una oferta a un cliente holandés y no sirven los textos en alemán.
Como digo funciona bien para formularios e informes.
2.- Rejillas, búsquedas, localizadores, etc:
Pero si quieres que toda la aplicación sea multi-idioma, no te basta con cambiar los formularios y los informes. Tienes que poder cambiar los textos de todos los objetos (Localizadores, búsquedas, rejillas, etc) y esto es otra historia.
Como sabes los textos de las búsquedas, rejillas, localizadores, no son variables.
Puedes solventar el título de las rejillas añadiéndolas como retornos e indicando el texto en el idioma correcto. Esto implica que no podrás disparar búsquedas directamente desde los menús, tendrás que utilizar siempre procesos.
Si embargo los nombres de las búsquedas y localizadores no tienen solución. Están prefijados y no puedes cambiarlos en ejecución... en mi caso tengo la suerte de que la matriz de la multinacional es americana y el idioma oficial es el inglés. Por lo tanto escribo todo en inglés y problema resuelto, pero tu caso sería distinto.
3.- Menús del Irunner:
Pero además tienes otro problema de difícil solución: Los menús, mensajes de error, preguntas, etc del Irunner.
Todos estos textos están en castellano e incluidos dentro del EXE, con lo cual no podrás cambiarlos dinámicamente. Si te curras la aplicación para que los forms, rejillas e informes sean multi-idioma el ejecutor, hoy por hoy, no lo será.
En su día (previo permiso por escrito de Atica Software, S.L.) traduje al inglés una copia del Irunner de la versión 6.1.10. Esto lo hice con un editor de recursos y cambiando las cadenas a pedal. Lo necesitaba para poder cambiar la versión del motor a mi cliente y me puse a hacerlo.
El resultado de la aventura sigue funcionando hoy en día, pero la traducción no pudo ser completa... digamos que al 98%.
Determinadas cosas no pueden ser traducidas ni utilizando esta técnica:
- Nombres de los meses en los objetos calendario.
- Texto "Fichas" de la toolbar de las rejillas.
- Texto de los botones en los cuadros de diálogo estandard (aunque no se si esto varía en función del idioma del windows que ejecuta la aplicación).
...
La única opción que te queda es traducir el Irunner a tantos idiomas como vayas a manejar en la aplicación... árdua tarea, pero posible. A cada cliente le instalarias el Irunner adecuado según su idioma.
Tendrías que obtener permiso de Velneo para ello, ya que hacerlo sin permiso es ilegal.
Resumiendo: Con la versión actual puedes "simular" un comportamiento multi-idioma con mucho trabajo ( créeme que es mucho ) pero no será, ni mucho menos, un multi-idioma real.
Una vez soltado este tostón creo que lo mejor sería esperar a la versión 7. De todas formas es decisión vuestra el emprender el desarrollo o no.
Por mi parte puedo aportar el Irunner de la versión 6.1.10 en inglés. Se lo tendrías que pedir a Velneo, ya que yo tengo permiso para utilizarlo pero no para distribuirlo.
Un saludo,
Francisco Javier Pérez Novo
EfeUno Consultores de Gestión y Software, S.L.
fjpnovo@efeuno.org
http://www.efeuno.org
(+34) 91 519 44 86
Skype: Fran-EfeUno
Google Maps:
40.447943147972445, -3.6719655990600586
Francisco Javier Pérez Novo
EfeUno Consultores de Gestión y Software, S.L.
fjpnovo@efeuno.org
http://www.efeuno.org
(+34) 91 519 44 86
Skype: Fran-EfeUno
Google Maps:
40.447943147972445, -3.6719655990600586
Sólo me queda decir: esperemos que la versión 7 salga pronto... Gracias a todos y felices fiestas...
vSaludos...
Amadís
Axos Soluciones Visuales
Software Gestión Distribución
Web: http://www.axosvisual.com
Amadís
Axos Soluciones Visuales
Software Gestión Distribución
Web: http://www.axosvisual.com