Visualización de archivos TMX en formato tabla

Hola a todos:

Ya no sé si pedir perdón por la falta de inactividad o directamente anunciar que echo la persiana y despedirme, la verdad, :P. En los últimos meses he estado tan liado que no he podido dedicar nada al blog en términos de producción de contenidos (pero sí he continuado respondiendo preguntas y echando una mano por privado). Aunque no puedo prometer que esto vaya a cambiar, el otro día necesitaba hacer un par de cositas con una memoria de traducción (TM) en tmx y creo que esto podría resultar práctico a cualquiera, así que lo tomaré como excusa para escribir un post nuevo.

El tema en cuestión es que hace unos días necesitaba mostrar el contenido de una TM en tmx de una forma visual, de manera que una persona sin conocimientos técnicos fuese capaz de interpretar y analizar sin problemas y rápidamente el contenido disponible en este tipo de formato bilingüe, que habitualmente tiene un aspecto parecido a esto.

Ejemplo de tmx

Para conseguirlo, se me ocurrió utilizar unas reglas de transformación (xslt) para que, tras aplicar unos cambios sencillos, al abrir el archivo de la TM se abra directamente en el navegador de Internet predeterminado con un aspecto parecido a este.

TMX display

He adjuntado a este post (TMX-XSL display) un archivo tmx de muestra y el archivo para poder visualizarlo como si fuese una página web en un navegador web (TMX_to_HTML.xsl). El procedimiento que se describe a continuación debería ser válido para prácticamente cualquier TM en TMX (de lo contrario, avisad, por favor):

1) Copiar el archivo TMX_to_HTML.xsl a la misma carpeta donde está el archivo TMX. Por ejemplo, si tenemos el archivo TMX en el escritorio (C:UsersAMADesktoptestTM.tmx) habrá que copiar el archivo de transformación al escritorio también (C:UsersAMADesktopTMX_to_HTML.xsl).

2) Cambiar la extensión del archivo tmx a xml. Por ejemplo, si el archivo tmx se llama testTM.tmx deberíamos renombrarlo a testTM.xml.

3) Abrir el archivo renombrado (por ejemplo, testTM.xml) en un editor como el Bloc de notas o Notepad++.  Añadir la siguiente línea <?xml-stylesheet type=”text/xsl” href=”TMX_to_HTML.xsl”?> justo después de la primera línea del archivo con la declaración de XML (<?xml version=”1.0″ encoding=”utf-8″?> en el ejemplo). Tras hacer el cambio, guardar el archivo. Cerrar el editor de texto.

Cambio en TMX

4) Abrir el archivo TMX_to_HTML.xsl con el editor y situarse en las líneas 18 y 19. En ellas es necesario cambiar los códigos lingüísticos para el source y target (en el ejemplo, ‘en-GB’ y ‘es-ES’) por lo que tengamos en nuestra TM en formato TMX.

Cambio en TMX 2

Para comprobar el código lingüístico de source y target, podemos abrir el archivo TMX en el editor y fijarnos en los códigos de idioma en cualquier unidad.

Cambio en TMX 3

Para resumir, lo que hay que hacer es garantizar que los códigos de la TM en tmx y el archivo de transformación (xsl) casan. Tras actualizar el archivo TMX_to_HTML.xsl con los códigos lingüísticos correspondientes, guardamos el archivo.

5) Localizar el archivo que acabamos de guardar y abrirlo con el navegador de Internet (por ejemplo, Firefox).

Tras abrirlo, si las lenguas de tmx y xls casan como se ha explicado en el paso 4) y ambos archivos se encuentran en el mismo directorio o carpeta, el contenido de la TM en TMX debería verse como una tabla en el explorador (si la TM es gigantesca, tardará en abrir).

¿Cómo funciona esto?

Tal y como indica la Wikipedia, las XSLT o Transformaciones XSL son un estándar de la organización W3C que presenta una forma de transformar documentos XML (en el paso dos cambiamos la extensión de archivo a .xml teniendo en cuenta que tmx es un estándar basado por sí mismo en xml). En este caso, lo que hacemos es usar unas reglas XLT para crear una estructura básica de tabla en HTML y finalmente, dentro de las celdas incluir la información de texto source y target de cada una de las unidades de traducción que hay en el TM en TMX.

Para extraer cada una de esas unidades, en el documento XLS se ha especificado una regla que indica que para cada unidad de traducción o tu de la TM (<xsl:for-each select=”tmx/body/tu”>) se busquen específicamente, por una parte, el texto source (<xsl:value-of select=”tuv[@xml:lang=’en-GB’]”/> porque en-GB es la lengua de partida) y se incluya en la columna para el source y, por otra, el texto target (<xsl:value-of select=”tuv[@xml:lang=’es-ES’]”/>, porque en el ejemplo, es-ES es la lengua de destino) y se incluya en la columna para el target.

En realidad, más allá de los archivos en sí, creo que lo más importante es realmente entender cómo funciona la transformación del archivo, cómo se navega a través de la estructura de la TM en TMX para finalmente extraer y mostrar solo la información deseada (para más información sobre cómo moverse por los elementos de la TMX o de cualquier XML, recomiendo leer este tutorial de XPath de w3schools).

Ahora mismo, el proceso con estos archivos es bastante manual, pero creo que para aprender y consolidar el conocimiento y las ideas es válido. Si tengo algo tiempo, intentaré crear una pequeña aplicación para que todo sea más sencillo, pero mientras tanto, espero que la explicación y los archivos de muestra os sirvan.

Sin más, un abrazo.

¡Y espero tardar menos en escribir el próximo post!

– Archivos de ejemplo TMX-XSL display.

– Nota: los códigos lingüísticos aceptados por la mayoría de las CAT son los de Microsoft, disponibles aquí: http://msdn.microsoft.com/en-us/goglobal/bb896001.aspx

– Recomendación musical: Jimi Goodwin (el cantante de The Doves) ha publicado single en solitario, titulado Oh!Whiskey, que podéis ver en http://www.youtube.com/watch?v=HlY_fg65CVQ.

Anuncios

Preparación de nuevos tipos de archivos con herramientas CAT (con JSON de ejemplo)

Hola a todos:

En los últimos meses me he venido encontrando un formato de archivo que no había recibido antes para preparar para traducción. Se trata de JSON (JavaScript Object Notation). JSON se utiliza principalmente como una alternativa a XML para transferir e intercambiar datos de forma sencilla. Además es también bastante común el encontrarse este tipo de datos como información integrada (embedded) dentro de otros tipos de archivo (por ejemplo, dentro de archivos JavaScript).

La cuestión es que en este post adjunto el tipo de archivo JSON que he preparado para SDL Trados Studio. No obstante, en este caso lo que me parece interesante es el comentar el proceso para aprender a crear (conceptualmente, con independencia de la herramienta CAT usada para traducir) cualquier definición de tipo de archivo.

Lo primero que hay que hacer al encontrarnos con un nuevo tipo de archivo es documentarnos. En el caso de JSON (y de la mayoría de archivos ligados a la programación web), Wikipedia (http://en.wikipedia.org/wiki/JSON) y w3schools (http://www.w3schools.com/json/) son siempre una buena opción. Tras documentarnos sobre las características formales el tipo de archivo es importante hacerse con unas copias y ejemplos (a ser posible, reales y del cliente para el que trabajemos) para comprobar que siempre vamos a trabajar con la estructura correcta. En el caso de JSON, según la definición estándar, la sintaxis se estructura en torno a pares de valores entrecomillados (comillas dobles) y separados por dos puntos. Por ejemplo:

“nombre” : “Alvaro”, donde “nombre” es el campo y “Alvaro” es el valor.

Dado que JSON se emplea a menudo como alternativa a XML, es interesante ver la analogía con la sintaxis de éste último, <nombre>Alvaro</nombre>.

Esta estructura (“elemento” : “valor traducible”) es la base sobre la que se crean otras más complejas como se puede observar en los diversos archivos de ejemplos, en los que hay diferentes niveles anidados y matrices con información. Pero, ¿es esto realmente importante?

Estructura Json

Estructura Json

En realidad, no es algo decisivo. A efectos de traducción, lo interesante es que hemos identificado que la información que se desea traducir es únicamente el valor entrecomillado que hay tras los dos puntos en cada par de valores. Por tanto, al crear nuestro tipo de archivo, conceptualmente hay que pensar algo como “sólo quiero traducir todo lo que haya entre dos puntos, comillas dobles de apertura y las comillas dobles de cierre” (:”TODO ESTO SERIA TRADUCIBLE, PERO NO MAS”).

Una vez hemos llegado a este punto, lo que hay que hacer es trasladar esa idea a la herramienta que utilicemos a fin de que al procesar los archivos únicamente se extraiga como texto traducible lo deseado.

Seleccionar tipo de definición de archivo

Seleccionar tipo de definición de archivo

En el caso de la definición de archivo JSON que he preparado para SDL Trados Studio, partí de la base de usar expresiones regulares porque me siento bastante cómodo con ellas (y porque era la opción más viable que había). Una vez hecho eso, la cuestión fue plasmar “sólo quiero traducir todo lo que haya entre dos puntos, comillas dobles de apertura y las comillas dobles de cierre” en una expresión regular. Este podría ser un desglose del razonamiento

  1. “elemento” : “valor traducible” –> Estructura general
  2. : “valor traducible” –> Estructura traducible (incluyendo espacios)
  3. : “cualquiertexto” –> Estructura traducible (incluyendo espacios)
  4. : “–> Expresión de inicio de segmento
  5. Cualquiertexto –> Texto traducible
  6. ” –> Expresión de fin de segmento

Tras desmembrar la idea, ya solo es cuestión de escribir la expresión regular en el lugar adecuado en la herramienta CAT (Studio en mi caso). De todas formas, nunca está de más hacer unas cuantas pruebas en herramientas que permitan hacer búsquedas con expresiones regulares como, por ejemplo, Notepad ++. En el caso de JSON, la expresión completa para pruebas sería :\s*?”.*?” (descripción de la expresión regular: dos puntos seguidos no obligatoriamente por 1 o más espacios en blanco, comillas dobles, cualquier combinación de números, letras y espacios en blanco y finalmente otras comillas dobles).

Pruebas

Pruebas

Tras hacer todas las comprobaciones que se deseen y configurar la regla general de extracción del texto traducible en el archivo podemos definir otros parámetros (entre otros la extensión de archivo predeterminada para la definición que en la que yo os ofrezco es .json) adicionales como la gestión de elementos internos, etc. En mi definición, aunque no tenga mucho sentido he puesto, por si las moscas, que se traten como elementos no traducibles todas las posibles etiquetas (por si alguien integra html dentro de JSON).

Creo que eso es todo. Me parece que con esta breve explicación cualquiera que se ponga a pensar un rato podrá hacer frente a nuevos tipos de archivo como JSON y prepararlos para traducirlos con CAT en lugar de manualmente.

Archivo de ejemplo 4 preparado

Archivo de ejemplo 4 preparado

Y ya que estamos, además la definición de JSON para Studio, también os dejo la de los archivos .rc de Windows que, aunque parezca mentira (¡a estas alturas de la vida!), hace poco me llegó un archivo rc para traducir. Aquí va pues la definición de tipo de archivo RC.

Con eso me despido. Espero que algunos os animéis con archivos “raros” a partir de ahora.

Un saludo,

Álvaro

Recomendación musical: Miracle un tema un poco antiguo de los Foo Figthers que escuché de fondo en Camden mientras paseaba con mi mujer y se me ha quedado en el coco.

Preparación de archivos XML con información contextual (vía XPath)

Hola a todos,

En los últimos meses he tenido que preparar bastantes archivos XML para su traducción con SDL Trados Studio. Por mi pasado como traductor, tengo siempre muy presente que cuanta más información haya sobre cada uno de los segmentos que se deben traducir, más calidad tendrá el resultado final. Y si además esa información está disponible dentro de una misma plataforma (en este caso dentro de la herramienta CAT para traducir), mejor.

En este artículo describiré rápidamente cómo aprovechar la información contextual en los XML que la tienen (algo cada vez más habitual en los archivos que se envían para traducción en forma de atributos o elementos de comentario). Para ello, utilizaremos la configuración avanzada de Studio y Xpath (para más información sobre Xpath y traducción, véase, por ejemplo, este post de multifarious).

Como ejemplo de archivo XML, tomaré el siguiente: un catálogo de libros en los que el elemento title (título) contiene un atributo llamado comment (comentario), en el que se ofrece información adicional acerca del propio título del libro. Por ejemplo, en el primer elemento, para el libro XML Developer`s Guide, hay disponible un comentario que dice “This book is also available on a CD. Translate this consistently”.

La idea es que, cuando estemos traduciendo, podamos tener acceso a esta información contextual desde la herramienta CAT en cada una de las unidades de traducción sin tener que abrir el archivo XML e ir haciendo búsquedas manuales.

XML de ejemplo

Una vez hayamos creado nuestra definición de tipo de archivo personalizada para el archivo XML (el asistente hace el trabajo bastante bien, no me voy a detener a explicarlo aquí, quizá en otro post), podemos hacer uso de las opciones más avanzadas para añadir la información contextual que he comentado. Para ello, seleccionamos Tools > Options > File Types y, a continuación, nuestro tipo de archivo personalizado (en el ejemplo es ProcessComments, previamente preparado tras dejar los elementos traducibles). A continuación, accedemos a la sección Parser y seleccionamos elemento para el que queremos añadir la información contextual. Conforme al ejemplo, el elemento en cuestión es title y seleccionamos Edit.

Parser Options

En el siguiente panel, definiremos la regla para el elemento. Además de especificar que siempre será traducible (el título del libro), el siguiente paso será definir el tipo de etiqueta como de estructura (Structure) y dejar el whitespace como la opción predeterminada, salvo que haya algún motivo (y conocimientos suficientes) para cambiarla.

Edit Rule

A continuación, hay que hacer clic en Edit, en la parte correspondiente a la información sobre la estructura. Acto seguido, pulsamos Add para añadir una propiedad.

Structure Info

En la pantalla de edición de la información, tendremos que usar como Purpose la opción Information (puesto que los comentarios son meramente informativos) y, a continuación, añadir un nombre (Name). El código y la información de identificación (identifier) se rellenarán automáticamente. Por último, llegamos a la opción más importante, Set description from content of this relative XPath. Mediante esta opción, podemos definir el elemento del archivo XML de donde se extraerá el contenido que se mostrará como información contextual para cada uno de los segmentos en los que se traduzcan elementos title.

Info context

En el caso del ejemplo, nos encontramos con la siguiente situación:

<title comment=” “This book is also available on a CD. Translate this consistently”>XML Developer`s Guide</title>.

El elemento title tiene un atributo comment. Esta estructura es de hecho, la estructura del elemento title para todo el archivo XML, así que lo que debemos hacer es enlazar el atributo comment a la opción Set description from content of this relative XPath. Para ello, debemos utilizar la regla de XPath correspondiente. Conforme a la especificación de XPath, debemos utilizar arroba y el nombre del atributo, es decir @comment. Básicamente, con esta regla de Xpath se le dice a Studio que en cada elemento title, busque dentro un atributo comment y, si existe, que muestre su contenido para la propiedad que acabamos de definir como Info Context en el ejemplo.

Por último, también podríamos alterar el formato de todo el elemento title y del contenido de Info context, pero yo particularmente no soy muy amigo de los colorines (en todo caso, recomendaría asignar algún fondo gris o de color no llamativo).

Tras aplicar la regla, al preparar archivos que casen con la definición de archivo preparada para los archivos XML de mi catálogo de libros, la información de contexto personalizada con comentarios para cada unidad de traducción estará disponible en la columna de la derecha en SDL Trados Studio. Como se muestra en las capturas siguientes, al hacer clic en la columna correspondiente en cada segmento, podemos ver los comentarios respectivos desde la herramienta CAT, sin tener que hacer búsquedas en archivos externos (copia texto de origen, abre editor de texto, abre comando de búsqueda, pega texto de origen, encuentra texto de origen y localiza comentario correspondiente).

XML bien preparado en Studio

Al tratarse este artículo de un ejemplo introductorio, el contenido del mismo puede parecer hipersimplificado para las personas con mucha experiencia en la gestión y preparación de archivos XML. Sin embargo, creo que para los que no tienen tanto bagaje,  este post puede picarles la curiosidad para empezar a jugar con las propiedades avanzadas, acercarse a Xpath, etc.

Finalmente, me gustaría aclarar que aunque en el ejemplo he usado SDL Trados Studio, realmente la dinámica de trabajo para preparar archivos de esta forma es prácticamente idéntica en cualquier herramienta CAT. La clave está realmente en aprender a aplicar las reglas de Xpath correspondiente y luego sólo es cuestión de aplicar el concepto a la herramienta CAT en cuestión. No hay más misterio.

Bueno, eso es todo. Espero que os resulte útil esta breve explicación y que os lancéis a mejorar la preparación de vuestros archivos. A medida que se practica y se va teniendo éxito, el perfil de usuario mejora, así que en, al fin y al cabo, terminas por ser capaz de ofrecer un mejor servicio.

Un abrazo y hasta la próxima.

Recomendación musical: lo último que he escuchado de Kings of Leon me gustó bastante, el single se llama supersoaker.

Windows Powershell para reemplazos de nombres de archivos

Estimados lectores:

Hola a todos y perdón por el retraso al escribir. Entre el cambio de trabajo, el cambio de países (dos veces en un mes) y las consecuentes mudanzas, los cursos, las enormes distancias en Londres, etc., llevo unos meses que no tengo tiempo prácticamente ni para mirar el correo electrónico.

No obstante, creo que ya ha llegado la hora de publicar algo en el blog, aunque sea un artículo muy cortito. Espero que os resulte práctico.

El tema de hoy trata sobre la gestión de archivos y los cambios de nombres. Como la gran mayoría de vosotros sabéis (tanto si sois PMs como si trabajáis de traductores/revisores como de gestores de cuentas), en la industria de la traducción es costumbre indicar el nombre de los archivos con el código lingüístico al final del mismo, antes de la extensión de archivo. Hay clientes que prefieren el código con dos letras (por ejemplo, EN para inglés, ES para español, etc.), mientras que otros proveedores o empresas se decantan por el código completo de cuatro letras (por ejemplo, EN-GB para inglés de Reino Unido, ES-ES para español de España, etc.). Estoy seguro que ya sabéis a lo que me refiero. Además, no es tan raro encontrar empresas que además del código lingüístico también añaden otros sufijos tipo TRA o QA para marcar las versiones de traducción y revisión respectivamente.

La cuestión es que es muy habitual que las personas que gestionan las traducciones tengan la labor de, una vez los archivos se han traducido con herramientas CAT, cambiar los códigos lingüísticos a la lengua de destino. Muchos de vosotros pensaréis, ¡pero qué tontería! ¡Si mi herramienta CAT te añade automáticamente el código lingüístico! Eso es cierto, pero no significa que todo el mundo quiera usar el código lingüístico que añade tu herramienta CAT, en caso de que lo añada. Por poner un ejemplo, imaginemos que tenemos la siguiente situación.

Un cliente nos encarga una traducción de 10 archivos a 5 idiomas. Los archivos tienen el siguiente formato, CodidoDeProyecto_ID_de_idioma.ExtensiónDeArchivo, por ejemplo, 24870_EN.xlsx o 558741_DE.xml.

Archivos antes

La instrucción que nos da el cliente es que necesita los archivos con los mismos nombres, pero con los ID de idioma correspondientes en formato largo. Si tuviésemos que cambiar cada uno de los 50 archivos a mano, con una media de 15 segundos por archivo (hacer clic con el botón derecho, seleccionar cambio de nombre, borrar la extensión, poner la correcta y guardar el cambio), tendríamos que invertir 12 minutos y 30 segundos. ¡Y únicamente con 50 archivos!

Esta tarea se puede automatizar fácilmente. En el mercado hay algunas herramientas gratuitas que lo hacen, pero en algunos casos en muchas empresas (y también entre traductores autónomos) existe reticencia (o directamente está prohibido) a instalar software que no está aprobado o para el que no se tiene servicio de asistencia técnica en caso de problemas. Si esta es tu situación, te propongo usar Windows Powershell, que está disponible en la mayoría de las versiones de SO Windows. Para arrancarlo, hay que hacer Inicio > Ejecutar y escribimos Powershell.

Se nos abrirá una colorida consola de comandos.

–          Lo primero que debemos hacer es ir hasta la carpeta donde están los archivos que queremos modificar. Para ellos escribimos cd “C:\Users\Alvaro\Documents\Blog”, y entre las comillas ponemos la ruta que deseamos. Pulsamos Intro.

PowerShell

–          A continuación escribimos Dir | Rename-Item –NewName { $_.name –replace “_EN”,”_ES-ES” }, donde “_EN”,”_ES-ES” son la parte que queremos reemplazar y el nuevo sufijo respectivamente. Es importante tener en cuenta que Powershell hace los reemplazos de forma literal, por lo que hay que ser cuidadoso con lo que ponemos. En el ejemplo, he decidido incluir hasta el guión bajo, para asegurarme que solo se cambia el sufijo lingüístico. Podría haber incluido, por ejemplo, también la extensión de archivo y habría quedado así “EN.xml”,”ES-ES.xml”. Para gustos los colores, ¿no? (dicho esto me gustaría añadir que también podríamos con este método cambiar extensiones de archivo por lotes). Cuando terminemos de escribir este comando, pulsamos Intro.

–          Comprobamos nuestra carpeta y listo, el cambio de los archivos de EN a ES_ES está completado en mucho menos tiempo. Para 10 archivos, en lugar de 2,5 minutos, hemos invertido un solo minuto. Si hacemos las cuentas para el resto de archivos, vamos a ahorrar bastante tiempo.

Archivos Después

Esta operación es un ejemplo de como muchas veces automatizando tareas repetitivas pero sencillas podemos ahorrar tiempo y, además, evitarnos momentos tediosos durante el día a día. Además, también pone de manifiesto que a veces en nuestros PC tenemos muchísimas herramientas que infrautilizamos.

Eso es todo, espero que os resulte útil.

Un saludo,

Álvaro

Recomendación musical: Do I wanna know?, el single del que será el nuevo disco de los Artic Monkeys en septiembre. Temazo.

La virtualización o el milagro de la multiplicación del pan y los PC

Hola a todos:

En primer lugar, quiero pedir disculpas por la falta de actividad reciente. Se avecinan cambios en el plano profesional y he estado muy ocupado en el último mes. Espero poder volver a retomar mi actividad habitual en la respuesta a preguntas, dudas, etc. a través del blog.

Manos a la obra. En este artículo (que espero sea breve) voy a tratar un tema de carácter informático: la virtualización. Según la Wikipedia, la virtualización es “la creación -a través de software- de una versión virtual de algún recurso tecnológico, como puede ser una plataforma de hardware, un sistema operativo […]”, no obstante, a efectos prácticos, para mí la mayoría de las veces la virtualización consiste en crear un segundo ordenador virtual dentro de mi propio equipo. Habrá gente que se pregunte, ¿y para qué le sirve esto a un traductor? Bueno, es sorprendente la de veces que he recurrido durante mi vida profesional a la virtualización; más abajo pongo ejemplos. Sin embargo, ahora mismo os dejo, a modo de receta, los ingredientes necesarios para virtualizar un PC:

1 – El software de reproducción de equipos virtuales gratuito de Vmware.

2- Una imagen de sistema operativo (un archivo de SO con la extensión .iso), o bien, un PC virtualizado (archivos con extensión .vmx). En este caso, por ejemplo, yo tengo una imagen de SO Windows XP creada a partir de mi propio ordenador. No obstante, en la red hay muchas, tanto de Windows como de Linux. La cuestión es tener licencia válida para activarla luego.

Estos dos elementos son lo único que necesitamos. Para crear una máquina virtual, lo único que hacemos es, en primer lugar, instalar el software VMware Player que he indicado arriba. A continuación, iniciamos el programa y, mediante el asistente, configuramos las características de nuestro nuevo ordenador virtual (capacidad, memoria ram, etc.) y, finalmente, utilizamos la imagen en formato .iso mencionada en el punto 2 para instalar el SO en el PC virtual. Realmente, como podréis observar, el proceso de instalación es idéntico al de un SO en un PC físico.

Tras finalizar la instalación del SO, al abrir VMware Player veremos que tenemos un archivo con el nombre del SO instalado, sobre el que podemos hacer clic para reproducirlo, tal y como se ve en la imagen (en mi caso, hay instalada una versión de Linux que se llama CS50 Appliance 17).

VmPlayer

Realmente, al hacer clic en el botón de reproducción, lo que hacemos es arrancar el ordenador virtual, es decir, es como si pulsáramos el botón físico de encendido de nuestro ordenador. Si creáis un PC virtual y lo arrancáis, el resultado en pantalla que tendréis será parecido a este. Como podéis observar, se trata pues del concepto de “un ordenador dentro de un ordenador” que mencioné al principio. Como es lógico, dentro de este nuevo ordenador virtual que hemos creado podemos trabajar con normalidad, es decir, podemos crear archivos, hacer instalaciones, almacenar trabajo, etc. Todo lo que hagamos, queda registrado dentro del archivo que Vmware Player crea al instalar el SO.

PC virtualizado y PC físico

Bueno, y de nuevo, todo este lío, ¿para qué me sirve a mí como traductor? Pues os doy unos ejemplos para los que yo he utilizado (y utilizo) la virtualización para que os hagáis una idea:

1 – Realización de testing: hay veces que para realizar testings es necesario disponer de varios equipos para, por ejemplo, comprobar cadenas de software localizado en idioma de origen y partida. En estos casos, en lugar de utilizar otro PC físico, si el cliente no presenta problemas, prefiero utilizar un PC virtual para un idioma (el de origen) y el PC físico para el otro (el de destino). Este procedimiento permite también poder instalar varias versiones de un SO dentro de un mismo PC, por ejemplo, instalar en un PC con Windows 7 máquinas virtuales con SO Win XP y Vista que un cliente nos pide también para un testing. Al usar la virtualización de esta forma, nos ahorramos el invertir en PC físicos adicionales y, además, se gana mucha flexibilidad, puesto que todo está accesible desde el mismo lugar.

2- Herramientas con requisitos muy específicos: para determinados trabajos, hay veces que es necesario prácticamente adaptar toda la configuración del ordenador (por ejemplo, para una herramienta que requiere una versión concreta antigua del servidor de SQL). En estos casos, a mí me resulta mucho más práctico crear una máquina virtual dentro de mi PC y adaptarla, en lugar de cambiar todo mi entorno de trabajo habitual.

3 – Ampliación de periodos de prueba: no estaba muy seguro de si poner esta, pero lo hago por la insistencia de un antiguo compañero de trabajo que me dijo que a mucha gente le encantaría saber esto. Como ya he dicho arriba, en los PC virtuales se pueden hacer instalaciones con total normalidad. Por ello, en ocasiones, cuando tengo que aprender a utilizar una nueva aplicación de software (una herramienta CAT, por ejemplo) y no tengo suficiente con el periodo de prueba de treinta días, opto por crear un PC virtual e instalarla dentro, de manera que gano otros treinta días de prueba. Obviamente, este procedimiento se puede repetir (crear el PC virtual e instalar el software que se necesite), de manera que, en cierto modo, estamos ampliando los periodos de prueba hasta que realmente se conoce la aplicación de software en cuestión y decidimos comprar la versión completa.

El lote completo: añadir Dropbox
Recuerdo que las primeras veces que instalé PC virtuales me resultaba muy engorroso pasar archivos del ordenador virtual al PC real. A veces incluso acababa usando el correo electrónico o el servidor FTP para copiar-pegar dentro de mi propio ordenador. No obstante, mi vida mejoró sustancialmente en este sentido en el momento que conocí Dropbox. ¿Por qué? Pues porque se me ocurrió que podía instalar Dropbox en mis PC virtuales y usar una carpeta de Dropbox como buzón general de almacenamiento de documentos y archivos de trabajo en el PC virtual. Hecho esto, sólo es cuestión de sincronizar Dropbox y, ¡voila!, tenemos acceso rápido y sencillo a los archivos desde cualquier parte.

Creo que con estas explicaciones breves (puede que falte información, pero como introducción valdrá para la mayoría), los ejemplos y el complemento del Dropbox, podéis empezar a hacer pruebas y ver qué os parece. Os garantizo que incluso para un traductor acaba siendo muy útil ser capaz de crear y gestionar PC virtuales. Además, se gana mucha destreza con el ordenador. Esto es todo., espero que os resulte útil la explicación.

Un saludo,

Álvaro

Recomendación musical: dado que Stereophonics ha sacado nuevo disco (Graffiti on the Train), ahí va uno de los temas, Roll the Dice.

Más sobre expresiones regulares

Saludos a todos:

En los últimos meses he publicado una serie de artículos sobre expresiones regulares (parte I, parte II y parte III) y me han llegado algunos correos electrónicos privados con preguntas, consultas y sugerencias. Gracias a todos los que os habeis molestado en ofrecerme vuestra opinión y os habeis interesado por el tema.

A pesar de que las expresiones regulares puedan resultar relativamente crípticas al principio, son algo fundamental para aquellos que tengáis intención que hacer pinitos o dedicaros profesionalmente a la ingeniería lingüística. Dicho esto, me he decidido a escribir este artículo corto y rápido (a diferencia de las parrafadas que suelo escribir) para facilitar un enlace a un vídeo de 26 minutos de duración que me pareció bastante explicativo para los que todavía puedan pensar que esto de las regexp es demasiado complejo y que no tiene mucha utilidad. Aquí va:

CS50 - Pattern Matching with Regular Expressions

Se trata de una sesión introductoria en el curso CS50 de Harvard. Aunque la explicación se hace sobre el lenguaje de programación Python los conceptos son extrapolables a cualquier implementación de regexp.

Lo que me parece más interesante que se tratan algunos de los puntos que ya vimos en los artículos mencionados al principio y además se ve muy claro con un par de ejemplo el comportamiento “avaricioso” de las regexp (tienden a encontrar el máximo de texto en una cadena), algo que no traté muy a fondo en la serie que yo escribí.

Eso es no es todo. Para presentar una alternativa a mis propios tutoriales, y a raíz de la visualización del vídeo que os propongo arriba, os dejo un tutorial de 30 minutos sobre expresiones regulares que tenéis en http://www.codeproject.com/Articles/9099/The-30-Minute-Regex-Tutorial. Muy completito, ¡y desde cero a cien en 30 minutos!

Por último, para los que ya se han puesto las pilas con las regexp y quieren convertirse en auténticos maestros, os paso los enlaces a los libros que recomendé para continuar avanzando (descarga gratuita autorizada):

Mastering RegExp

Regular Expressions Cookbook

En ambos casos se trata de libros bastantes extensos. En la mayoría de las ocasiones pueden resultar muy útiles para encontrar regexp ya definidas que podemos aplicar a situaciones o búsquedas comunes. Además, para los que quieran hacer búsquedas y reemplazos complejos utilizando variables y subexpresiones son una fuente de referencia inmejorable.

Bueno, ahora sí, eso es todo.

Nos leemos en la red. Un saludo,

Álvaro

Recomendación musical: el nuevo single de mis admirados Stereophonics, Indian Summer. Recuerda a los temas de sus primeros álbumes, ¿no?

Expresiones regulares y traducción (parte III)

¡Saludos a todos y feliz Navidad!

Ya se acerca el final del año 2012, que ha tenido sus más y sus menos, un año con bastantes cambios para mí, la verdad. Para cerrarlo y asimismo poner fin a la serie sobre expresiones regulares y traducción, en el siguiente post veremos los aspectos más avanzados del uso de las regexp que complementan a los operadores básicos vistos en los artículos anteriores de esta serie. Sin más dilación, vamos allá.

Ya sabemos cómo encontrar caracteres literales individuales, así como usar comodines para localizar tipos genéricos de caracteres, ahora es el momento de aprender a gestionar la repetición y el número de caracteres que queremos buscar. Como en los artículos anteriores, veamos una tabla de referencia con los patrones y metacaracteres de búsqueda correspondientes.

Patrones y metacaracteres para gestión de repeticiones

+ (signo más): al incluir el signo más tras una expresión regular, se encuentran uno o más caracteres de dicha regexp. Por ejemplo, mientras que [0-9] sirve para encontrar un número cualquiera entre 0 y 9, [0-9]+ sirve para encontrar uno o más números consecutivos.

* (asterisco): se usa exactamente igual que el anterior, solo que el asterisco sirve para encontrar cero o más repeticiones del carácter o rango de caracteres buscados con la regexp escrita.

? (signo de interrogación): se utiliza de forma parecida a los anteriores, con la salvedad de que ? sirve para encontrar cero o una repetición del carácter o rango de caracteres buscados.

{x} (corchetes): al crear un expresión regular seguida de corchetes con una cifra, especificamos el número exacto de ocurrencias de la regexp en cuestión que queremos encontrar. Por ejemplo, si ponemos “ {2}”, como resultado encontraremos todos los dobles espacios, pero únicamente los dobles (si hay tres espacios seguidos, no funcionará).

{x,y} (corchetes): cuando en un corchete usamos dos cifras separadas por una coma, estamos indicando un número mínimo (x) y máximo (y) de repeticiones que deseamos localizar.

{x,} (corchetes): al usar únicamente una cifra y una coma dentro del corchetes, especificamos el mínimo de repeticiones que se deben encontrar. Por ejemplo, si ponemos “ {2,}”, como resultado encontraremos todos los dobles espacios, espacios triples, cuádruples, etc.

Como podéis imaginar, al poder controlar con mucha más precisión la cantidad de caracteres que se recuperan para un intervalo o un único tipo de caracteres, tenemos mucha más potencia a nuestra disposición. Por ejemplo, si retomamos el ejemplo de la localización de números del artículo anterior, ahora podemos ver que dicha expresión podía mejorarse mucho. Así, en lugar de buscar \d\.\d (dígito, punto, dígito), ahora podríamos hacer algo como esto: \d+\.\d+ (uno o más dígitos, punto, uno más dígitos), o incluso precisarlo más con una regexp como \d+,\d{3}\.\d+ (uno o más dígitos – coma- tres dígitos – punto – uno o más dígitos) para buscar números con unidades de millar y decimales en formato de inglés británicos.

Una vez se conocen todos los operadores es cuestión de lo más complicado, es decir, exactamente lo que se comentó en el primer artículo de esta serie: definir bien qué queremos buscar (y eventualmente reemplazar) para así poder crear un patrón o expresión regular que lo represente exactamente.

Las subexpresiones

Tras ver todos los operadores, ahora me gustaría introducir otro concepto, el de las subexpresiones. Se trata sencillamente de usar paréntesis (como en matemáticas) para agrupar búsquedas y tratarlas como un único elemento. Por ejemplo, si en un texto se quieren buscar todos los años que empiecen por 18 o 19, podríamos usar la siguiente búsqueda: (18|19)\d{2}. De esta forma, buscaríamos en primer lugar 18 o 19 (¿se me olvidó mencionar que las regexp también permiten usar la barra vertical | como un operador booleano OR?) y, a continuación, exactamente dos dígitos cualquiera.Esta es en realidad una súper simplificación de todo lo que ofrecen las subexpresiones (siguiendo con el símil de la matemáticas, recordad los infinitos elementos anidados con paréntesis en las clases de álgebra), pero creo que suficiente para dejar claro cómo separar partes significativas de las regexp que creemos.

Bueno, creo que con esta introducción a los operadores para gestión de número de ocurrencias y las subexpresiones podemos dar por conceptualmente concluido este post (¡además se acaba el año 2012 y todavía tenemos muchas cosas que hacer!). Al combinar las nociones de los artículos anteriores y de este, prácticamente cualquier profesional que trabaje como traductor o localizador (en el sentido de la producción lingüística, que no de la preparación de archivos) podría ser capaz de crear expresiones complejas para crear controles de calidad personalizados, hacer búsquedas, filtrar el contenido de archivos, etc. Como ya he dicho anteriormente, el dominio de las expresiones regulares es cuestión de práctica, de cometer errores, de consultar regexp creadas por otros, comprenderlas y crecer desde ellas. Por ello, no puedo sino animaros a continuar practicando y usando las regexp en vuestro día a día para consolidar vuestros conocimientos.

No obstante, dado que en el sector de la traducción y la localización habitualmente las expresiones regulares se suelen utilizar también para la creación de definiciones de tipos de archivos y filtros personalizados para la extracción de cadenas de archivos y la preparación de archivos de traducción y localización, no puedo dar por zanjado este tema sin mencionar que obviamente quedarían por tocar temas como la anidación avanzada, uso de referencias a ocurrencias anteriores (backreferences), uso de operadores con alcance mínimo (lazy) o máximo (greedy), pseudo-variables, conversión entre mayúscula y minúscula, búsqueda contextual (hacia atrás/delante), uso de sentencias condicionales, etc. Se trata de conceptos bastante avanzados para los que en la mayoría de casos se requieren ciertas nociones de programación (para no perderse con las analogías, las referencias a lenguajes de programación, etc.). Por ello, y porque además me veo incapacitado para explicarlo todo con la seguridad y rigor necesarios (porque algunos conceptos no los tengo 100% manejados y cometo fallos), para los que queráis seguir avanzando con las expresiones regulares me gustaría recomendaros tres títulos: Mastering RegExp (O’Relly), Regular Expressions Cookbook (O’Relly) y Teach Yourself Regular Expressions In 10 Minutes (Ben Forta). Son parte del material bibliográfico con el que he ido aprendido y mejorando mi uso de las expresiones regulares. Por otra parte, también hay mucho material en la red.

brindisCon esta última nota bibliográfica llegamos al fin (al menos de momento) de la serie de artículos sobre expresiones regulares. Espero que os hayan resultado útiles y a que muchos os hayan animado a comenzar a utilizarlas. En serio, cuando uno se acostumbra a emplearlas a diario, acabo mejorando como profesional. Asimismo, con este post, llegamos también al fin del año 2012. Espero que a todos el 2013 os depare lo mejor.

Nos leemos en la blogosfera. ¡Feliz año nuevo!

Atentamente,

Álvaro

Recomendación musical: para terminar el año musical, un tema(zo) del disco del último mes que más me ha sorprendido (sobre todo por la juventud de su autor): Two Fingers de Jake Bugg.