Archivos de Tags: xmlui - Paginas 2

Traducción al español de Dspace 3.0 disponible

Enviado por cfernandez el 2013/01/11 2 comentarios

Ya está puesta a disposición de la comunidad la traducción al español de la versión 3.0 e interfaz XMLUI. El fichero messages_es.xml está incorporado en la distribución de la versión 3.0, aunque también se encuentra disponible en el ticket jira 1398.

En ese mismo tícket está disponible el fichero de traducción de los mensajes correspondientes al Discovery, y señalar que por premuras de ensamblaje de la versión 3.0, no pudimos incluir la traducción de los módulos SwordClient y XMLWorkflow. Recordar que desde la version 1.8, cada módulo distribuye su propio messages.xml, separado del messages.xml principal, de manera similar a la fragmentación de los ficheros de configuración…

Como en ocasiones anteriores, hemos revisado algunas de las traducciones de mensajes que veníamos arrastrando de versiones anteriores, intentando luchar algo contra el desorden natural de los mensajes…. Pues eso, sean benevolentes.

Traduccion al gallego de Dspace 1.8- XMLUI

Enviado por cfernandez el 2012/11/28 Comentarios desactivados

La traducción al gallego de la interfaz XMLUI de Dspace para versiones 1.8 y anteriores está ya disponible. El fichero messages_gl.xml se encuentra disponible en el ticket jira 1394.

La traducción se ha realizado en el marco de un proyecto para la Universidade de Vigo, revisándose por el Área de Normalización Lingüistica de dicha universidad.

Probamos DSPACE 3.0. Y nos gusta…

Enviado por cfernandez el 2012/10/30 Comentarios desactivados

Pues no pudimos esperar más y nos bajamos e instalamos la Dspace 3.0-rc1 release. Realizamos la décimosegunda descarga, y nosotros pensando que llegábamos tarde….

El proceso de instalación, sobre un Ubuntu 9, Postgresql y Tomcat 6 que estaba en una máquina virtualizada fué nítido y rápido, y voilà, ya teníamos un Dspace3.0 con xmlui para probar. Mientras redactamos una evaluación detenida, os podemos contar algunos de los temas que destacan (y que estábamos esperando) de esta versión. No es una lista exhaustiva de todo lo bueno que contiene esta versión, que es mucho, y que lo podéis encontrar aquí.

Versionado a nivel de item. La historia de un item está disponible y es posible citar una versión particular de un item.

Modificaciones al sistema de embargo. Ya no se require el uso de los crontab (embargo-setter y embargo-lifter) para aplicar las restricciones, sino que se usa el AuthorizationManager, definiéndose una Embargo Resource Policy que hace uso de las fechas de comienzo y fin de las ResourcePolicies. Tendremos que echar una pensada sobre esta implementación. Ya os contaremos.

Mejoras al Discovery. La gente de @atmire sigue marcando diferencias y en esta versión la lista de propuestas para Discovery/Solr es abrumadora: resaltado de keywords, recomendaciones, nuevo tratamiento de las facetas, etc… Y SOBRE TODO:

Han portado el Discovery a JSPUI (gracias al apoyo de la Universidad de Hong Kong). Enhorabuena a los usuarios de JSPUI, ahora tendrán la popsibilidad de usar Discovery
Y Solr tiene en cuenta los derechos de acceso a un item, de modo que detecta que si el usuario no tiene accesos de lectura, ese ítem no se muestra en los resultados en las búsquedas. Para todos aquellos que en un momento dado buscamos ocultar items y colecciones y no lo logramos porque al final aparecían en los resultados de los buscadores, este es un avance sustancial. Habrá que probar esta función en detalle.

Mejoras al sistema de estadísticas. Aparte de que se han incluído estadísticas de search en colecciones/comunidades específicas y estadísticas de los workflow, aparecen una serie de utilidades para el tratamiento de grandes ficheros de log, con el fin de intentar minimizar el problema que generan los logs en instalaciones con mucho tráfico.

Envíos basados en tipo de documentos. Esta era una solicitud que venía de lejos (Google Summer of Code, un ticket jira DS-464, muy antiguo y una adaptación-patch a la versión 1.8 con el código del ticket jira DS-1127). Se dirige a la necesidad de muchos repositorios de adaptar los formularios de envío (input-forms) a los diversos tipos de objetos del repositorio. Hasta ahora la única solución era definir colecciones diferenciadas, cada una con un <form> adaptado. El enfoque ha cambiado, y se han incorporado en los <field> restricciones a su visualización dependiendo de determinadas características de los objetos que se describen. Posiblemente un enfoque más cómodo que el anterior.

OAI 2.0 basado en xOAI, aportado por la empresa Lyncode, antiguos Universidad do Minho y Keep solutions, creo. Permite la creación de sets virtuales, filtrado y transformación. Entendemos que es una reforma completa, o quizá evolución natural del OAIextended, pero basado en un framework OAI mejorado. Lo evaluaremos.

Tratamiento de formatos bibliográficos. Los scripts de importación disponen ahora de una opción que a partir del Biblio-Transformation-Engine es capaz de importar metadatos ¿y bitstreams? de los formatos Endnote, BibTex, RIS, TSV, CSV. Pues esto hay que probarlo en detalle..

Definir un nuevo índice de navegación

Enviado por cfernandez el 2012/08/22 Comentarios desactivados

Además de la búsqueda (search), uno de los mecanismos que ofrecen los repositorios a sus usuarios es la navegación (browse) por sus contenidos, con los usuarios revisando un índice p.ej. de títulos para ver si encuentran contenidos de su interés.

En la mayoría de instalaciones surge la necesidad de redefinir los índices de navegación (Browse indexes), puesto que los cuatro índices (autor, título, fecha y materia) que vienen definidos por defecto en LUCENE, que es el buscador habitual de la mayoría de instalaciones Dspace, en contraposición a SOLR… posiblemente no se adapten suficientemente a las necesidades de nuestra organización. Dspace permite la definición de nuevos índices (incluyendo eliminar o modificar los ya definidos) como parte del proceso de configuración.

En primer lugar, índice se asocia por lo general a metadato, por lo que debemos tener definidos en Dspace los campos de metadatos relevantes, y sobre ellos configurar los índices de navegación.

Lo primero a tener en cuenta es incluir el metadato en el metadata-registry…claro. p.ej. dc.subject.unesco, porque queremos tener un índice de materias unesco.
Localizar la sección configurable browse indexes en dspace.cfg. Y en ella, editar el nuevo índice:
```
 webui.browse.index.(n) = Unesco:metadata:dc.subject.unesco:text
```
para una explicación de la sintaxis de este campo, ver el cajetín al final de este post, y referirse al manual de Dspace. Sobre todo, cuidado con la numeración del índice, ya que deben quedar todos los índices en secuencia ordinal correcta…1,2,3..n , sin saltos, repeticiones…
realizar un index-init, rearrancar tomcat limpiando la memoria caché y el índice ya esta listo para ser usado..
Como el índice es nuevo, no existirán las etiquetas de lenguaje correspondientes. Avisados quedan, son un montón. Navegar sobre el índice recién construido y anotar las nuevas etiquetas, del tipo:
```
 xmlui.ArtifactBrowser.ConfigurableBrowse.title.metadata..........
```
Para XMLUI, incluirlas en el messages.xml y en los messages_xx que use vuestra instalación

¿Sabías que…? si el campo sobre el que se construye el índice es un campo authority controlled, Lucene ofrece simultáneamente al índice «tradicional» un índice adicional sobre ese campo, que se construye únicamente con los valores validados… Para usar ese índice en el dspace.cfg tienes que configurar un nuevo índice con los valores:

webui.browse.index.5 = lcAuthor:metadataAuthority:dc.contributor.author:authority (ejemplo)

Sintaxis
webui.browse.index.<n>=<index name>:<metadata>:<schema prefix>.<element>.<qualifier>:<data-type field>:<sort option>.

Propiedad en dspace.cfg: webui.browse.index.<n>

<index name>: El nombre que queramos dar al índice, relevante para las messages keys

<metadata>: valores posibles “metadata”, “item” o «metadataAuthority»

<schema prefix>.<element>.<qualifier>: el campo dublin core cualificado sobre el que se construye el índice, p.ej.dc.contributor.author. Admite en <qualifier> caracteres de macheo múltiple (*)

<data-type field>: los tipos que permite son «date», «title», «text», «other», «authority» (y podriamos definir otros adicionales relevantes a configuraciones específicas de normalización del índice)

<sort option>: Opcional, puede ser ascendente o descendente.

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

Enviado por cfernandez el 2012/05/11 Comentarios desactivados

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

Enviado por Adán Román el 2012/05/03 9 comentarios

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

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

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:

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

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 el puerto de acceso es correcto, lo cambiamos al nuestro, 8180, 8888, el que usemos:

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

Cuidado, que hay una serie de problemas reportados en JIRA respecto el uso de 127.0.0.1 y el uso de localhost, por lo que quizá se tenga que tantear. (CORREGIDO gracias a la aportación de Javier, de la Universidad de Piura, Perú)

Una vez editados estos ficheros, hay que reiniciar 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 localizar su messages.xml en las 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??

Enviado por cfernandez el 2011/12/09 6 comentarios

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

Enviado por Adán Román el 2011/03/24 Comentarios desactivados

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

« Página anterior

Archivos de Tags: xmlui - Paginas 2

Contenidos