lunes, 4 de octubre de 2010

Estándares (III)


Personalización
En ocasiones los estándares abiertos permiten un nivel de personalización peligrosamente alto, ya que esto puede llevar a la desintegración y atomización del estándar. Por ejemplo, XLIFF 1.2 permite la creación de metadatos personalizados en ciertos campos. Aunque la creación de campos personalizados por desarrolladores de herramientas y diseñadores de procesos pueda ser positiva cara a evitar el uso de estándares propietarios, esta personalización lleva a incompatibilidades entre las distintas implementaciones, y a la pérdida o corrupción de datos intercambiados entre soluciones. Al ser la compatibilidad e interoperabilidad el objetivo primero de los estándares, la posibilidad de personalización parece incompatible con la idea de utilizar estándares.


Complejidad
A pesar de que los estándares abiertos permitan cierto nivel de personalización, los diseñadores intentan evitarla hinchando los estándares con demasiados metadatos innecesarios. Por ejemplo, la especificación XLIFF 1.2 permite hasta 10 estados de traducción, sin contar la infinita personalización: "final, necesita-adaptación, necesita-l10n, necesita-revisión-adaptación, necesita-revisión-l10n, necesita-revisión-traducción, necesita-traducción, nuevo, aprobado, traducido". Aunque ciertos usuarios necesiten todavía más estados, la mayoría de traductores y, especialmente, gestores de proyecto, tendrían suficiente con una lista mucho más reducida, como "sin traducir", "traducido", "revisado", "necesita revisión" y “final”. Incluso alguien con una visión más pragmática podría argumentar que un estado binario es más que suficiente: o una unidad de traducción está completada o no.
El problema con un nivel tan alto de complejidad reside en el hecho de que, mientras el estándar XLIFF permite estos metadatos, la mayoría de herramientas de localización que dicen ser "compatibles con XLIFF" o no soportan metadatos opcionales o simplemente no implementan la interfaz de usuario necesaria para editar estos metadatos. Por ejemplo, Maxprograms Swordfish es la única herramienta comercial que permite a los usuarios cambiar entre todos los estados posibles. La mayoría de herramientas o bien no van más allá del estado binario antes mencionado o sólo permiten un número de estados que creen "suficientemente bueno". Si un archivo XLIFF cargado de muchos estados de traducción se importa en una herramienta con compatibilidad parcial de la especificación XLIFF 1.2, éstos estados se perderán o no se actualizarán al exportar de vuelta el archivo XLIFF. Todo esto lleva a la pérdida de (meta)datos y a perder el principio de interoperabilidad propio de los estándares.


Interoperabilidad
Como se ha mencionado antes, la interoperabilidad entre procesos es la razón de ser principal de los estándares abiertos. Sin una buena interoperabilidad, los usuarios acaban cansados de perder datos y estar atados a un solo proveedor, además de que los desarrolladores tienen que perder el tiempo reinventar la rueda cada vez que crean su formato propio (y propietario) de trabajo.
Un ejemplo de tal interoperabilidad son las Interfaces de plataforma de aplicación (APIs), que permiten a los sistemas intercambiar datos y solicitudes. Por ejemplo, Google ofrece su servicio Google Translate a terceros mediante su API que hace que cualquier pagina web se traduzca de forma automática con un simple clic, gracias a lo cual muchas herramientas de traducción permiten enviar frases individuales a Google Translate y recuperarlas traducidas sin necesidad de establecer procesos más manuales.
La integración entre distintos proyectos de localización también puede realizarse compartiendo un glosario o una memoria, con la importación o exportación de archivos y con solicitudes u ofertas de actividad. Además, el uso de librerías comunes como gettext (extracción de datos de localización) o translate-toolkit (pre y post-procesamiento de archivos) reduce la duplicacion de esfuerzos y proporciona una experiencia común.
En el caso del contenido en línea, los plugins de los Sistemas de gestión de contenido (CMSs) permiten el intercambio de datos entre distintas soluciones (migración), pero también la exportación de contenidos específicos para ser localizados, ya sea con archivos accesibles offline o como datos mediante APIs. En este caso, es vital conectar el CMS a un Sistema de gestión de traducción (TMS), y así intercambiar los datos de localización en las dos direcciones, como pedidos de traducción y como entregas ya completadas.



(Ésta es la tercera de mis entradas relacionadas con mi tesina del máster. Queda una más sobre estándares y ya cambio de tercio. Como veis, no valgo para investigador. Y no es falsa modestia.)

No hay comentarios:

Publicar un comentario en la entrada