Tag Archives: xmlui

La traducción al español de Dspace 1.8 ya está disponible

Posted by elorenzo on 2012/05/11 None comments

Para los que instaléis, o tengáis instalada, la versión 1.8 y uséis la interfaz XMLUI, ya hemos puesto a disposición de la comunidad la traducción al español de la versión. El nuevo fichero messages_es.xml, a la espera de ser incorporado a los mecanismos estándar de distribución de código es decir, corrección final por el equipo de desarrollo de Dspace.., posiblemente para la anunciada 3.0, se encuentra disponible en el ticket jira 1146..

Comentaros que además de traducir los nuevos mensajes que aparecen en la versión 1.8, hemos realizado un esfuerzo de revisión del resto de mensajes de versiones anteriores. Dado que el messages_es.xml es acumulativo entre versiones, y por tanto compatible hacia atrás, esto quiere decir que se puede usar en versiones anteriores, por lo que quizá sea de interés o valorable la aplicación del parche a versiones 1.7 ó 1.6.

Considerar los términos y cambios a las traducciones anteriores, dentro del contexto del ejercicio interpretativo que es un traducción, por lo general díficil y con múltiples resultados….Acá van algunas temas reseñables:

  • Ciertos mensajes de 1.6 y 1.7 tenian cierta variabilidad de términos (upload se traducía en ocasiones como subir o cargar… y otros)..que en el nuevo fichero messages se ha intentado limitar.
  • Nos hemos quedado a la mitad en el tratamiento del género. Así, preguntamos si está seguro/a de …. pero quien administra Dspace, son los administradores y no hay administradoras. Ser por favor benevolentes ….
  • Y con ciertos términos, suficientes para dejarnos un regustillo de tarea inconclusa, seguimos atrancados. La interpretación de Curator/Curate/curation tasks, etc.. términos que en inglés tienen un sentido claro, pues en español nos asaltan con Curador/Curar/Tareas de curación que posiblemente desconcierten a alguno/a…. y otros más, no muchos, pero como dijimos, algunos haylos.

No obstante, como el messages_es.xml se puede editar, la posibilidad de cambiar términos es evidente… De hecho, estamos seguros que en las decenas de instalaciones que se están realizando en Centro y Sudamérica (el 39% de las visitas a nuestro blog en el último trimestre vienen de vuestro continente, gracias por esas lecturas) ciertos términos de nuestro “techy-español” suenan francamente extraños y lejanos. Y hemos visto personalizaciones de Dspace con un tratamiento del idioma “común” sustancialmente diferentes.

Otro aspecto a considerar. Desde Dspace 1.8, cada módulo incorpora (puede incorporar) su propio messages.xml. No tenemos aún una traducción decente de p.ej (discovery)/messages.xml.. Quizá el próximo mes.

Pues lo dicho, considerar el messages-es.xml de la versión 1.8 como un punto de partida y animaros a realizar variaciones a este fichero. ¿para cuándo, un messages_es_MX o un es_AR o un es_CL?

Activar Mirage y Discovery

Posted by snieto on 2012/05/03 None comments

Una de las principales propuestas de DSpace 1.7 fue la funcionalidad de búsquedas Discovery. Desarrollado, y cedido a la comunidad DSpace, por la empresa AtMire, el sistema de búsquedas por facetas (faceted search) es de indudable atractivo para las nuevas instalaciones y posiblemente imprescindible en instalaciones con un número de items elevado, pues las facilidades de búsqueda en esos entornos necesitan ser “reforzadas”.

Faceted search, also called faceted navigation or faceted browsing, is a technique for accessing information organized according to a faceted classification system, allowing users to explore a collection of information by applying multiple filters (wikipedia)

Para poder manejar correctamente el nuevo sistema de búsquedas, se distribuye conjuntamente con la release, el tema Mirage (y ahora debe quedar claro que hablamos de XMLUI, no de JSPUI) como complemento visual de la funcionalidad Discovery.

En este post va a proceder a explicar como se hace para activar Mirage y Discovery en nuestro Dspace 1.7 o 1.8.

ACTIVACION DE MIRAGE

Tendremos que ir al fichero xmlui.xconf ubicado en [dspace-instalación]/conf/xmlui.xconf

Ahí vamos a quitar los comentarios referentes a la linea

<!–<theme name=”Atmire Mirage Theme” regex=”.*” path=”Mirage/” />–>

Por lo que nos quedaría de la siguiente forma

<theme name=”Atmire Mirage Theme” regex=”.*” path=”Mirage/” />

Una vez hecho esto, debemos comentar el tema que se estuviese usando, normalmente el tema Reference, es decir:

<theme name=”Default Reference Theme” regex=”.*” path=”Reference/” />

y añadirle los comentarios, dejándola así.

<!– <theme name=”Default Reference Theme” regex=”.*” path=”Reference/” /> –>

Por ahora no hemos hecho mas que cambiar un tema por otro. Llega ahora la hora de la verdad, activar el faceted search.

ACTIVACIÓN DE DISCOVERY

Activar Discovery supone en primer lugar sustituir las transformaciones (aspects) relacionadas con la búsqueda de XMLUI por las nuevas transformaciones que supone Discovery. Para ello, en el fichero xmlui.xconf ubicado en la ruta [dspace-instalación]/conf/xmlui.xconf tenemos que desactivar la linea referente al uso del SearchArtifact, y activar la correspondiente al Discovery. Así, hay que comentar la linea siguiente:

<aspect name=”Searching Artifacts” path=”resource://aspects/SearchArtifacts/” />

quedando la línea de la siguiente forma

<!–<aspect name=”Searching Artifacts” path=”resource://aspects/SearchArtifacts/” />–>

y siendo consecuentes, descomentar la línea de Discovery:

<!–<aspect name=”Discovery” path=”resource://aspects/Discovery/” />–>

quedando la línea de la siguiente forma

<aspect name=”Discovery” path=”resource://aspects/Discovery/” />

El siguiente paso que tenemos que modificar el fichero dspace.cfg, cambiando un par de parámetros:

event.dispatcher.default.consumers

y añadirle a la derecha el parámetro discovery quedando de la siguiente forma.

event.dispatcher.default.consumers = search, browse, discovery, eperson, harvester

La siguiente línea a tocar es la siguiente:

recent.submissions.count

En este caso pondremos el parámetro a cero quedando así la línea:

recent.submissions.count=0

Ya estamos finalizando. El último fichero que debemos comprobar es el dspace-sorl-search.cfg, ubicado en la misma carpeta que los anteriores ficheros. Simplemente chequear que la dirección de nuestro dspace/solr coincide con la especificada en el fichero ¿aún no habíamos dicho que Discovery se apoya en SOLR?… Aseguraros que SOLR está desplegado y funcionando en vuestro Tomcat.

Bien, buscamos la línea:

solr.search.server = http://localhost:8080/solr/search

y ahí debemos comprobar que url y puerto son correctas (cuidado, que hay una serie de problemas reportados al respecto). P.ej. si nuestro DSpace estuviese en otra dirección ip, 192.122.111.11, con el puerto 8180, habría que dejar la línea de esta forma:

solr.search.server = http://192.122.111.11:8180/solr/search

Una vez editado estos ficheros, hay que reinciar el tomcat para que se apliquen los cambios y ejecutar en línea de comandos el programa update-discovery-index para que se actualicen los índices del Discovery.

[dspace-instalación]/bin/dspace update-discovery-index

Una vez ejecutada, podemos ver los cambios en nuestro Dspace, un magnífico DSPace con búsqueda por facetas:

Ah, un último punto… las etiquetas/textos que usa Discovery no están traducidas, pues no se incluyen en el messages-es.xml del núcleo de Dspace. La opción más razonable es localizarl su messages.xml en los fuentes de dspace-discovery y copiarlas, es decir añadirlas, al messages_es.xml que usemos de forma habitual (una vez traducidas, claro..)

Suerte (y gracias a Atmire…)

XMLUI o JSPUI??

Posted by elorenzo on 2011/12/09 2 comments

Una cuestión que normalmente  surge en las nuevas instalaciones (o migraciones ) de DSpace es ¿qué interface usar?.

Anteriormente a Dspace 1.5, la interface única  de JSPUI simplificaba la elección :), y este es el motivo de la amplia difusión de los interfaces JSPUI, pero con la aparición de XMLUI es una pregunta recurrente. Intentaremos proporcionar alguna luz, o quizá simplemente alimentar el debate al respecto…  Empecemos:

XMLUI permite de forma extremadamente simple, mucho más que JSPUI, aplicar apariencias radicalmente diferentes a distintas colecciones, lo que resulta de especial relevancia en determinados ámbitos, pensemos en distintas tipologías de objetos por colección, o en diferenciación de la imagen institucional o… motivos diversos los hay, y en ocasiones son causas suficientes para decantarse por XMLUI…

Por otra parte, existe una sensación general de que los nuevos desarrollos de Dspace se alejan de JSPUI, pero nos gustaría confirmarlo con hechos. Algunas de las nuevas funcionalidades presentes en Dspace 1.8 están soportadas únicamente en XMLUI, como el Configurable Reviewer Workflow. De hecho, según se encarga de recordarnos la documentación del 1.8, la activación de esta función “deshabilita” el JSPUI. (realmente no lo deshabilita, simplemente deja de funcionar, pues se altera el esquema de la base de datos…). Y en versiones anteriores, recordamos el Authority Control en Dspace 1.6, la versión JSPUI nos produjo más quebraderos de cabeza que satisfacciones, hablando en plata. Y algunas de las características de un “tema” como Mirage, incluso considerando sus bugs pre-1.8, son inalcanzables, pensamos, para JSPUI.

Pero esto también pudiese ser cierto a la inversa. Al menos hasta la aparición de la versión 1.7, la interfaz de administración de XMLUI iba por detrás de la disponible en JSPUI. Y recordemos que la funcionalidad base para usuarios generales de JSPUI sigue siendo objetivo, a mi entender, aún no alcanzado, de los temas XMLUI como el “Classic”, sin efectuar desarrollos específicos. Lo cual nos lleva al siguiente punto, modificar y desarrollar la interfaz de usuario en una u otra interfaz.

Desarrollar en XMLUI es sustancialmente más complejo que en JSPUI, para funcionalidades “estándar” si es que eso existe. La curva de aprendizaje de XMLUI es mucho más costosa y esforzada, sinceramente. La mezcla de funciones java, seguido de una cadena de transformaciones XSL, todo embutido en un framework Apache Cocoon, resulta compleja de entender. XMLUI no funciona bajo una lógica “una plantilla-una página”, sino bajo una lógica “diversas plantillas- una página” y, simultáneamente “una plantilla- diversas páginas”. Lo cual complica la concepción del sistema así creado…

Bien, existen más diferencias, y sobre todo más opiniones sobre las mismas, que las planteadas en la breves líneas anteriores

¿y Vds, que opinan?.

ARVO contribuye a la comunidad: Mensajes para XMLUI en español para DSpace

Posted by snieto on 2011/03/24 None comments

La mayoría de nuestros clientes utiliza la interfaz XMLUI para DSpace. Los mensajes de dicha interfaz se encuentra en el fichero messages_xx.xml donde xx es el código del idioma. ARVO ha traducido los nuevos mensajes que aparecen en las versiones 1.6 y 1.7 al español y lo ha puesto a disposición de la comunidad DSpace proporcionando el fichero “messages_es.xml”. Este fichero lo podemos encontrar en:

[dspace_installation]/webapps/xmlui/i18n/messages_es.xml

El procedimiento se resume en:

  • Registro en JIRA de DSpace: https://jira.duraspace.org/
  • Añadir un nuevo “Issue” como “improvement” (es decir notificar una mejora)
  • Rellenar con las versiones afectadas, ficheros adjuntos, documentación etc…( si procede )
  • Se crea automáticamente un ticket: en nuestro caso fue el 837 https://jira.duraspace.org/browse/DS-837
  • Pasa a un estado de “pendiente de revisión”
  • Cuando una persona se lo asigna, lo revisa: “Updated”
  • y cuando lo termina: “Resolved”

Todas estas notificaciones se informan en la lista de correo de los desarrolladores: [dspace-devel] de manera que en todo momento estamos informados de la situación de nuestra contribución.

Agradecer desde aquí a:

  • Bram Luyten de @mire por los consejos para desarrolladores
  • Claudia Juergen de la Universitaetsbibliothek Dortmund quien resolvió el track de JIRA
  • Francisco Javier Herrero de la Universitat Jaume I de Castellón, autor de la traducción base de DSpace 1.5