Archivos de Tags: language packs

Traducción al español de Dspace 5 (y 4) disponible

Ya está puesta a disposición de la comunidad DSpace la traducción al español de la versión 5.0 e interfaz XMLUI. El fichero messages_es.xml y el resto de ficheros de idiomas de la release está incorporado en la distribución de la versión 5.0, además de encontrarse ya disponible en el ticket jira 2233 o en el github

Así, está disponible el fichero de traducción de los mensajes correspondientes al Discovery, SwordClient y XMLWorkflow.  Recordar que desde la versión 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…

Además, como los ficheros de mensajes son compatibles con versiones atrasadas, pues se puede incorporar a las versiones 4 (de las que no se disponía de versión traducida)

Traducción al español de Dspace 3.0 disponible

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

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.

Configurando el buscador Lucene, sobre alfabetos, diacríticos, stemmers ….

A raiz de algunas preguntas que aparecieron últimamente en las listas de GUDE , sobre anomalías en los resultados de búquedas, me comprometí a escribir sobre el tema. No se si este post arrojará alguna luz o confundirá aún más…espero que lo primero.

Este post es aplicable a las configuraciones de buscador basadas en Lucene, no en SOLR, es decir, todas las 1.6 y anteriores y las 1.7 y 1.8 que no usen la facilidad Discovery…

Nuestro camino empieza a partir de la línea en dspace.cfg:

search.analyzer = org.dspace.search.DSAnalyzer

es decir, el analizador estándar de Dspace, que como bien nos recuerdan, está diseñado para textos en inglés. Y este analizador tiene los siguientes filtros, aplicados en cascada:

  • StandarFilter -> labores preparatorias de conversión del texto en cadena de palabras para el resto de filtros
  • LowerCaseFilter–> conversión a minúsculas
  • StopFilter –> Elimina las palabras gramaticales o “vacías” , que no aportan gran significado a la búsqueda, como artículos, conjunciones, preposiciones, etc, a partir de una lista de exclusión o “stopword”. La lista original del filtro incorpora términos ingleses
  • PorterStemFilter–> El algoritmo de Raíces de Porter (es lo que significa Porter Stem) retira sufijos y otras terminaciones morfológicas comunes de las palabras inglesas. Y desde luego con el español, catalán, portugués, etc… no es donde ofrece sus mejores resultados….

Sobre PorterStemFilter: Básicamente mejora las búsquedas en inglés, obteniendo la raíz de una mayoría de términos. Así loving, loves, loved, lovable, .., se ven reducidas a lov- y se mejora sustancialmente la búsqueda. De manera colateral, y por eso su uso pasa desapercibido a los hispanohablantes, es un stemmer válido para algunos plurales, pero no todos, del español, ya que recordemos que no está diseñado para nuestro idioma.

Para los curiosos, el filtro implementa un proceso definido en 1979 por Martin Porter, y que puede verse aquí .. Como dice Porter, y otros antes y después, el algoritmo simplemente devuelve mejores resultados en las búsquedas automatizadas, en inglés. Mejores que si no se usa el filtro. Pero tiene, evidentemente, sus carencias y equivocaciones, ya identificadas por Porter.

Y de forma “histórica”, como un conocimiento pasado de instalación en instalación, y que nosotros mismos hemos implentado, la mayoría de instalaciones con textos en español, portugués, francés… han añadido, a continuación en la cadena de transformaciones un nuevo filtro:

  • ISOLatin1AccentFilter, que reemplaza los caracteres acentuados del juego de caracteres ISO Latin 1 (ISO-8859-1) por sus equivalentes sin acentuar, es decir reemplaza á por a.

Con esta configuración, y con este orden de transformaciones, entre otros efectos, las palabras terminadas en es, son consideradas plurales (en inglés, pero plurales) y reducidas a su raíz, singular, por el PorterStemFilter. Por contra, las palabras terminadas en és, no son reducidas, pues para este Filtro, si terminas en és no eres un plural. Los resultados de la búsqueda son así dispares…y de ahí las preguntas en GUDE.

Un poco de wikipedia: Un signo diacrítico es un signo gráfico que confiere a los signos escritos, no necesariamente letra, un valor especial.
Son diacríticos, por ejemplo, los acentos ortográficos ( ´ ; ` ), la diéresis ( ¨ ), los signos empleados en el alfabeto fonético, como la oclusión (^) o la nasalización ( ~ ), la tilde de la ñ (virgulilla), la cedilla ( ¸ ) , la colita ( ˛ ), la coma ( , ), el doble acento agudo, ( ˝ ), el carón ( ˇ ), el breve ( ˘ ), el macrón ( ˉ ), el anillo ( ˚ ), el punto ( . ), el acento circunflejo ( ^ ) y el garfio ( ̉ ).

Otro poco de wikipedia: ISO 8859-1 es la norma de la ISO que define la codificación del alfabeto latino, incluyendo los diacríticos (como letras acentuadas, ñ, ç), y letras especiales (como ß, Ø), necesarios para la escritura de las siguientes lenguas originarias de Europa occidental: afrikáans, alemán, aragonés, asturiano, castellano, catalán, danés, escocés, español, feroés, finés, francés, gaélico, gallego, inglés, islandés, italiano, neerlandés, noruego, portugués, sueco y Euskera.
También conocida como Alfabeto Latino n.º 1 o ISO Latín 1.

Dicho esto, señalar que ISOLatin1AccentFilter ha sido retirado, “deprecated”, por Apache Lucene y ha sido sustituido por ASCIIFoldingFilter (hubo un ISOLatinACCENT por el intermedio..). Los detalles de la sustitución, aquí.

Esta clase mejora la ISOLatin1Accent, ya que ésta solo trataba el primer bloque de BASIC Latin, y lo amplía incluyendo (y filtrando a sus caracteres base) una larga lista de extensiones: C1 Controls y Latin-1 Supplement, Latin Extended-A, Latin Extended-B, Phonetic Extensions, General Punctuation, Superscripts and Subscripts, etc…

Y también señalar que Lucene tiene un org.apache.lucene.analysis.es.SpanishAnalyzer, que puede ser declarado en dspace.cfg como sustitución a org.dspace.search.DSAnalyzer. Las implicaciones de esta sustitución, es que en vez de usar la cadena StandarFilter -> LowerCaseFilter–> StopFilter –> PorterStemFilter–> ISOLatin1AccentFilter, usa el filtro definido por SpanishAnalyzer, un SpanishLightStemFilter. Las malas noticias son que las pruebas que hemos realizado con este Stemmer son ¿decepcionantes?, con un tratamiento desconcertante de las palabras agudas acentuadas terminadas en o, a y e …os suena, ¿verdad? No obstante, nos reservamos una segunda evaluación más pausada sobre este filtro.

ya casi… Conclusiones o recomendaciones

  • Seguir adoptando y adaptando org.dspace.search.DSAnalyzer, no cambiar a org.apache.lucene.analysis.es.SpanishAnalyzer, en tanto Lucene no mejore el Stemmer de español incluido por defecto.
  • Posiblemente cambiar ISOLatin1AccentFilter por ASCIIFoldingFilter. No mejorará radicalmente los resultados de ninguna búsqueda, pero si en el futuro se retira de las librerías Apache, el build no os dará problemas
  • Dependiendo del idioma predominante en nuestro Repositorio, valorar quitar PorterStemFilter de la cadena del analizador. Si requerís un Stemmer, otra opción, que hemos probado y aparentemente no tiene los problemas reportados en las listas GUDE, aunque a lo peor tiene otros efectos colaterales, es invertir el orden de los filtros PorterStem e ISOLatin1/ASCIIFolding.

con lo que org.dspace.search.DSAnalyzer nos podría quedar así:

import org.apache.lucene.analysis.ASCIIFoldingFilter;
..
..
result = new StandardFilter(result);
result = new LowerCaseFilter(result);
result = new StopFilter(result, stopSet);
result = new ASCIIFoldingFilter(result);
result = new PorterStemFilter(result);

Ya terminamos

Sobre todo, recordar los objetivos de un analizador: simplemente devolver mejores resultados en la mayoría de consultas. Es una transacción. Si dejamos pelada la cadena de análisis, los resultados serán extremadamente precisos, en el sentido de ofrecer solo resultados coincidentes con la cadena de búsqueda, pero no estaremos aprovechando las posibilidades de Lucene y nos habremos dejado en el camino un porcentaje amplio de resultados relevantes. Vuestra decisión.

(y perdón por que esta vez me ha salido un rollo)
(y sacaremos un post con la configuración propuesta para SOLR)

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

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?