GNU/Linux

Trataré de explicar algo de terminología antes de entrar en los detalles técnicos de este artículo:

Gettext es un conjunto de herramientas que sirven para que un programa pueda producir mensajes en múltiples idiomas.
Los ficheros po son ficheros de traducciones empleados por el conjunto de herramientas gettext de GNU. Un fichero po contiene una relación entre una cadena no traducida a otra cadena traducida en un idioma en particular.
A la operación por el cual un programa ha sido preparado y es capaz de soportar múltiples idiomas se le llama internacionalización, abreviado por I18n (en inglés internazionalization tiene 18 caracteres entre la i y la n, igual que en castellano)
A la operación por la cual un programa, ya internacionalizado, se le pasa toda la información necesaria para que pueda adaptar su entrada (stdin) y su salida (stdout) de manera que sea correcta para diferentes idiomas y hábitos culturales de un idioma o país en concreto se le llama localización, y suele ser abreviado por L10n (localization, 10 caracteres entre la ele y la ene)
El soporte de lenguaje nativo (Native Language Support o NLS) engloba ambos procesos; internacionalización y localización.
Un locale es un conjunto de componentes de los datos culturales de idiomas y/o países. El soporte de mensajes es uno de los locales más importantes, además hay como locales: los conjuntos de caracteres a utilizar (charsets), la representación de números (numbers), la representación de fechas (dates) y la representación de monedas (currency).

El po de la extensión de los ficheros de traducción significa Portable Object, para distinguirlo de los ficheros mo que significa Machine Object. Los ficheros po son legibles y editables por humanos. Cada fichero po está dedicado a sólo un idioma. Si un programa necesita traducciones en más idiomas se precisa crear un fichero po por idioma. Gettext tiene utilidades para detectar cadenas marcadas para traducir en un programa (xgettext) que crea un fichero tipo pot Portable Object Template que sirve de planilla para iniciar el trabajo de traducción, y utilidades para comentar cadenas que ya no se utilizan en futuras versiones del programa (msgmerge). También lógicamente para convertir los po's en mo's mediante fmtstr.

Los fichero mo son ficheros compilados para la lectura por parte del programa y son de tipo binario. El formato de los ficheros mo es a menudo diferente de sistema a sistema y cada sistema debe tener sus propias utilidades para convertir po's a mo's.

Continua leyendo "Internacionalización y localizacion con gettext"

Publicado por Abraham Covelo

Emplear dos sistemas de control de versiones parece algo fuera de lugar a la hora de llevar un proyecto. Sin embargo muchas pueden ser las causas en las que emplear subversion y git puede ser muy provechoso. Por ejemplo en el caso de estos dos escenarios el empleo de ambos sistemas de versionado esta justificado:

- Repositorio central con subversion y posibilidad de trabajar offline con git en máquina local. Cuando el desarrollador vuelva a estar online puede comitear los cambios al repositorio central de subversion. Con tu copia de trabajo puedes trabajar offline puedes decir. Si pero no tienes ninguna de las capacidades de un control de versiones disponible.

- Repositorio central con subversion donde no se desea aumentar el número de ramas. Los desarrolladores pueden hacerse con el código en git y hacer ramas y otros repositorios clonados mientras dure el desarrollo de una característica específica luego se reúne el código y se comitea a subversión.

Veamos como puedes mezclar lo mejor de los dos mundos.

Continua leyendo "Empleando git y subversion"

Publicado por Abraham Covelo

En la tercera parte de este recetario sobre subversion hablaremos de tags y ramas. Haciendo incapié en su gestión y en como se emplean las ramas en situaciones reales de desarrollo de software.

Puedes encontrar la otras partes de este artículo a continuación:

Subversion y sus mejores recetas (1ª parte)

Subversion y sus mejores recetas (2ª parte)

Continua leyendo "Subversion y sus mejores recetas (3ª parte)"

Publicado por Abraham Covelo

¿Quien ha dicho que segundas partes nunca fueron buenas?

Continuando con la serie sobre subversión (subversión 1ª parte) seguimos con recetas rápidas para el uso de este sistema de control de versiones. En esta parte explicaremos algunas recetas para poder utilizar ramas de desarrollo paralelas.

Eliminar bloqueos (locks) que hayan quedado pendientes

$ svn cleanup
(a veces quedan locks sobre ficheros en tu copia de trabajo. Se retiran con este comando. Si alguna vez subversion se queja de un lock en tu copia de trabajo prueba este comando. Por ejemplo, a veces, svn status puede devolver una L (lock) sobre algún fichero, entonces hay que emplear este comando)

Concepto importante: Revisiones (revisions)

Una operación de commit (svn commit) publica cambios en cualquier cantidad de ficheros y/o directorios en una transacción atómica. Es decir las modificaciones que realices implicadas en un commit se realizan de manera indivisible, no existe posibilidad de que algún otro desarrollador vea o descargue en su copia de trabajo una modificación parcial de tu commit, lo ve todo o nada (si esta viendo o tiene una revisión no actualizada anterior a la tuya). Cada uno de estos commits crean una revisión que tiene asignado un número entero que comienza en cero (repositorio vacío) y que se va incrementando de 1 en 1 por cada commit exitoso. Cada revisión genera un nuevo "sistema de ficheros" que contiene el estado del repositorio después de los cambios efectuados por todos los commits anteriores a esta revisión incluyéndola.

Obtener la copia de trabajo de una fecha especifica en lugar de un número de revisión

$ svn checkout -r {"2006-02-17 15:30"}
(Obtiene como copia de trabajo la release más cercana anterior a la fecha 2006-02-17 15:30)


Crear una nueva rama de desarrollo (branching)

$ svn copy file:///var/svn/newrepos/myproject/trunk file:///var/svn/newrepos/myproject/branches/myfirstbranch -m "Creada una nueva rama llamada myfistbranch"
(Crea un nueva rama de desarrollo incluyendo un commit para que esta rama ya esté disponible en el repositorio)

Obtener una copia de trabajo de una rama de desarrollo

$ svn checkout file:///var/svn/newrepos/myproject/branches/myfirstbranch

Mantener tu rama de desarrollo en sincronía con la rama principal (trunk)

(Desde la copia de trabajo de tu rama de desarrollo, asegúrate de que tu copia de trabajo esta limpia svn status limpio)
$ svn commit -m "Llevar los cambios locales a la rama de desarrollo"
(Si creamos el branch en la revisión 9)
$ svn merge -r 9:HEAD ^/trunk
(mezclar los cambios procedentes de la rama principal (trunk) a tu copia de trabajo. Es posible que surjan conflictos que haya que resolver, el acento circunflejo es un alias de la url del repositorio)
$ svn commit -m "Actualizando rama con trunk"
(Se actualiza esta rama de desarrollo)


Mezclando los cambios de tu rama con la rama principal (trunk)

$ svn commit -m "Llevar los cambios locales a la rama de desarrollo"
$ svn merge -r 9:HEAD file:///var/svn/newrpos/myproject/trunk
(Volvemos a poner en sincronía la nueva rama)
$ svn commit -m "Actualizando rama con trunk"
$ svn merge --reintegrate ^/branches/myfirstbranch
(la rama es terminada aquí y no se debe trabajar con ella)
$ svn commit -m "Mezclar cambios en nueva rama a la rama principal"


Borrar rama

$ svn delete ^/branches/myfirstbranch -m "Eliminando rama myfirstbranch"
(Se borra pero el historial se puede revisar/reutilizar)

Llevar tu working copy a otra rama de desarrollo

$ svn switch ^/branches/myfirstbranch


Información sobre la copia de trabajo actual

$ svn info

Obtener información de mezclado de cambios que ya han sido llevados de la rama principal (trunk) a la nueva rama de desarrollo

(copia de trabajo es la nueva rama de desarrollo, /branches/myfirstbranch)
$ svn mergeinfo file:///var/svn/newrepos/myproject/trunk

Obtener cambios que aún deben ser mezclados desde la rama principal (trunk) a la nueva rama de desarrollo

(copia de trabajo es la nueva rama de desarrollo, /branches/myfirstbranch)
$ svn mergeinfo file:///var/svn/newrepos/myproject/trunk --show-revs eligible

Obtener informe de resultados de una mezcla sin hacerla realmente

(copia de trabajo es la nueva rama de desarrollo, /branches/myfirstbranch)
$ svn merge file:///var/svn/newrepos/myproject/trunk --dry-run

Echar atrás cambios ya realizados (comiteados)

(suponiendo que queremos echar atrás la revisión 101 que contiene graves errores)
$ svn merge -r 101:100 file:///var/svn/newrepos/myproject/trunk

ó

$ svn merge -c -101 file:///var/svn/newrepos/myproject/trunk
(actualizas tu copia de trabajo con lo que esta en la revisión 100)
$ svn diff
(compruebas los cambios)
$ svn commit -m "Deshaciendo los cambios de la revisión 101"


Recuperar un fichero borrado en una revisión anterior

(Tenemos un fichero llamado para_borrar.txt que se borró en la revisión 32 y queremos recuperarlo
$ svn copy http://svn.example.com/repos/calc/trunk/para_borrar.txt@31 ./para_borrar.txt
$ svn status
(Verificamos que se va a añadir)
$ svn commit -m "Recuperamos para_borrar.txt borrado en la revisión 32"

Así lo recuperaríamos con historial si por cualquier motivo no quisiéramos el historial de este archivo recuperado tenemos otra opción

Recuperar un fichero borrado en una revisión anterior eliminando su historial

$ svn cat http://svn.example.com/repos/calc/trunk/para_borrar.txt@31 > ./para_borrar.txt
$ svn add para_borrar.txt
$ svn commit -m "Re-creado el fichero para_borrar.txt de la revisión 31"

Recupera un fichero borrado en una revisión anterior sin tener una copia de trabajo

$ svn copy http://svn.example.com/repos/calc/trunk/para_borrar.txt@31 http://svn.example.com/repos/calc/trunk/para_borrar.txt -m "Recuperamos para_borrar.txt borrado en la revisión 32"

Espero que os haya sido de utilidad.

Publicado por Abraham Covelo