Traduciendo la interfaz de trabajo de OJS3

Lamentablemente la nueva versión de OJS (v3) contiene partes del sistema aún no traducidas o mal traducidas al castellano.

Gracias a la instalación del plugin Translator, los administradores pueden traducir directamente desde la interfaz de trabajo sin necesidad de descargar y cargar los archivos de instalación que contienen las cadenas de caracteres no traducidas o mal traducidas. En esta entrada te explicaremos cómo trabajar con este plugin,

El proceso de instalación y carga de traducciones o refinamiento de traducciones es bien sencillo. El usuario debe ir a Preferencias → Sitio Web → Módulos y desde allí, acceder a la Galería de módulos para localizar el plugin Translator (https://github.com/pkp/translator).

Una vez instalado el usuario deberá acceder a la lista de módulos y plugins instalados, localizarlo, activarlo y hacer clic en el enlace Traducir. De ese modo podrá acceder a los archivos de traducción y editar directamente el contenido del componente que desea actualizar.

Para ello, en primer lugar, deberá seleccionar el idioma de trabajo. En las capturas que siguen se muestra el proceso completo para cargar traducciones en castellano/español.

1) Clic en el botón Editar.

2) Seleccionar el archivo xml donde figura el componente/cadena de caracteres que desea editarse. En el ejemplo, se va a proceder a cargar la traducción de los componentes que figuran al inicio del post (ventana emergente que le permite al editor tomar la decisión editorial de enviar a revisión un artículo):

##editor.review.newReviewRound##

La propia cadena de caracteres aporta pistas de gran valor para localizar el archivo xml que debe editarse (editor.xml). Para acceder a él el usuario deberá hacer clic en el enlace Editar.

3) Una vez accedido al archivo xml el usuario deberá localizar en el fichero el componente a editar (editor.review.newReviewRound), cargar la traducción y guardar cambios.

6 comentarios en «Traduciendo la interfaz de trabajo de OJS3»

  1. Por si fuese de interés:

    Hasta (diría) la versión 3.1 de OJS las cadenas en es_ES y ca_ES fueron traducidas y corregidas de forma exhaustiva por profesionales. Tradicionalmente estos dos idiomas (junto con el alemán) han sido los primeros en traducirse y los que han ofrecido traducciones más completas. Vamos, que estamos orgullosos del trabajo que se ha hecho. 🙂

    Pero el workflow de traducción de un proyecto en github, cuando está basado en submódulos, se convierte en una tarea extremadamente farragosa y el equipo de voluntarios que mantenemos las traducciones es_ES y ca_ES acordamos con PKP un cambio de modelo.

    En el sprint de Heidelberg empezamos con una nueva aproximación. Resultó evidente (hace rato) que no tiene sentido mantener un formato y una herramienta de traducción OJS-nativos cuando hay formatos standards y fantásticos proyectos libres para gestionar su traducción (pe: weblate).

    Así pues, de la versión 3.1.0 hacia delante, no se han traducido (ni se traducirán) las cadenas que faltan, pues preferimos dedicar los pocos recursos con los que contamos a buscar soluciones sostenibles que faciliten que otros y otras se sumen a la nada grata tarea de traducción.

    En cualquier caso, para el «mientras tanto», si alguien se anima a traducir las cadenas que faltan, aceptaremos encantados cualquier PRs.

    Si el perfil no es el de traducción, sino que es técnico, en este hilo estamos hablando de como tirar adelante el sevidor de traducción y como se puede leer, también faltan manos:
    https://github.com/pkp/pkp-lib/pull/3906

    un cordial saludo.

    1. Muy buenas Marc,

      Te quedamos muy agradecidos por las referencias e información que aportas, de veras. No podemos estar más de acuerdo contigo respecto al estado de las traducciones es_ES y ca_ES de OJS que trasladas. Notamos efectivamente ese pequeño cambio a partir de la versión que refieres, en todo caso, nos sumamos a tu apreciación sobre el trabajo del equipo de trabajo PKP y al nuevo enfoque de trabajo que habéis acordado. Nos parece una decisión acertada.

      Al margen evidentemente de la ausencia de ese pequeño corpus de traducciones que afectan fundamentalmente a algunos módulos y a las pantallas de trabajo del workflow editorial, como bien sabes, muchas instalaciones quieren customizar sus propias traducciones y el post, en buena medida, va orientado a dar pautas genéricas para poder acometer cambios en las traducciones de las revistas (enriquecimiento).

      Muchos de nuestros clientes nos solicitan pequeños cambios en ese sentido y por eso queríamos aportar nuestro pequeño granito de arena al respecto, trasladando unas sencillas pautas para poder realizar cambios menores de manera autónoma (correctivos, perfectivos).

      Finalmente, recogemos el guante que nos lanzas. Nuestro equipo de trabajo OJS ha liberado código en los repositorios GitHub (integración tesauro Agrovoc) para versiones 2.4.8x y próximamente aportaremos nuevo código a la comunidad PKP.

      Un cordial saludo

  2. Disculpa el silencio. Durante las vacaciones se detiene el espacio y el tiempo.

    Cuando se creó el plugin de traducción la idea no era solo facilitar la tarea de los/las traductores/as, sino justo el uso que comentas: permitir que las revistas adapten parte de la terminología a sus necesidades concretas. Por esa parte genial el post. Mi única «queja» era por lo de «lamentable», pues a mi modo de ver, lo que resulta lamentable es que tantos estemos usando la herramienta y tan pocos aporten algo de vuelta.

    Celebro mucho escuchar que se liberan desarrollos. Como sabes el equipo de PKP cuenta con apenas (o mejor dicho «a penas») 5-6 programadores, así que la única manera de crecer es trabajando en comunidad. Desafortunadamente parece que hay mucha más demanda (volvemos a las 10.000 revistas en 2019, pese a la revisión del «concepto revista en activo», lo usamos en la mayoría de universidades…) que necesidad de aportar de vuelta.

    Creo que es tarea de todos intentar cambiar esta manera de pensar, «liberar rápido y morir joven» (que decía un buen amigo), pensar colectivamente y construir comunidad. Pienso que si logramos salir del uso instrumental de la herramienta, descubriremos que tenemos capacidad para construir una mejor aplicación, pero también una mejor ciencia.

    En ese sentido, al compartir conocimiento, vuestro blog es un aporte. Gracias.

    Y cambiando de tercio, suena muy interesante el módulo del tesauro Agrovoc. ¿Algún enlace en el que poder echarle un ojo? ¿Tenéis intención de migrarlo a ojs3?

    Hace una década (pensé que era menos, pero al buscar el link me he dado cuenta de que ya soy viejo en esto) hice un desarrollo para integrar un tesauro en ojs (tema3 se llamaba la herramienta exerna) pero lo usamos poco y finalmente abandonamos el proyecto: http://wayback.archive-it.org/7100/20160820122634/https://pkp.sfu.ca/support/forum/viewtopic.php?f=28&t=4800

    Siempre he pensado que es una necesidad, pero faltan manos o tiempo o las dos cosas.

    OJS 3 mejora la gestión de las keywords y provee incorporar tesauros. Echadle un ojo al github por si podéis aprovechar algo. Creo que era Nate quien estaba con eso. Si se le explica que tenéis clientes que lo piden tal vez pueda redefinir la prioridad del feature request.

    Por cierto, nos veremos en la PKPBCN19?

    Un saludo,
    m.

    1. Buenas Carlos,

      Disculpa la demora. ¿Durante el proceso de instalación del plugin OJS te ha reportado algún error? Necesito saber qué versión de OJS tienes, qué versión del plugin has instalado, etc.

      Un saludo

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Solve : *
11 − 4 =