Porqué no hay que tener miedo de la palabra Pucherazo

campana_1881Estos días estamos viviendo una oleada de suspicacia por parte de los simpatizantes de Podemos, entre los cuales, en este momento, me encuentro. Además de Fraude, la palabra más oída ha sido Pucherazo. Parece que esta palabra da mucho miedo, solo de pensarlo a algunos se les estremecen las canillas y se les aflojan los esfínteres.

No, a nosotros no, eso son los países tercermundistas los que sufren este tipo de cosas, nuestro sistema es perfecto.

Bueno, no quiero quitarles la ilusión, que hasta hace poco era mía, pero si que me voy a permitir deciros por qué no hay que tener miedo de expresar las dudas y porqué nuestro sistema puede ser perfecto, pero puede ser igualmente vulnerado.

Primero, ¿quién dijo miedo? Las garantías que hay en nuestro ordenamiento administrativo y jurídico para asegurar que las elecciones sean limpias e imparciales me parecen, simplemente, impecables. Sin embargo, seríamos cómplices por dejadez si no estuviésemos vigilantes de que todas las medidas orientadas a evitar el fraude se han tomado adecuadamente. Si nadie pone en duda el sistema, ¿quién avisará cuando este sea vulnerado? Ni siquiera sitios tan «democráticos» como EEUU ha quedado libre de los «pucherazos» electorales, y no lo digo yo, lo dicen aquí, por ejemplo. Lo bueno de todo esto es que con una ciudadanía vigilante y unos garantes aleccionados a seguir alerta todo puede funcionar correctamente. ¿Miedo a mostrar dudas? Ninguno. Lo peor que puede pasar es que estemos equivocados y, en ese caso, seremos los primeros beneficiados… Así que, ¿quién dijo miedo?

Segundo, ¿el sistema perfecto? Desde que algunos mostrasen sus dudas, e incluso que algunos intentaran aprovecharlas para colar HOAX falsos o portadas de periódicos trucadas, salieron muchos artículos defendiendo lo «perfecto» de nuestro sistema electoral, donde destaco este de David Fernandez: No, el 26J No hubo pucherazo (ni puede haberlo), artículo donde explica muy bien el funcionamiento de las mesas electorales y desmonta los hoax (o similares) que pretendían demostrar pucherazo en las mesas electorales. No obstante, en el artículo y en los comentarios posteriores, queda demostrado que no hay auditoría sobre la transmisión de datos ni el tratamiento inmediato de los datos provisionales. Es decir, el programa que recoge los datos desde las apps de los delegados de la administración que hay en cada mesa puede hacer con esos datos lo que quiera sin que nadie lo sepa en ese momento. Imaginemos, por un momento, que, por error informático, se produce una mezcla de los datos de algunos partidos con otros en esa recogida de datos, los resultados provisionales serán completamente distintos de los reales, habiendo sido las mesas completamente decentes y habiendo cumplido al 100% con su cometido.

Evidentemente la ley prevé que haya un recálculo global en las juntas electorales provinciales a la vez que se añade el voto de los Españoles residentes fuera del país, pero tal como se vió en Sevilla en el 22-M (no lo digo yo, de nuevo, lo dicen aquí y fue una realidad) es costumbre dar por válido el recuento provisional y solo añadir el voto de los residentes en el extranjero. ¿Qué problema tiene esto? Que realmente se confía al 100% en un sistema que no ha sido auditado debidamente y no se puede corregir los errores humanos en este segundo recuento. Esto, y nuestra maravillosa ley D’Hont puede hacer bailar escaños a los distintos partidos (incluso solo por errores). Así que, si no se exige un completo escrutinio general «de verdad» hay muchas posibilidades de que la realidad no coincida con las cifras.

Tercero, ¿porqué dudo?, visto que el sistema no es perfecto, que tenemos un intermediario que no es fedatario público y que no ha sido auditado y en vista de las variaciones tan poco comunes entre las encuestas a pie de urna (estaríamos hablando de las mayores variaciones desde que se hacen) y las encuestas previas (incluida la del CIS) no puedo sino tener una duda «razonable».Además, siempre he creído que el pueblo español podía ser engañado durante un tiempo, pero ver un repunte de votos de un partido corrupto y de demostrada toxicidad para la sociedad Española me parece más increible si cabe.

En cualquier otro momento de nuestra corta historia democrática ni me hubiese planteado que hubiese podido haber algo raro, pero vivimos unos momentos donde el gobierno ha cobrado en dinero negro de oscuros contribuyentes, que ha repartido beneficios con turbios amiguetes, que han utilizado el poder en su beneficio como partido y que alimentado una caverna mediática y un estado de opinión más de hooligan que de discusión política… Por eso dudo, y espero fervientemente que el escrutinio general termine por aclararme y borrarme de una vez las dudas. Cualquier otra cosa sería un pucherazo en toda regla y la mayor estafa perpetrada contra los españoles.

ACTUALIZACIÓN 1: En sitios no tan lejanos ni tercermundistas hay quien ha impugnado elecciones y no se les ha caído la democracia. Como en Austria (ver noticia).

ACTUALIZACIÓN 2: Qué se está haciendo en podemos para verificar los datos.

La épica del informático

programmingHoy toca una entrada para alabar la tarea de nuestros trabajadores del conocimiento (eufemismo clase Dios) que son, como no, ninguneados e ignorados silenciosamente por el público en general y por sus jefes en particular. Pero esperad, antes de eso, un «mea culpa»… ¿Porqué los profesionales de la informática son tan despreciados en esta, una sociedad construida en base a su esfuerzo? Os diré mi opinión… Porque acostumbramos mal a nuestros clientes. Nos piden lo imposible y se lo damos, nos quejamos, nos revolvemos contra la ignoracia atrevida del que nos pide la luna pero finalmente cedemos y eso es lo que nos conduce inexorablemente a las mazmorras de nuestro propio talento.

Si alguien pide un presupuesto a un fontanero para que le ponga un grifo debajo de la cama (por estúpido que eso sea) y consigue un profesional que no se descojone de su ocurrencia y le de el presupuesto lo más normal es que consiga su grifo y nada más. Imaginemos la conversación:

  • Cliente: ¿Qué es esto que me has puesto aquí?
  • Fontanero: un grifo
  • Cliente: pero está debajo de la cama, ¿cómo voy a poder usarlo así?
  • Fontanero: es lo que pidió
  • Cliente: si, claro, pero es de sentido común que un grifo debajo de la cama debe tener algo que permita que se use desde encima de la cama
  • Fontanero: eso no es mi problema
  • Cliente: venga, no me vengas con esas, un grifo que no se puede usar no te lo voy a pagar.
  • Fontanero: es lo que has pedido y es lo que tienes que pagar
  • Cliente: ya, pero al menos harás que se pueda usar desde la cama
  • Fontanero: solo tienes que bajar de la cama y amorrate al caño
  • Cliente: eso no es práctico
  • Fontanero: ya ¿y?
  • Cliente: venga, me haces un apaño para que pueda usarlo desde la cama y luego te contrato la pila del baño
  • Fontanero: ni de coña, aquí tiene la factura.
  • Cliente: bueno, vuelve dentro de un mes y te pago junto con el resto de..
  • Fontanero: ahora
  • Cliente: esto…
  • Fontanero: ¿Pagas o me llevo el grifo y se te inunda la casa?

Bueno, algo así… Los clientes suelen ser más razonables con los fontaneros que con los informáticos, porque, total, seguro que a los informáticos les gusta hacer mal su trabajo y no ponen todas las cosas que tienen que poner porque son vagos.

¡Pues no!

Los informáticos, y los programadores principalmente, son héroes. Gente que consigue lo imposible, que cumple con requisitos inverosímiles, que estira el tiempo disponible hasta lo absurdo para conseguir terminar algo que, probablemente, luego sea mal juzgado por algún ignorante en la materia. Los programadores más experimentados crean obras de arte en unas líneas de código que, aunque podrían ser admiradas en museos donde otros programadores no puedan más que deshacerse en halagos, al final son ejecutados una vez por alguien que no está preparado ni para programar una lavadora y obtienen un comentario estúpido sobre el número de clicks que hay que hacer… Estos héroes anónimos mueven nuestro mundo, allí donde mires hay un programa que escribió alguien, que hace más sencilla tu vida, o que te permite hacer cosas impensables hace solo unos años. Estos héroes sin nombre que, por lo menos en España, están mal pagados, mal vistos (como si picar código al azar en un editor fuese programar), mal dirigidos por gente sin criterio y sin empatía. Formando parte de hojas excel que los mide en kilos de carne y los vende y los compra a otros patanes con ínfulas que creen que hacer informática es un simple problema de coste.

Por todo ello, amigo gerente, si alguna vez un programador te intenta explicar lo difícil que es conseguir algo, entiéndelo como un cumplido que te hace intentando dejar que veas una porción pequeña de su complejo mundo interior. Intenta comprender que no te está intentando dar una excusa, sino describiéndote el peligroso campo de batalla en el que va a meterse en tu nombre y dar hasta su última gota de sudor y sangre para acabar con el enemigo y conseguir esa funcionalidad que tu describes en una frase pero que eres completamente incapaz de explicar en sus detalles (o, simplemente, no quieres hacerlo por pereza).

Día a día, proeza a proeza, sin parar, sin esperar recompensa, sin aparecer en los libros de historia (ni siquiera viendo reconocida su propiedad intelectual muchas veces), el programador anónimo sigue siendo el motor de esta sociedad y, desde aquí mi más sincero agradecimiento a todos ellos. Y, por favor, dejad de tratar a los gerentes como niños, que ellos no quieran escuchar los problemas no significa que estos no estén ahí y que merezcan verlos con sus ojos… Igual así despiertan y os empiezan a tratar como lo que sois, los nuevos magos de la tecnología moderna.

Internacionalizar una web en php

main_icoDespués de muchos meses trabajando en una aplicación que, por azares del destino, alguien decidió que se realizase en php utilizando como frontend Drupal (del que solo se utiliza el sistema de registro y poco más) y después de infinitos test de usuarios (que nunca son suficientes) y después de generar un proyecto con 31.000 líneas de código propias (el total sin contar drupal suma más de 203.000) llega el momento de venderlo.

El primer cliente siempre es el peor, pero es que el segundo ¡es holandés! y, claro, lo quiere en inglés… Y algún lumbrera le asegura que tendrán la versión en inglés ¡¡en una semana!!. Lo bonito del tema es que cuando aseguró eso no preguntó a nadie del equipo de desarrollo. ¿Para qué? Las fechas las ponen ellos, qué más da que sea algo imposible.

Total, que, de casualidad, nos enteramos de que hay que hacer este «pequeño» cambio, las traducciones no serán un problema, porque tenemos gente que puede hacerlo bien y rápido, pero, ¿cómo internacionalizamos el php? La parte que cubre Drupal (y que podría traducirse desde el mismo sistema) es mínima, en total tenemos 425 archivos php donde hay textos en castellano en cualquiera de ellos, además, parte en html, parte en php y parte en javascript… Cualquier otro programador hubiese presentado su carta de renuncia o hubiese pedido una baja laboral. Además, ya nos han dicho que no piensan pagarnos las horas extras y que si cometemos errores tendremos que arreglarlos en nuestro tiempo libre.. ¡Eso si que son condiciones laborales y no las de los mineros de asturias!

Sin embargo mi responsabilidad como profesional me obliga a atender las peticiones por absurdas que sean e intentar dar soluciones… Así que os pongo un resumen de lo que hicimos:

Problema número 1: qué sistema de internacionalización usar.

Al contrario que Java, que dispone de un sistema i18n con properties desde el principio, php adolece de este mecanismo estandar. Después de valorar varias opciones (muchas usadas en programas populares como prestashop, etc.) descubrimos que lo mejor es utilizar gettext.

Gettext es un proyecto GNU que, afortunadamente, es utilizado muy ampliamente en Linux para proporcionar internacionalización a sus programas. Es por ello que está presente en la mayoría de las distribuciones (incluyendo las que usamos para desarrollo y pruebas) y, además, tiene un módulo para php que también está normalmente incluida en las instalaciones normales de php (incluso en XAMPP está).

¿Cómo funciona gettext? Básicamente se basa en localizar todas las cadenas de texto ya escritas y sustituirlas por una función que la traduce. En el caso de php esta suele ser la función gettext(‘cadena’) o, abreviada _(‘cadena’). De esta forma, el texto en html:

<p>Esto es un texto</p>

Lo modificaremos en:

<p><?php _("Esto es un texto")?></p>

Luego el sistema localizará, según los parámetros de idioma, su traducción y la escribirá. Si no encuentra ninguna escribirá esa misma cadena.

Así que el primer, y más tedioso, problema es sustituir todas las cadenas de texto en nuestro programa por estas sustituciones. No hay una forma única y automatizada de hacerlo, porque podemos encontrarnos texto dentro del código php, dentro de etiquetas html o incluso dentro de código javascript y dependiendo de dónde se encuentre esa cadena deberá traducirse (o no).

Problema número 2: traducir las cadenas

Una vez que tenemos «marcadas» todas nuestras cadenas, deberemos generar un archivo con las traducciones… Esto ya es más sencillo de automatizar porque podemos utilizar herramientas que ya existen. La más adecuada es poedit. Esta herramienta nos permite escanear directorios de fuentes y almacena las cadenas que no están traducidas en un catálogo para después permitir que un traductor las vaya traduciendo sin tener que saber nada de php.

Antes de utilizar poedit es muy recomendable que establezcamos las rutas de los directorios donde vamos a guardar los catálogos traducidos. Generalmente esto se hace en el directorio raiz de la aplicación creando estos directorios:

locale/xx_XX/LC_MESSAGES

donde xx_XX es el código del idioma y país (en_GB en nuestro caso). Dentro de cada uno de esos directorios almacenaremos los .po (y .mo que compilamos) que generaremos con poedit.

Una vez creados los directorios, arrancamos el poedit y lo configuramos indicando que el directorio principal será «.» y los directorios a escanear serán ../../../ (suponiendo que hemos respetado la estructura que os he comentado). También es importante el tema de los plurales que, en caso del español sería:

nplurals=2; plural=n != 1;\n

Una vez todo en su lugar solo tendremos que actualizar para que poedit busque en todos los archivos y nos encuentre todas las cadenas que se pueden internacionalizar. Utilizando el mismo programa podemos hacer que los traductores nos traduzcan las cadenas y nos devuelvan el mismo .po ya traducido.

Problema número 3: hacer que el sistema use el idioma del usuario

Para que funcione gettext para php hay que incluir las siguientes líneas al principio del script:

putenv("LC_ALL=$locale");
setlocale(LC_ALL, $locale, 'english');
bindtextdomain("messages", __DIR__."/Locale");
bind_textdomain_codeset("messages", 'UTF-8');
textdomain("messages");

Lo relevante ahí es que $locale ha de contener el idioma (en_GB) messages es el nombre que tiene el catálogo poedit (así tendremos un messages.po en el directorio correspondiente) y que a bindtextdomain hay que pasarle el directorio donde hemos colocado nuestros locales.

Para el caso de drupal vamos a utilizar el idioma que el usuario ha puesto en su perfil, por lo que el código adicional a utilizar es:

global $language;
$locale = $language->language;
if ($locale=='en')
    $locale="en_GB.utf8";
else
    $locale = 'es_ES.utf8';

Esto es así porque los locales han de ser tal como están en el sistema operativo y, sin embargo, los idiomas en drupal solo indican el idioma y no el locale.

Seguimos en ello (hay muchos archivos) y además, nos queda pendiente la internacionalización de los correos y de los informes que generamos… Seguiremos informando.