Categoría: código abierto

Categorías
código abierto Mundo 2.0 programación Tutoriales WordPress

Trabajando con SVN (y WordPress)

Esto es un reblog de trabajo para no perder el archivo. Cómo usar SVN para tus traducciones de WordPress, en inglés. Lo guardo por histórico, porque en próximas versiones esta forma de trabajar dejará de funcionar.

Using SVN in your translation flow is not as hard as it seems. If you know some of the basics, you can update a repository (for themes, plugins, or core) in an easy way. Let’s begin :).

We are going to work with the example of the Spanish (Spain) translation. What do we need to begin with?

Permissions

First of all, we need to have permissions granted to write to our Subversion repository. We can ask for this access in the make/polyglots site.

make-polyglots

Don’t forget to:

  • Ask for access politely
  • Indicate your wp.org user
  • Indicate the repository you want access to (you need to be a validator for your language to be granted commit access)
  • Tag your post with request. Locale tags are not needed, as they are automatically associated with validators, but they will be appreciated by others translators and validators.

Creating your own local copy

Now that you have access to the repository, you need to make your own local copy to work with it.

First, you need to locate your locale’s repository. You can look for it in https://i18n.svn.wordpress.org. Once you have located it, copy the URL. For the Spanish example, the URL is https://i18n.svn.wordpress.org/es_ES/

The next step is to make the copy. If you are a Mac or Linux user, you only need to go to a terminal. If you are a Windows, user, you can install Win32SVN to work with a terminal with SVN.

We are going to use SVN. SVN is an abbreviation for Subversion, a software versioning and revision control by Apache. SVN (and other revision control software, like git) allow the programmers to work in a collaborative way and allow to all the people involved to look at and review the code, modify it, and revert it if there is any problem.

Once you have your terminal ready, you need to write this with your own locale:

svn-co

Now you’ll see a lot of archives being copied, and you will have all your locale repository copied in your local directory.

archive

copied

SVN basics

Note that you are right now in a SVN repository. You can see what others have done in the repository by using the command svn log. When you submit your changes, others will see your activity in the logs.

SVN is a little wayward. When you are in a SVN repository, you need to remember to alway use the command svn to do things.

  • if you want to copy something, you need to use svn copy or svn cp
  • if you want to move something, you need to use svn move or svn mv
  • if you want to delete something, you need to use svn delete or svn del
  • if you add a new file to a directory and want it to be in the SVN repository, you need to use svn add <file> to add it to the next commit

You have a list of all the available commands writing svn help in your local repository.

blame

Creating a new tag and/or branch

Now that we have our local repository, we need to create our new branches and tags. We are going to work with the example of WP 4.0-alpha.

As we see before, when you create a new file or archive you need to add it to the repository. If you do not add it, you will not be able to commit your files to the repository.

To make things easier, we are going to svn copy a prior directory and modify the files.

First step, we go into the tags directory. We will have a list of all prior tags.

Now, we copy the last directory created to a new one with our version:

svn-cp

Done! Now we can navigate with our browser to make things easier.

Understanding the repository

In our new directory we will see two directories: dist and messages.

The dist directory has this content:

  • license.txt – the license archive
  • licencia.txt – name may vary. This is the license in your language.
  • readme.html – the readme file in your language.
  • wp-admin/setup-config.php – a translated version of the setup in your language
  • wp-config-sample.php – a translated version of the config sample in your language

The messages directory has this content:

  • admin-xx_XX.mo – the translation archive for the administration ( link )
  • admin-xx_XX.po – .po version
  • admin-network-xx_XX.mo – the translation archive for the network administration ( link )
  • admin-network-xx_XX.po – .po version
  • continent-cities-xx_XX.mo – all the translated Continents and Cities to your language ( link )
  • continent-cities-xx_XX.po – .po version
  • xx_XX.mo – the main WordPress translation ( link )
  • xx_XX.po – .po version
  • twentyxxxxx – the translation of each official theme (various directories)
    • xx_XX.po
    • xx_XX.po

Updating your files

At this point, we need to update the files of our new directory to commit the new version. To do this, we need to know how are we going to build the new package.

packagesIf you are going to use the translate.wordpress.org option,

  • All the installation and setup archives will be read from our new /dist directory (and we will tell the system where they are)
  • The translations will be read from the translate.wordpress.org site

If you choose the Subversion option,

  • All the installation and setup archives will be read from our new /dist directory (and we will tell the system where they are)
  • All the translations will be read from our translations svn directory (and we will tell the system where they are)

You should always try to use the first version. If you need to use the second version, then you will need to:

  • go to each one of the translation sites in translate.wordpress.org (you have the links here)
  • export the translations in .po and .mo versions
  • change the names of the archives to match the list before
  • put them in the svn directory in their correct place

Regardless the option we want to use, we need to update the archives in the dist directory. Usually, you will only need to update the version number in the readme.html file. If you need to do something else, it will be mentioned in the make/polyglots site.

readme

After finishing with the archives and changes, we can use the command svn status in our parent directory to see the changes that are going to be committed.

svn-status

Committing changes

  • If we are committing a minor version (3.9.1 for example), we will need to commit a tag with the new version
  • If we are committing a major version (4.0 for example), we will copy this new tag to a branch to upload the tag and branch

svn-branch

If we are using the Subversion option we will see the list of all .po and .mo archives; it’s a good idea to update the .mo and .po archives in the /trunk directory as well.

If we are using the translate.wordpress.org option, we are ready to commit our changes.

The command to commit our changes is svn commit or svn ci. We will add a message using the -m subcommand, containing:

  • the version we are uploading
  • the language we are uploading
  • please use english to make understanding easier

svn-commitAnd done! We are ready to go to our local WordPress.org site and build the new version of WordPress.

Building a localized WordPress  version

If you have just committed the files to the repository, you will need to wait a bit to see it appear in your local WordPress.org site.

Once it’s working, you need to select:

  • the translate.wordpress.org option
  • the /dist/ directory
  • the development (trunk) project

The WordPress version will change and you will see the last version in development. The revision number will be ignored, it only works in the Subversion option.

version-2

If you want to build an official release version, you will need to look in the project list and select the one that you are looking. You will get the last minor version released. Again, the version will be automatic and the revision number will be ignored.

version-prior

You can build and distribute as many beta and release candidate versions as you want. They will automatically go to the beta and release candidates place.

rc-versions

Categorías
código abierto Mundo 2.0 Personales

Instagram y la libertad

Esta mañana, al levantarme, leía a Hugo en Facebook. Y, automáticamente, pasaba a leerlo en su blog.

Su cuenta de Instagram está cerrada. Ayer, en un concierto, hizo lo que hacía siempre. Subir algunos fragmentos de vídeos del mismo, y así darle publicidad entre sus seguidores en la red social.

Hoy, la sorpresa.

We’ve removed or disabled access to the following content you posted on Instagram because we received a notice from a third party that the content infringes their copyright(s)

Tal como cuenta, no tiene a dónde reclamar. No ha habido aviso. La cuenta se ha cerrado, con sus más de 900 fotos, interacciones, recuerdos, momentos, comentarios… Todo eso que creamos artificialmente alrededor de un momento capturado, ahora está perdido.

No es sólo que Janet se esté haciendo la peor publicidad que podría con esta preciosa acción de sus abogados. Aquí hablamos de libertades. Y bien lo dice Hugo:

Hay una delgada línea para estas compañías de redes sociales… necesitan usuarios para existir, pero los usuarios no son los clientes. Son el producto que se vende a los publicistas.

Esto es tan cierto como problemático. Instagram cerró muchas cuentas ayer a causa de Janet Jackson. Y esto nos recuerda que Instagram, o Facebook, su empresa madre, son espacios donde nos comunicamos con otros, pero no son libres, y el contenido que publicamos allí no es nuestro. Vive, o sobrevive, mantenido por el antojo de unos cuantos a los que hemos dado (aquí sí) libertad casi absoluta sobre nuestro contenido en sus términos y condiciones de uso.

Porque sí, lo que publicamos en Facebook es nuestro, pero…

Eres el propietario de todo el contenido y la información que publicas en Facebook y puedes controlar cómo se comparte a través de la configuración de la privacidad y de las aplicaciones. Asimismo:

1 En el caso de contenido protegido por derechos de propiedad intelectual, como fotos y videos («contenido de PI»), nos concedes específicamente el siguiente permiso, de acuerdo con la configuración de la privacidad y de las aplicaciones: nos concedes una licencia no exclusiva, transferible, con derechos de sublicencia, libre de regalías y aplicable en todo el mundo para utilizar cualquier contenido de PI que publiques en Facebook o en conexión con Facebook («licencia de PI»). Esta licencia de PI finaliza cuando eliminas tu contenido de PI o tu cuenta, salvo si el contenido se compartió con terceros y estos no lo eliminaron.

Recordad. WordPress es libre. El contenido es vuestro. Y está hecho a prueba de abogados de Janet Jackson.

Categorías
código abierto Jornadas, convocatorias y kdds

En el JoomlaDay™ Sevilla

La previa

El sábado pasado estuve en el JoomlaDay™ Sevilla. Isidro me invitó a estar, y me propuso además encargarme de la Keynote, la ponencia inicial.

Al principio dudé bastante. Ir al JoomlaDay™ Sevilla, por supuesto. Isidro y Penyaskito han pasado bastante por nuestras WordCamps, y nos han mostrado que tenemos mucho que aprender unos de otros. Era una oportunidad estupenda que no iba a dejar pasar. Además también iba Iñaki, así que nos íbamos a reunir gran parte de los Pixelated Heart. Pero eso de invitar a un tipo de WordPress no lo veía tan claro.

Isidro, Juanka y Enrique sí lo tenían claro, así que me busqué algo que pudiera interesar a todos y que hiciera que mereciera la pena la invitación: aparqué WordPress, me puse la chaqueta de Código Abierto, y les conté cosas sobre Software Libre.

¿Y qué cosas aprendí en el JoomlaDay™?

Pues aprendí cosas de Joomla!

No soy nuevo en Joomla!, empecé a programar con PHP haciendo módulos y extensiones para Mambo Server, pero de eso hace al menos todo el tiempo que llevo trabajando con WordPress, que son ya 9 años.

Hubo cosas que me gustaron de Joomla! Por ejemplo, la integración de módulos en la instalación que a día de hoy utilizamos casi todos, como el de SEO. O que en algunas secciones tengan el UI/UX muy cuidado y sea muy sencillo trabajar en el backend. O su trabajo tan avanzado con el resposive.  Hubo otras que me asustaron. Como la precariedad de la instalación de temas y plugins, y lo manuales que son otros procesos que tenemos automatizados desde hace tanto tiempo, llevando en el mercado también más de 10 años.

Internamente, a los Pixelated les ha servido también para, a través de la comparación de CMS, darse cuenta de que saben de WordPress y programación más de lo que pensaban.

En definitiva, cosas suficientes como para saber que tenemos donde aprender, y que también podemos aportar cosas a su ecosistema.

Sobre la organización y el evento en general

En la primera vez que se enfrentaban a la organización de un evento como este (al menos Isidro), me contaban desde primera hora que no es lo mismo asistir a un evento que organizarlo. Y aquí, claves que tuvieron en cuenta y que creo que son dignas de mencionar:

  • Parte de los organizadores no presentaron ponencia, para poder estar 100% pendientes de la organización. Hacer esto al menos en su primera vez, hasta ver qué implica realmente organizar el evento, me parece un acierto.
  • El horario se cumplió al minuto (y me alegró de ser culpable en parte de haberles transmitido que eso es importante con nuestros eventos)
  • Hubo viandas para los asistentes en todo momento, tanto comida como bebida (y principalmente agua)
  • ¡Había agua para los ponentes! Me había llevado una botella por si acaso. En los últimos dos eventos en los que estuve se olvidaron de que si hablamos mucho tenemos que beber también, pero estuvieron en todo 🙂
  • Tenían un ordenador disponible por si el ponente no tenía el suyo
  • Tenían una copia de todas las ponencias en PDF en el ordenador disponible, por si algo fallaba (Plan B). Y ese ordenador estaba siempre en la mesa.
  • Todos los ponentes llevaban las ponencias bastante bien preparadas. Así que bien por ellos también.
  • El público estaba muy entregado. Joomla! tiene también una Comunidad muy interesante (es también una Comunidad de  Software Libre, es normal 🙂 ).

El feedback de cosas a mejorar ya se lo comenté directamente a los organizadores. Y lo bueno de los eventos es eso. Tenemos que ver las cosas buenas que queremos repetir, y mejorar las mejorables.

Por mi parte, espero tener la oportunidad de ir a otro JoomlaDay™ que sea cerquita, porque me lo pasé muy bien y conocí a gente muy interesante. Sin desmerecer algún que otro roce WordPress-Joomla!, como era de esperar 🙂 .

Categorías
código abierto Jornadas, convocatorias y kdds WordPress

Keynote del JoomlaDay™ Sevilla

SL.001

Buenos días

A mí me toca hoy abrir el JoomlaDay™.

Seguir leyendo «Keynote del JoomlaDay™ Sevilla»
Categorías
código abierto Mundo 2.0

Usando git en (pre)producción

Desarrollando con git

Desarrollar es un trabajo pesado, eso lo sabemos todos. Sobre todo, si queremos cumplir con todas las buenas prácticas que deberíamos.

Una de esas buenas prácticas es llevar un control de versiones de tu software. No porque necesites separar la versión 1 de la 2, sino porque llevar un control de versiones exhaustivo te ayudará después a encontrar errores, a poder revertir cambios, y a que otros (o tú mismo dentro de dos meses) puedan revisar tu código para ayudarte a mejorar.

Muchos de nosotros, cuando estamos desarrollando algo, lo hacemos en un estado que llamamos de preproducción. Esto sólo quiere decir que nuestro desarrollo no está abierto a todos, visible. Por tanto, es un sitio de pruebas, donde nos da igual que se escupan errores por pantalla, o que la página esté descuadrada.

Cuando estamos haciendo ese trabajo podemos hacer 100-200 cambios al día, y llevar un control de versiones de cada uno de los cambios que hacemos se puede convertir en algo pesado. ¿Cómo lo convertimos en algo asequible? Automatizándolo.

El scripting

Soy de los que usan git (y SVN) desde consola. Para mí es mucho más rápido porque juego con el scripting.

Por un lado, tengo una serie de alias definidos:

  • alias fp=’git format-patch’
  • alias ga=’git add .’
  • alias gc=’git commit -a -m’
  • alias gp=’git push origin master’
  • alias log=’git log –pretty=oneline’
  • alias sinc=’sh /Users/raven/Git/sinc’
  • alias st=’git status’

De esta forma, cada vez que tengo un cambio nuevo, los comandos a ejecutar son los siguientes:

> ga
> gc "mensaje de descripción del commit"
> gp

Mi estructura de directorios incluye, en mi carpeta de usuario, una carpeta /Git donde tengo todos los repositorios de trabajo. Para cada uno de ellos tengo un pequeño script que lanza una sincronización con el servidor, de forma que si he cambiado algo allí, ese cambio se reflejará en mi directorio local.

Así, sólo tendré que ejecutar un comando, y se actualizará mi copia local. Todos los scripts de actualización los tengo en la carpeta /Git, en vez de dentro de cada uno de los repositorios, para que no interfieran con las copias.

git/raven.es> sh ../raven.sh

Ese archivo raven.sh tiene el siguiente contenido, que cambia para cada uno de los repositorios:

expect -c 'spawn rsync -avrhz -e "ssh -p" --progress --delete --exclude-from "/Users/raven/Git/exclude.txt" MIUSER@MISERVER:MIDIRECTORIO/raven.es/ /Users/raven/Git/raven.es/ ; expect password ; send "MIPASSWORD;\n" ; interact'

Este archivo exclude.txt tiene, en cada línea, nombres de archivos o directorios que se ignorarán en la sincronización, y puede tener el contenido que necesitéis. En mi caso, el archivo tiene el siguiente contenido:

sources
public_html/database.*
core.*
.svn
.git
stats
backup_site
backup
*/backup
versiones-backup
uploads
blogs.dir
upgrade
logs
cgi-bin
*.tar.gz
hiccup
wp-content/uploads/
wp-content/blogs.dir/
wp-content/upgrade/
error_log
*/error_log
cache
*/cache

Automatizando aún más

En mi directorio Git también tengo un archivo, sinc, que lanza la sincronización de todos los repositorios, lanzando uno a uno los sincronizadores individuales.
Aquí las posibilidades son múltiples. Dependiendo de vuestra forma de trabajar, os puede interesar lanzar la sincronización y el git add en la misma orden, o hacerlo todo en bloque. Podéis fabricaros vuestro propio script a medida.

Lo que tenéis que recordar es una cosa importante. Si hay algo que hacéis muchas veces de forma parecida, invertid tiempo en automatizarla. En muy poco tiempo notaréis la diferencia.

Categorías
código abierto

Código abierto explicado con legos

Podéis activar los subtítulos en español. Son automáticos y algunas veces son literales, pero hacen que se entienda todo muy bien.