Xsl + java

lusop · #1 (**permalink**) 06/05/2010, 08:41

Buenas,

En mi empresa tienen una web medianamente grande hecha en xsl. Actualizan de vez en cuando un fichero xml del que tira este XSL. Lo que ocurre es que tienen todo hecho una vez para cada idioma y quieren usar i18n (internacionalizaci'on). Es decir, usar una caracter'istica de las jsp dentro de las xsl.

Hab'iamos dicho que lo pas'abamos a java y listo, pero me han pedido hacerlo en dos pasos: primero meter lo de la i18n, dejando lo de las xsl, y despu'es de hacer otrtas cosas m'as urgentes, pasarlo todo a JSP. Hab'ia pensado al principio que sin problema, pero acabo de caer de que no puede hacerse. Las cadenas que queiren traducir est'an inclu'idas dentro de los XSL, por lo que habr'ia que sacarlas de ah'i, no?

Las cadenas que tengan que ser traducidas tienen que estar en la JSP y, desde esas JSP, llamar a la xsl para que se ejecute sobre un xml. No s'e si me explico. Hay que pasarlo todo a java o, por lo menos, sacar todas las cadenas de los xsl, no?

Gracias

lusop · #2 (**permalink**) 11/05/2010, 10:02

Bueno, no ha habido manera. Por si a alguien le interesa, la soluci'on adoptada ha sido crear una pequena aplicaci'on que toma todas las cadenas traducibles de los ficheros contenidos en el directorio y las sustituye con un tag:

<html><head><title>hola</title...

pasa a ser

<html><head><title><translate>message_000001</title...

y en un fichero excel guarda

message_000001\thola

Y luego otra aplicaci'on coge el excel del idioma que sea y sustituye al rev'es.

GreenEyed · #3 (**permalink**) 11/05/2010, 13:04

Nosotros hacemos aplicaciones internacionalizadas con XML/XSLT y lo que hacemos es separar las cadenas en ficheros XML y luego incluimos ese XML para ser procesado junto con los datos. En funcion del idioma, se incluye un XML u otro y luego desde la XSL basta hacer referencia a las etiquetas como si fueran datos normales y listo.

S!

lusop · #4 (**permalink**) 12/05/2010, 02:31

Claro, pero es que nosotros importamos datos desde otro xml que define la composici'on de la web en s'i (nodos, temas, etc...) y, al menos que yo sepa, no puedo usar dos xml distintos en el mismo xsl, no?

Fuzzylog · #5 (**permalink**) 12/05/2010, 02:34

pero lusop, ¿Para eso no existen las transformadas xsl? (mas conocidas como XSLTs)

GreenEyed · #6 (**permalink**) 12/05/2010, 03:15

Se pueden juntar varios XML en uno antes de procesarlos con la XSL, o se puede usar la funcion document() dentro de la XSLT para "importar" un XML externo y accederlo.

S!

lusop · #7 (**permalink**) 12/05/2010, 05:56

Cita:

Iniciado por Fuzzylog

pero lusop, ¿Para eso no existen las transformadas xsl? (mas conocidas como XSLTs)

para importar desde m'as de un archivo? c'omo se hacen las referencias?

lusop · #8 (**permalink**) 12/05/2010, 05:59

Cita:

Iniciado por GreenEyed

Se pueden juntar varios XML en uno antes de procesarlos con la XSL, o se puede usar la funcion document() dentro de la XSLT para "importar" un XML externo y accederlo.

S!

A ver, el problema es que no tengo los mensajes en un xml. De hecho, lo intentamos evitar a prop'osito, y queremos tenerlo en ficheros tipo properties:

mensaje1 Bienvenido
mensaje2 Hola

As'i que, al final, te tienes que crear una aplicaci'on que te pase esto a xml por en medio cada vez que hay atraducci'on (que est'as en las mismas)

Fuzzylog · #9 (**permalink**) 12/05/2010, 06:17

Pues entonces este es el objetivo...

http://www.google.es/search?hl=es&so...=&oq=&gs_rfai=

Busca por ahi a ver si encuentras algun resultado que te valga y trata de variar la consulta para encontrar algo al respecto.

Suerte

GreenEyed · #10 (**permalink**) 12/05/2010, 06:44

Pues si los quereis usar desde una XSLT, lo mejor es tenerlo en formato XML, puesto que las XSTL son buenas transformando ese tipo de ficheros.

Si quereis mantener las XSL y los mensajes en properties, se podría hacer un programa que lea un fichero de properties y lo devuelva on-the-fly en formato XML. Pero vamos sólo es una idea.

S!

lusop · #11 (**permalink**) 12/05/2010, 10:50

Cita:

Iniciado por GreenEyed

Pues si los quereis usar desde una XSLT, lo mejor es tenerlo en formato XML, puesto que las XSTL son buenas transformando ese tipo de ficheros.

Claro, si el problema es el panorama que me he encontrado. Yo no lo hubiera hecho as'i desde el principio, pero... quieren usar las XSL y tener los lenguajes en formato properties

Cita:

Iniciado por GreenEyed

Si quereis mantener las XSL y los mensajes en properties, se podría hacer un programa que lea un fichero de properties y lo devuelva on-the-fly en formato XML. Pero vamos sólo es una idea.

No es mala idea, pero si cada vez que recibamos una petici'on, hay que pasar de texto a xml 30000 l'ineas y luego parsear el resultado, me parece mucha tralla para cada petici'on (que es lo que ocurrir'ia siendo XSL).

De todos modos, la aplicaci'on est'a ya hecha, pero muchas gracias!

GreenEyed · #12 (**permalink**) 12/05/2010, 11:24

Pues sí, con 30.000 lineas no es cosa de hacerlo cada vez. Se podría hacer sólo cuando haya cambios en las propiedades, pero vamos, como dices es un poco problematico por ser una posible fuente de errores por falta de sincronización. Habría que hacerlo con cuidado.

Es el problema de las migraciones a medias

.

Suerte!

PD: A todo esto, el framework que usamos nosotros lo que te permite es definir "fuentes de datos" XML y un tipo de fuente son los ficheros simples, los cuales puedes internacionalizar poniendo el locale a un valor, y entonces en vez de cargarte fichero.xml, te carga fichero_locale.xml.
Ya se que lo teneis hecho y no os servirá, pero por si sirve de idea...

PPD: Si vais a migrar a JSP, no se si lo habreis planteado pero las facilidades que tienen las XSLT para reutilizar macros no las tienen los JSP, a base de includes puede ser un infierno. Nosotros en estos casos usamos SiteMesh para reutilizar el "layout" y evitar al máximo los includes. Las JSP no es algo que usemos mucho por que no nos matan demasiado.