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.

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.

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.

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.

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.

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.

Anuncio publicitario

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

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

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

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

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.

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.

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.

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.

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.

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).

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.

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.

–          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.

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.

Cambio de rumbo profesional y apertura de Dc. Studio

Hola a todos desde las frías tierras de Zürich:

Ante todo, os ruego me perdonéis por la inactividad reciente, pero es que he estado tremendamente ocupado últimamente. ¿Motivo? Pues un cambio importante en mi vida.

Desde hace más o menos un mes sabía que iba a empezar un trabajo nuevo, así que cais no he tenido tiempo para otra cosa que no fuese preparar papeleos, despedidas, formarme, etc. El cambio en cuestión es que desde el pasado lunes 16 de abril formo parte del equipo de IT de la empresa suiza de servicios lingüísticos CLS COMMUNication, en concreto del departamento de Language Technology. A partir de ahora trabajaré en lo que más me gusta: ayudar a traductores y PjM en apuros, dar formación de herramientas y procedimientos de traducción, desarrollar herramientas y aplicaciones para mejorar el negocio, hacer consultoría y asesorar a clientes y managers, etc.

De momento me encuentro en Zürich conociendo a mis compañeros de departamento y la empresa en general, aunque en breve me trasladaré a Londres, donde seré, entre otras cosas, el IT guy de la oficina de CLS en la capital del Reino Unido.

La consecuencia directa, en cuanto al blog se refiere, es que si ya de por sí últimamente mis artículos tendían a tener un carácter técnico, creo que el camino que seguirá el blog será profundizar en todo tipo de entresijos informáticos relacionados con IT en general, programación y sobre todo con las herramientas CAT.

De hecho, para celebrar el nuevo rumbo que toma mi vida profesional, he decidido crear una nueva sección en mi web denominada Doctor Studio. Dado que en los diferentes artículos que he publicado sobre SDL Trados Studio se han generado bastantes preguntas y debates interesantes, me parece que lo mejor es que de ahora en adelante, los lectores que tengan problemas dejen sus comentarios y dudas en una misma sección centralizada, para que pueda consultarse con mayor facilidad.

Bueno, como todavía estoy bastante ocupado entre unas cosas y otras, os dejo y os invito a visitar la web de mi nueva empresa, así como, en el futuro, plantear vuestras dudas al Doctor Studio.

Un saludo desde tierras suizas.

Atentamente,

Álvaro

Recomendación musical: el pequeño de los Gallagher y los suyos (Beady Eye) sacan nuevo trabajo y su nuevo single suena bastante bien, aquí lo tenéis, Flick of a finger.

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).

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.

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:

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?

Petición de ayuda a los lectores para apoyar al Msc Trans de Imperial College

Estimados lectores:

Escribo este post a fin de solicitaros ayuda de forma directa.
Las dificultades económicas generadas por la crisis afectan a todo el mundo y a todas las instituciones. Las universidades y los programas formativos no quedan al margen. Como consecuencia, la Junta directiva de Imperial College London se está planteando la posibilidad de eliminar el departamento de traducción de dicha universidad.

A fin de evitarlo, a través de una iniciativa pública disponible en http://www.change.org/en-GB/petitions/petition-against-the-transferral-or-closure-of-the-translation-studies-unit?utm_source=share_petition&utm_medium=url_share&utm_campaign=url_share_after_sign#share se está tratando de recabar apoyo para evitarlo. El objetivo es poner de relieve que los estudios de traducción continúan siendo necesarios y aún más que estos tengan un carácter científico y riguroso.

Aunque puede que muchos de vosotros no conozcáis de primera mano el departamento de traducción de Imperial College, me gustaría aclarar que cuenta con docentes de máximo prestigio como Jorge Díaz Cintas o Christophe Declercq. Además, el departamento de traducción de Imperial funciona como unidad dinamizadora de actividades de traducción en Reino Unido y en el viejo continente en general. Por descontado está el hecho que ofrece una formación completa y de calidad que nos ha permitido a muchos no únicamente disfrutar de un periodo formativo sensacional en un entorno inmejorable, sino también mejorar nuestra red de contactos profesionales y académicos.

Por ello y porque estoy convencido de que se trata de un centro neurálgico para los estudios en traducción e interpretación en todo el mundo del que todavía muchos profesionales deben disfrutar, os ruego que apoyéis esta iniciativa (y cuanto antes, mejor).

Gracias por vuestra colaboración. Es sólo cuestión de un minuto, pero juntos podemos dejar muy claro que es importante que se preste a la traducción la importancia que realmente tiene en la actual sociedad globalizada. Un saludo,

Álvaro

 

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.

Con 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.

Expresiones regulares y traducción (parte II)

Hola y saludos otoñales (casi invernales) a todos (los del hemisferio norte, en el sur, al revés):

En el anterior post de esta serie sobre expresiones regulares vimos la introducción general y el uso de los operadores básicos (caracteres literales, punto, corchetes, guión y acento circunflejo).

En esta segunda parte de la serie vamos a centrarnos en los caracteres con un significado especial más allá del propio literal: los metacaracateres. Los metacaracteres sirven para identificar o encontrar patrones de texto o formato que, de otra manera, resultaría bien imposible, bien muy complejo. En una implementación general de la sintaxis de las expresiones regulares nos encontramos con la siguiente selección de metacaracteres habituales, que presento en un cuadro para que pueda usarse como referencia rápida.

Metacaracteres de búsqueda

– \ (barra invertida): la barra invertida sirve para anular (o “escapar” en términos informáticos) un metacaracter de forma que se utilice como un carácter literal. Por ejemplo, si hacemos una búsqueda por \\n (como veremos a continuación, \n es un metacaracter para un salto de línea manual) estaremos indicando que en lugar de buscar un salto de línea se busque el carácter de barra invertida seguido del carácter n (práctica habitual en programación para suprimir, por ejemplo, los saltos de línea y cambiarlos a otra cosa). – \f (barra invertida y f): sirve para identificar o buscar los caracteres de salto de página en formato electrónico (se trata de un carácter que manda la instrucción a la impresora). – \n (barra invertida y n): sirve para encontrar un carácter de salto de línea en un documento (de hecho, \n es la forma de insertar una línea nueva en muchos lenguajes de programación como C o C++). – \r (barra invertida y r): sirve para encontrar un carácter de retorno de carro (cuando se pulsa la tecla Intro para pasar la siguiente línea, como cuando se empujaba la palanca de cambio de línea en una máquina de escribir antigua). – \t (barra invertida y t): sirve para encontrar un carácter de tabulación horizontal (el que se inserta al pulsar la tecla Tab del teclado). – \v (barra invertida y v): sirve para encontrar un carácter de tabulación vertical (en ASCII tiene asignado el 11). – [\b] (corchete apertura, barra invertida, b y corchete de cierre): permite identificar un carácter de retroceso en un texto. – \d (barra invertida y d): se trata de uno de los metacaracteres más útiles y usados. Permite buscar cualquier dígito, es decir, es lo mismo que escribir [0-9] para usar un intervalo, tal y como vimos en el post anterior. Por ejemplo, al buscar \d euros en un editor compatible con regexp clásicas (por ejemplo, EditPad Lite), encontraríamos en un texto tanto 5 euros como 7 euros. – \D (barra invertida y D mayúscula): sirve para justamente lo contrario a lo anterior, es decir, para buscar todo lo que no sean dígitos. Se trata por tanto, del equivalente a [^0-9]. – \w (barra invertida y w): otro de los metacaracteres más utilizados ya que permite localizar cualquier carácter alfanumérico (en mayúscula o minúscula) y el guión bajo. Por tanto, es igual al patrón [a-zA-Z0-9_]. Por ejemplo, con la búsqueda [Cc][Rr]\w encontraríamos tanto CR7 como crocs. – \W (barra invertida y W mayúscula): sirve para lo contrario a lo anterior, es decir, encontrar un carácter no alfanumérico ni un guión bajo; sería el equivalente a [^a-zA-Z0-9_]. Se puede utilizar para buscar caracteres de formato (párrafo, saltos, etc.) u otros como #. – \s (barra invertida y s): sirve para encontrar cualquier tipo de carácter de espacio en blanco. Es por tanto equivalente a [\f\n\r\t\v]. Por ejemplo, al buscar por \s en el texto Uno y dos, el texto que se identificaría serían los espacios en blanco (Unoydos). – \S (barra invertida y S mayúscula) lo contrario a lo anterior, es decir, lo mismo que [^\f\n\r\t\v]. Nos permite encontrar un carácter del tipo de todo lo que es «visible» al ojo humano en un texto. – \b (barra invertida y b): este metacaracter es muy útil porque sirve para marcar una posición de un carácter dentro de una palabra. Habitualmente se usa para buscar caracteres al principio. Por ejemplo: al buscar por \barm se encontrarían las palabras armadura y arma, pero no harmónica puesto que el patrón de búsqueda arm no está al principio de palabra en el último caso. Aunque se usa especialmente para marcar el inicio de una palabra, \b también sirve para marcar el final; por ejemplo, la búsqueda ato\b serviría para encontrar pazguato, pero no atornillar. Por último, si se combina el uso para inicio y final de palabra, lo que obtenemos es el equivalente a la búsqueda de palabra completa; por ejemplo, \bagua\b encontrará agua pero no aguantar. Por su uso, este es un metacaracter marcador de posición dentro de una palabra. – \B (barra invertida y B mayúscula): sirve para no encontrar un carácter en los límites de una palabra. Se usa, por ejemplo, para localizar guiones de separación en palabras en inglés (no hay espacios a los lados) con regexp como \B-\B, con las que se obtendrían resultados como task–related. – ^ (acento circunflejo): fuera de un corchete, el acento circunflejo sirve para marcar el inicio de una cadena completa. Ojo, hemos dicho cadena, no palabra. En términos habituales, esto significaría comienzo de una frase en una nueva línea. Por ejemplo, ^\w nos serviría para localizar el primer carácter alfanumérico de una frase o cadena. En algunas implementaciones se suele ver \A en lugar de ^. – $ (símbolo del dólar): sirve para lo mismo que el metacaracter anterior, solo que en este caso se encuentra el final de una cadena. Por ejemplo, :$  nos permitiría encontrar todas las cadenas que terminen en dos puntos. En algunas implementaciones se suele ver \Z en lugar de $.

Como podemos intuir, la combinación de estos metacaracteres con los patrones de búsquedas tratados en el primer artículo de esta serie sobre expresiones regulares multiplica las prestaciones de las que disponemos. A modo de ejemplo práctico en el mundo de la traducción, podemos ver la combinación de caracteres literales y comodines (metacaracteres) en la creación de reglas de control de calidad o QA en la mayoría de las herramientas CAT del mercado. Habitualmente, las funciones de QA operan de la siguiente manera:

1) Se busca la aparición (o ausencia) de un patrón determinado en el texto de origen y

2) Se compara el resultado del primer paso para verificar la existencia (o no existencia) de dicho patrón en el texto de destino.

En concreto y para verlo con más claridad, vamos a definir una regla que busque los números con punto como separador de decimales en el texto de origen y que en el texto de origen NO tengan como separador de decimales una coma.

a) Expresión regular para el texto de origen: \d\.\d.

– Explicación: expresión formada por cualquier número (\d), punto (como punto es un metacaracter por sí mismo, lo escapamos con la barra invertida) y de nuevo cualquier número.

– Resultado: se encontraría, por ejemplo, 10.1, 512,684.58, 4.6.

b) Expresión regular para el texto de destino: [^\d,\d].

– Explicación: expresión formada por cualquier número (\d), coma y de nuevo cualquier número.

– Resultado: se encontraría, por ejemplo, 10,1, 512.684,58, 4,6.

Como se observa, en realidad lo que se hace es decirle al programa mediante una expresión regular lo siguiente “si en un segmento de origen encuentras un número, un punto y otro número y en el segmento de destino correspondiente hay un número separado de otro por algo que no sea una coma, genera un error de QA para que lo compruebe». En concreto, en este caso vemos como en el número 512.684,58 se habría producido un falso positivo (¡el tema de los falsos positivos daría para otro post!), puesto que aquí el punto separa las unidades de millar, no los decimales. En el resto de casos, no habría habido ningún problema.

Expresión regular para función de QA en SDLX

Esta última explicación y ejemplo es uno de los casos más habituales de uso de las expresiones regulares. No obstante, existen muchos más escenarios como, entre otros, el filtrado de cadenas en el editor de traducción, la extracción de cadenas en la ingeniería de traducción con patrones complejos, etc. La verdad es que una vez se dominan bien todos los operadores básicos, cada cual es capaz de idear aplicaciones de lo más variopintas en su trabajo y su día a día.

En este segundo artículo de la serie sobre regexp hemos tratado los metacaracteres como complementos indispensables para los operadores de regexp básicos a fin de buscar y encontrar patrones textuales más sofisticados. Pero, ¿no sirven todos estos metacaracteres vistos para localizar caracteres individuales? En el ejemplo [^\d,\d], ¿no se resaltaban con la búsqueda únicamente el número anterior (\d) y posterior al separador de decimales (,\d)? ¿Qué pasa si queremos buscar más números o caracteres y combinar en una búsqueda patrones más grandes en que se repitan caracteres, espacios en blanco, etc.?

Obviamente, todo eso se pensó al diseñar las expresiones regulares, así que nosotros lo veremos en el siguiente post de esta serie, donde trataremos la búsqueda y creación de repeticiones de caracteres y búsquedas, los cuantificadores, las subexpresiones y muchas más cosas con las que podremos aprovechar toda la potencia que nos brindan las regexp.

Mientras tanto, como en el caso anterior, a practicar con lo ya aprendido, ¿de acuerdo?

Nos leemos en más o menos un mes. Ah, y como siempre, perdonad que me enrolle tanto y termine por escribir post larguísimos. Un saludo a todos,

Álvaro

Recomendación musical: tras casi dos años de espera si no me equivoco, mis apreciados Stereophonics vuelven a la carga con nuevo material y sello discográfico propio. Aquí va el single titulado In A Moment.