Mientras aguardábamos a que nos atendieran, me he puesto a curiosear con el móvil por el sitio web del Coto Valdorba, y, oh sorpresa, me he dado cuenta de que está elaborado con WordPress y con el tema Graphene. Enseguida se me ha ocurrido que no podía desaprovechar la coincidencia, y me ha venido una idea muy sabrosa (¡nunca mejor dicho!) a la cabeza: diseñar algo así como una hipotética ruta turístico-gastronómica-bloguera, cuyos hitos coincidieran con sitios web relacionados con la gastronomía que estén escritos, total o parcialmente, en español y hayan sido realizados con WordPress y el tema de Syahir Hakim.

Dicho y hecho. Tras regresar a casa, despertar de la siesta, comprobar que –¡por fin!–, Osasuna ha ganado su primer partido de la temporada y deja de ser colista, he navegado un rato por la Red, en busca de webs que reunieran los requisitos que acabo de mencionar. Con los primeros resultados obtenidos (la búsqueda no ha sido ni mucho menos exhaustiva), propongo a continuación una ruta turístico-gastronómica, que de momento habrá de ser exclusivamente virtual.

El viaje comenzará, claro está, por la Navarra Media, para luego desplazarse hasta la costa mediterránea española, donde nos aguarda la hermosa localidad de Nerja, y nuestro primer sitio web grapheniano (o graphenesco), Tapas-bars Nerja & Torrox (en inglés y español) que da cuenta de la rica variedad de tapas de la comarca malagueña de la Axarquía.

A continuación, el recorrido por los sitios web de restaurantes vestidos de Graphene nos obliga a coger el avión y volar a los Estados Unidos, donde encontramos dos ciudades de la costa este: Stamford, en Connecticut, sede del restaurante y panadería de comida guatemalteca The Maya, y Los de patanegra, un sitio web mantenido por la comunidad española de Pittsburgh, Pensilvania, que por supuesto presta toda la atención que se merece a la cocina de nuestro país. Sin salir de los Estados Unidos, aunque en la particular condición de estado libre asociado, quizás nos interese visitar el sitio Foodiespr.com, dedicado a patrocinar los atractivos gastronómicos de Puerto Rico.

Cruzamos la frontera entre Estados Unidos y México y, como era esperable, nos encontramos con una amplia variedad de sitios web: el blog de la empresa mexicana Mónica Gómez Banquetes; la web Bestinplaya.com, dedicada a loar las bellezas y las ricas viandas de Playa del Carmen, en el estado atlántico de Quintana Roo; y Vallarta a la carta, otro sitio de promoción turística, aunque en esta ocasión de la localidad de Puerto Vallarta, en el Pacífico.

Algo más al sur visitaremos la hermosa ciudad de Guayaquil, en Ecuador, sede de Viva Guayaquil. Y ya en territorio andino, los sitios web de un local chileno, Restaurante El estudiante, en Antofagasta, y el portal de promoción turística argentino Maipú, cuna del vino y del olivo, consagrado a la ciudad mendocina.

Si ustedes, amables lectores de La Bitácora del Tigre, paran por alguno de estos lares o entran en cualquiera de los restaurantes graphenianos que acabo de mencionar, díganles a sus responsables que van de parte de Eduardo Larequi, autor de la traducción al español del tema Graphene. A ver si les invitan, o al menos les hacen un descuento, a cargo del ahorro que representan las 620 líneas que contiene la traducción. Ya sé que hay que echarle morro (yo no me he atrevido a hacerlo en el restaurante del Coto Valdorba), pero por intentarlo no se pierde nada.

Esta entrada El Tigre gastronómico y el tema Graphene ha sido publicada en primer lugar en La Bitácora del Tigre.

Quiero comenzar este primer artículo de la serie por la explicación de aquellos principios que han guiado el proceso de adaptación, lo cual me llevará a profundizar en las características de Hybrid y en algunas funcionalidades del tema (y de WordPress) que permiten un altísimo grado de personalización de los sitios web elaborados con este magnífico tema.

1. Mantenimiento del aspecto visual característico del blog

Tras instalar el tema Tarski, en mayo de 2006, el blog adoptó un patrón visual muy limpio, casi minimalista, con grandes espacios en blanco, escaso aparato gráfico y una tipografía nítida y coherente. Me he fijado la meta de mantener, en la medida de lo posible, ese patrón de diseño, propósito que el tema Hybrid favorece, pues su aspecto visual responde a principios muy semejantes. No obstante, la renovación del blog ha supuesto algunas modificaciones importantes:

• Las páginas del sitio web tienen mayor anchura que antes (960 píxels frente a 760), lo cual implica también una imagen de cabecera más amplia. Por cierto, he conseguido el efecto de daguerrotipo aplicado a los ojos del tigre siguiendo el tutorial Efecto Daguerre (difuminar bordes) en Photoshop.
• La caja de texto también es más ancha que antes (620 píxels frente a 500). La ganancia de espacio proporciona más claridad al texto, sin comprometer su legibilidad.
• El diseño hace uso de una tipografía con remates o serifas, basada en la fuente tipográfica Georgia, lo cual marca una diferencia muy clara con la que hasta ahora venía utilizando (Verdana).
• Las páginas de archivo o índices, es decir, las páginas correspondientes a los listados de artículos por fecha, categoría, etiquetas, autores, búsquedas, etc., exhiben miniaturas de 110 x 110 píxels, que el tema extrae de las imágenes destacadas. Esta característica proporciona al blog un aspecto muy elegante y profesional (véanse, a título de ejemplo, las páginas de la categoría de Fotos y la que corresponde a las entradas con la etiqueta viajes y excursiones). Naturalmente, para que esta funcionalidad sea posible es necesario que en cada entrada o página se haya incluido una imagen destacada, lo cual solo ocurre en un porcentaje relativamente pequeño de las entradas. En lo sucesivo, intentaré añadir una imagen destacada a todos los artículos que vaya creando o editando, pero es más que dudoso que pueda hacerlo con todos, por el enorme trabajo que ello supondría.
• Algunos estilos de posicionamiento y alineación de imágenes que creé en el tema Tarski con anterioridad a diciembre de 2008 no tienen su equivalente en Hybrid, porque fueron diseñados “a mano”, sin tener en cuenta los procedimientos estándar de WordPress (véanse algunos detalles del caso en Actualización a WordPress 2.7 y más sobre Barcelona). En el pecado llevo la penitencia, porque tras el cambio de tema he advertido que hay entradas mal formateadas, que tendré que corregir. Pido disculpas de antemano a los lectores que se encuentren con ellas, y les estaría muy agradecido si me informaran de cuantas anomalías descubran.

2. Consecución de un correcto etiquetado semántico y características SEO

El tema Tarski se caracterizaba por una muy buena estructuración del código HTML, pero la de Hybrid es probablemente mejor. Además, Hybrid ofrece una ventaja añadida, ya que permite etiquetar todas las entradas y páginas fijas con metadatos (véase la figura 1, donde pueden observarse los campos de título, descripción, palabras claves) que resultan muy útiles a la hora de favorecer la indexación del sitio y su posicionamiento en los buscadores, que tanta importancia tienen a la hora de localizar un contenido en la Red. Aunque hasta la fecha utilizaba para estos propósitos el plugin Platinum SEO Pack, que en alguna ocasión me ha venido de perlas para afinar los metadatos del blog (véase, por ejemplo, Sobre los riesgos de un buen posicionamiento en los buscadores), es posible que lo desactive en el futuro, pues en gran medida resulta redundante.

3. Aumento de las posibilidades de personalización

Hybrid es un tema que ofrece unas posibilidades de personalización y adaptación mucho mayores que las del tema Tarski, especialmente para aquellos usuarios acostumbrados a las interioridades del HTML, las hojas de estilo en cascada (CSS) y el lenguaje PHP. Buena parte de las hazañas que los expertos en estos lenguajes pueden lograr con Hybrid están fuera de mi alcance, pero sí he conseguido poner en práctica unas cuantas modificaciones, a saber:

• Desarrollo de un tema-hijo, en el que he incluido varios estilos modificados (para la cabecera, para el menú superior, para ciertos elementos incluidos en las reseñas, para las entradas fijas o sticky posts, etc.), plantillas personalizadas para páginas fijas (por ejemplo las del índice general y la de las etiquetas más frecuentes), imágenes, etc. He trasladado varios estilos personalizados del tema Tarski al nuevo tema, pero en este ámbito todavía me quedan muchas modificaciones por hacer. La gran ventaja de un tema-hijo es que si actualizo el tema padre (es decir, el tema Hybrid), no pierdo las modificaciones o personalizaciones que haya realizado.
• Implantación de widgets o/y de código en aquellas zonas widgetizables que están contempladas en el diseño del tema Hybrid, y en las zonas adicionales que aparecen tras la instalación de los plugins Hybrid Hook Widgets y Hybrid Hook (figuras 2 y 3). El ejemplo más notorio del uso de estos elementos en mi blog es la imagen de cabecera, insertada en un widget denominado “Header”, pero hay otros no menos importantes: la advertencia sobre la moderación de comentarios, situada sobre el área denominada “Hook: Comment Form”, la lista de entradas relacionadas, creada mediante el widget que proporciona la extensión Yet Another Related Posts Plugin y luego insertada en el área que se sitúa tras cada entrada individual, etc. También he creado widgets condicionales asociados a distintas circunstancias del blog, pero la importancia de este aspecto en el proceso de personalización aconseja tratarla con más detalle en un próximo artículo.
• Utilización de los widgets mejorados del tema Hybrid, que permiten muchas más opciones que las que WordPress proporciona de manera estándar. Por ejemplo, el widget de categorías que utilizaba en la barra lateral derecha con el tema Tarski era resultado de una laboriosa manipulación del código PHP, mientras que el actual (figura 4) simplemente hace uso de una de las cuantas opciones que ya incorpora el widget mejorado de Hybrid.

4. Documentación y soporte

Justin Tadlock, creador del tema Hybrid, brinda a los usuarios registrados en su sitio web una documentación y soporte sencillamente espléndidos. No hay más que acceder a los foros del tema e investigar por entre las casi 28.000 intervenciones que forman parte de él para darse cuenta de la aceptación que este tema ha tenido entre los usuarios de WordPress y de la muy infrecuente calidad del soporte que nos proporciona Tadlock. Para ejemplo, he aquí la respuesta que ayer me dio el autor a una pregunta que le había planteado apenas unas cuantas horas antes, sobre el resultado visual de una lista de entradas elaborada con el plugin Query Posts.

Esta entrada Adaptándome a Hybrid, 1 ha sido publicada en primer lugar en La Bitácora del Tigre.

El blog todavía requiere mucho trabajo de reajuste para recuperar en la medida de lo posible su aspecto visual característico (quiero emplearme a fondo con la creación de un tema-hijo que, entre otros requisitos, habrá de mantener los ojos felinos en la cabecera, aunque todavía no sé muy bien cómo hacerlo) y las funcionalidades de navegación que le aportaba el tema Tarski. Esta tarea me ocupará en los próximos días, así que ruego a mis lectores y lectoras que sepan disculpar los posibles fallos e inconsistencias que puedan aparecer durante esa fase transitoria.

Una nota final para los incondicionales del tema Tarski: quienes han confiado hasta la fecha en mi traducción del tema creado por Ben Eastaugh, pueden estar seguros de que no les dejaré en la estacada. Tengo intención de renovar mis traducciones conforme vayan apareciendo nuevas versiones, entre otras razones porque Tarski es uno de los temas que utiliza la plataforma Multiblog del PNTE.

Esta entrada La Bitácora del Tigre cambia de look ha sido publicada en primer lugar en La Bitácora del Tigre.

Es cierto que la existencia del repositorio oficial de temas de WordPress, cada vez más amplio, variado y con mayor conciencia de la necesidad de “localizar” los temas para permitir la generación de los archivos de traducción, facilita el mencionado objetivo, pero también lo es que muchos temas de calidad indiscutible ignoran olímpicamente tal necesidad, y que otros proporcionan un soporte limitado para las versiones lingüísticas, bien porque omiten algunas cadenas, bien porque ignoran el hecho de que no todas las lenguas comparten el orden de palabras característico del inglés, o bien porque hacen uso de mecanismos y diseños que dificultan la traducción.

A lo largo de la historia de este blog he escrito en varias ocasiones sobre estos problemas, no sólo para quejarme del imperialismo lingüístico del inglés (a la vista de las circunstancias, probablemente sería más útil y productivo protestar contra la bajada de sueldo de los funcionarios públicos), sino también para aportar unos cuantos granitos de arena a la construcción de la comunidad de practicantes de WordPress, mediante mis traducciones de temas como Graphene, News, P2, Portfolio Press o Tarski. No son los únicos, desde luego, porque si incluyera en una lista todos los temas que he traducido total o parcialmente (y en ella habría que anotar los que forman parte de la plataforma Multiblog del PNTE), estoy seguro de que la nómina pasaría de sesenta plantillas, de muy distinto tipo y condición.

Sin embargo, hasta la fecha nunca me había puesto a la tarea de traducir lo que podríamos llamar como “temas tipográficos”, es decir, temas centrados en el texto, con efectos gráficos mínimos y cuyo principal interés es la presentación armoniosa de la escritura. Creía que el interés de la comunidad bloguera en esta clase de plantillas sería más bien escaso, hasta que algunas de mis intervenciones en Twitter fueron respondidas por Néstor Alonso (aquí y aquí) y José María González Serna (aquí, aquí y aquí), lo cual me convenció de que podía ser interesante la traducción de dos temas tipográficos tan distinguidos y de tanta elegancia formal como The Erudite (figura 1) y Typominima (figura 2).

No me extenderé sobre las características de ambas plantillas, pues ya están descritas en sus respectivos sitios web, aunque creo que conviene hacer algunas puntualizaciones sobre las traducciones que ofrezco a continuación. The Erudite forma parte del repositorio oficial de WordPress, y aunque cuenta con ficheros es_ES.po y es_ES.mo, la traducción es incompleta, porque hay unas cuantas cadenas en el código original que no están preparadas para ser traducidas. El paquete ZIP que ofrezco al final de este artículo subsana esas deficiencias y mejora, por tanto, el resultado final del tema en su aplicación a blogs en español.

El caso de Typominima es muy distinto. El tema no está preparado para ser traducido (salvo que la traducción se haga editando las cadenas del código original), así que me he dedicado laboriosamente a llamar a todas las cadenas de texto mediante las funciones de traducción de WordPress, hasta conseguir los resultados apetecidos. Aunque voy cogiéndole el tranquillo a funciones como _e(), __(), _c(), _x() y _n() y algunas otras, tengo que reconocer que sólo a través del añejo sistema de la prueba y el error (y a costa de bastantes horas de trabajo), consigo progresar, porque como ya he dicho en más de una ocasión, mis habilidades de programador en PHP tienden a cero.

Los experimentos con ambas plantillas los he realizado sobre uno de mis blogs de prueba, el mismo en el que instalé el plugin Import HTML Pages y llevé a cabo las operaciones necesarias para escribir el artículo Para convertir un sitio web estático en un blog. Con ello he conseguido matar dos pájaros de un tiro: por una parte, verificar el funcionamiento de los temas The Erudite y Typominima, y por otra insuflar nueva vida a las antiguas reseñas de Lengua en Secundaria. Cuando haya repasado y reformateado a mi gusto estos treinta y tantos artículos (va para largo, porque es un proceso bastante pesado, sobre todo por el asunto de las notas a pie de página), lo más probable es que las importe desde La Bitácora del Tigre.

Adenda del 24 de diciembre de 2017

Ya hace tiempo que he eliminado del servidor los ficheros de traducción de estos temas, razón por la cual he borrado también los enlaces de descarga, dado que no funcionaban y solo servían para crear confusión.

Esta entrada Dos temas tipográficos para WordPress y sus traducciones al español ha sido publicada en primer lugar en La Bitácora del Tigre.

Los artículos correspondiente a ambos tipos de contenido se editan de la misma manera que cualquier entrada o página de WordPress, aunque debe tenerse en cuenta que los creadores del tema han simplificado el interfaz de edición de ambos tipos de contenido, pues no cabe la posibilidad de adscribirlos a categorías o adjuntarles etiquetas (aprovecho para señalar que ya existen temas que asocian los tipos de contenido con categorías propias, como es el caso de Portfolium). A cambio, News ofrece un bloque adicional de campos personalizados, destinado a diversos metadatos: título, descripción, palabras clave e imagen en miniatura (figura 3). Estos cuatro campos también forman parte del interfaz de edición de entradas y páginas, lo cual convierte al tema News en una herramienta muy efectiva a la hora de producir páginas fácilmente indexables por los motores de búsqueda.

Para insertar un vídeo en un artículo correspondiente a dicho tipo de contenido, basta con copiar y pegar la URL (véase la figura 4). Siempre que el servicio de alojamiento soporte la tecnología oEmbed, WordPress será capaz de interpretar el elemento multimedia y rodearlo del código HTML necesario. Por su parte, las presentaciones se elaboran mediante el procedimiento al que ya me referí en la segunda entrada de esta serie y que está descrito en el tutorial elaborado al efecto por DevPress. Seguramente también será posible insertar presentaciones de SlideShare y otros servicios semejantes mediante oEmbed, pero aunque he leído algún truco sobre el particular, no he profundizado lo suficiente para hacer afirmaciones tajantes al respecto.

El tema News proporciona los archivos de plantilla necesarios (se trata de slideshow.php y video.php) para representar adecuadamente los dos tipos de contenido. El resultado de su aplicación a los respectivos tipos de artículos (no hace falta modificar ningún parámetro, porque el tema lo hace de forma automática) es, como ya mostré con las capturas de pantalla incluidas en la primera entradas de esta serie, sencillamente espectacular. No obstante, no es posible utilizar páginas de archivo o índices que permitan obtener listados de todos los artículos pertenecientes al tipo “presentaciones”, o al tipo “vídeos”. Es decir, URLs como http://www.misitio.com/videos o http://www.misitio.com/presentaciones producen un molesto error de página no encontrada.

Cuando descubrí esta circunstancia pensé que era un defecto de diseño del tema, y puse el caso en conocimiento de sus creadores (véase mi intervención en los foros de DevPress, titulada Custom post type URLs), pero lo cierto es que yo estaba pidiendo peras al olmo, puesto que las páginas de archivo correspondientes a los tipos de contenido personalizado constituyen una funcionalidad todavía no incorporada al núcleo de WordPress. Tal como apunta Justin Tadlock en su respuesta a mi intervención, está previsto que la versión 3.1 incorpore esta característica fundamental. A la espera de dicha actualización, ahora mismo es posible obtener las páginas de archivo correspondientes a los tipos de contenido personalizados mediante la instalación de alguno de los plugins que proporcionan las funciones necesarias, como por ejemplo, Custom Post Type Archives o Simple Custom Post Type Archives. Yo he utilizado en mi blog de pruebas la primera de estas extensiones (por cierto, con una documentación extraordinaria, muy superior a lo habitual), configurada tal como se ve en la figura 5, con resultados no del todo óptimos, pero en cualquier caso más que satisfactorios (figuras 6 y 7).

Otra de las características más interesantes del tema News es el soporte para los temas-hijo de WordPress. Para hacer más fácil la personalización, los autores han incluido un tutorial muy fácil de seguir, e incluso proporcionan un modelo de tema-hijo que se puede aprovechar para realizar toda clase de pruebas y experimentos. El mío no es demasiado original, pues me he limitado a sustituir el logotipo original por una cabeza de tigre al estilo iPhone (véase la figura 8).

Este nuevo logotipo ha sido elaborado con la aplicación online iPhone Style Icon Generator, a partir de una de mis imágenes de Flickr, que a su vez es el origen del avatar que utilizo en este blog, en mi cuenta de Twitter y en algunos otros sitios. En cuanto a los estilos que controlan la apariencia del título del blog, basta con añadir al fichero style.css del tema-hijo el siguiente código:

#site-title {
	background: url("images/tigre.png") no-repeat scroll 0 5px transparent;
	padding: 0 20px;
}

Respecto a mi traducción del tema News al español, conviene tener en cuenta algunas observaciones, a saber:

• He traducido el widget denominado “Utility: Header”, correspondiente a la línea 155 del fichero functions.php, como “Cabecera”, a secas, pues estoy seguro de que traducir el primer término del nombre original no sirve más que para generar confusión.
• El nombre “Subsidiary Menu”, definido en la línea 167 del fichero functions.php, lo he traducido por “Menú de pie de página”; tal denominación se ajusta perfectamente a la naturaleza y ubicación de dicho menú, y hace innecesaria la traducción del adjetivo.
• Hay una opción en el widget de etiquetas, titulada “Pad counts?” (línea 272 del fichero /library/classes/widget-tags.php), que me ha costado mucho traducir. Tras varias consultas al Codex de WordPress, he encontrado finalmente una pista en el blog de Javier Aroche, tras lo cual he decidido optar por una traducción muy poco literal, de tipo explicativo: “¿Incluir en el número de entradas las que corresponden a términos-hijo?”.
• El botón de “Suscribirse”, que forma parte del widget de boletín de noticias, no es un texto, sino una imagen (/images/bg-sidebar-newsletter.png). Así pues, si se quiere traducir este elemento, hay que editar el fichero PNG.

Esta entrada Más sobre temas especiales para WordPress: el tema News, 3 ha sido publicada en primer lugar en La Bitácora del Tigre.

Los tres menús admiten modificaciones mediante estilos CSS (por ejemplo, el icono que aparece a la derecha del enlace de RSS se logra mediante la clase “feed”), y su configuración está perfectamente explicada en el tutorial que a tal efecto ha preparado DevPress. Si se observa la figura 3, podrá entenderse la potencia del sistema de menús de WordPress, que permite combinar todo tipo de enlaces, y disponerlos en el orden deseado, mediante un interfaz de “arrastrar y soltar”, muy cómodo e intuitivo.

El tema News también está muy bien dotado en lo que concierne a los widgets, pues no sólo añade opciones de configuración exhaustivas a los que ya trae de serie WordPress (véase, por ejemplo, la figura 4, en la que aparece una captura que demuestra las abrumadoras posibilidades de la configuración del widget de categorías), sino que presenta widgets exclusivos, muy apropiados para la configuración de un sitio web al estilo revista o magazine: suscripción a boletines de noticias mediante FeedBurner, lista de entradas más populares, con opciones para los artículos más visitados y más comentados, y serie fotográfica de las imágenes incluidas en los artículos del sitio (figura 5).

Los widgets de News se pueden situar en cinco áreas distintas: dos en la barra lateral izquierda y las otras tres (figura 6) en diversos lugares del blog: una en la cabecera, muy apropiada para el formulario de búsqueda; otra para las páginas de error 404 (véase, en la figura 7, la página de error personalizada que he elaborado en un santiamén, gracias a los infinitos recursos gráficos de Flickr); y un área adicional para los artículos individuales del blog, que se intercala entre el contenido y el formulario de comentarios y en la cual se puede ubicar contenido, scripts o funciones especiales

Otra funcionalidad interesantísima del tema News es la que permite crear presentaciones animadas o carruseles de fotografías a partir de las galerías de imágenes de WordPress. El uso de esta característica es sencillísimo (y además está muy bien explicado en el correspondiente tutorial), pues basta con subir a un artículo una serie de imágenes, agruparlas en una galería e insertarlas donde sea conveniente mediante el correspondiente shortcode. Si dicho artículo se configura como una entrada fija o sticky post, el tema se encargará de traerlo a la página de inicio del blog, mediante una presentación de gran impacto visual (véase la figura 8). El carrusel también se puede lograr a partir de varias entradas individuales, siempre que se cumplan dos requisitos: adjuntar a cada una de ellas una imagen y configurarlas como entradas fijas. Con todas ellas el tema genera una presentación animada y la sitúa al comienzo de la página principal (figura 9).

En la próxima entrega de esta serie veremos cómo trata el tema News los tipos de contenido personalizado (presentaciones y vídeos), explicaremos cómo utilizar los campos personalizados para introducir metadatos en los artículos y analizaremos algunos aspectos mejorables del tema. Si mis previsiones se cumplen, la ya varias veces prometida traducción española será el colofón a esta serie dedicada al espléndido tema que tan generosamente nos ha entregado DevPress.

Esta entrada Más sobre temas especiales para WordPress: el tema News, 2 ha sido publicada en primer lugar en La Bitácora del Tigre.

Como ya señalé en su momento, la lista de características del tema News es abrumadora. Entre las más importantes, cabe destacar las siguientes:

• Tres conjuntos de menús personalizables, dos de ellos en la cabecera, ambos desplegables mediante efectos Superfish, y el tercero en el pie de página.
• Posibilidad de insertar un carrusel o presentación animada a partir de las galerías de imágenes de las entradas.
• Dos tipos de contenido personalizado (vídeos y presentaciones), con plantillas ya preparadas para una exhibición espectacular.
• Cinco áreas de widgets, la mayoría de los cuales disponen de una enorme cantidad de opciones (uno de los aspectos donde más se advierte la mano mágica de Justin Tadlock y la influencia de su tema Hybrid).
• Una plantilla tipo revista o magazine para la página principal que permite mostrar las entradas destacadas y las más populares.
• Funciones integradas de recomendación de las entradas mediante servicios de marcadores y redes sociales.
• Posibilidad de elaborar temas-hijo para modificar el comportamiento del tema sin afectar a su diseño y estructura originales.
• Entradas fijas (sticky posts) especialmente diseñadas.
• Campos personalizados para la introducción de metadatos en entradas y páginas.

Desde luego, lo que más salta a la vista de News es su espléndida factura visual, que supongo podrá apreciarse en las capturas de pantalla de un blog de prueba que he adaptado a los particulares usos y maneras del tema: la página principal en disposición CMS (figura 1), las páginas correspondientes a los tipo de contenido personalizado “vídeo” (figura 2) y “presentación” (figura 3), las páginas de archivo que incluyen entradas con miniaturas de imágenes destacadas (figura 4), etc.

Como en el caso del tema Portfolio Press, para sacar todo el partido de un tema como News hay que modificar la configuración por defecto del blog, de forma que la página de inicio del sitio utilice la plantilla de estilo revista o magazine. Para lograr tal propósito, hay que dar los siguientes pasos:

1. Después de descargar, instalar y activar el tema, hay que regenerar la estructura de enlaces permanentes del blog, para que puedan estar disponibles las nuevas URLs asociadas al contenido personalizado. Esta acción se realiza desde Ajustes >Enlaces permanentes > Guardar cambios.

2. A continuación, se debe crear una página estática en blanco, con el nombre de Inicio; en realidad, podría ser cualquier otro, pero esta denominación es una de las más habituales. Esta tarea se lleva a cabo desde el menú Páginas > Añadir nueva. Desde el interfaz de edición, hay que asignar a la página que se acaba de crear la plantilla denominada Home, que es la que permite obtener la estructura típica de un portal o sitio de noticias (figura 5).

3. Acto seguido, hay que asignar al tema aquella categoría o categorías que se desean destacar en la página principal, para lo cual se debe acudir al menú Apariencia > Configuración del tema – News (en mi traducción; el menú original en inglés dice News Settings), y escoger en el último de los campos de configuración las categorías necesarias (figura 6).

4. Tras crear la página de inicio, es preciso crear otra página estática en blanco, a la que se vinculará el contenido normal del blog (es decir, el que se organiza de forma cronológicamente inversa). Un nombre que suele recomendarse para tal propósito es Blog, pero también podría elegirse otro que sugiera un patrón cronológico de organización, como Noticias, Novedades, etc.

5. Por último, debe configurarse el blog para que la página principal sea la página de Inicio y el contenido normal sea accesible desde la página Blog. Esta acción se lleva a cabo desde el menú Ajustes > Lectura, seleccionando la opción de que la página del blog sea la página fija que hemos llamado Inicio y la página de entradas la denominada Blog, tal como puede verse en la figura 7.

En próximas entregas de esta serie dedicada al tema News explicaré algunas de sus características más interesantes, como la configuración de los widgets, la elaboración de entradas con carruseles de imágenes, el uso de los campos personalizados para introducir metadatos en entradas y páginas, etc., los intríngulis de la elaboración de artículos correspondientes a los tipos de contenido personalizado, etc. Y, por supuesto, haré pública mi traducción del tema, para quien le pueda interesar.

Esta entrada Más sobre temas especiales para WordPress: el tema News, 1 ha sido publicada en primer lugar en La Bitácora del Tigre.

• Para microbloguear o utilizar el blog a modo de una herramienta colaborativa de comunicación sincrónica al estilo Twitter, con temas como P2, GTD o LiveTwit.
• Para montar sitios de noticias, tipo revista o magazine, como los que se pueden crear con Arras Theme.
• Para elaborar fotoblogs (Zack 990) y videoblogs (WooTube).
• Para publicar portales, mediante temas que permiten desarrollar sitios complejos con funcionalidades semejantes a las de un CMS; por ejemplo, Carrington blog.
• Para crear comunidades de usuarios y redes sociales, gracias al plugin BuddyPress y alguno de los temas adaptados para dicha extensión.
• Para elaborar un sitio web que resuma la actividad de un usuario en las redes sociales, con temas como Visiting Card.
• Para publicar wikis, mediante plantillas especialmente diseñadas para tal propósito, como WordPress Wiki Theme.
• Para crear un sistema de gestión de agenda, gracias a RoloPress o Driftwood.
• Para construir un agregador de fuentes RSS, con temas como Aggregator o OneNews.
• Para desarrollar sitios de comercio electrónico, con alguno de los muchos temas existentes para tal propósito. Por ejemplo, Ecommerce Theme.
• Para elaborar portfolios, con plantillas como Portfolio Press, que voy a comentar a continuación.

Portfolio Press no es, ni mucho menos, el único tema de WordPress que se puede utilizar para crear portfolios (véase, por ejemplo, la enorme recopilación de plantillas publicada en 100 stunning professional portfolio WordPress themes), pero tiene algunas ventajas: es gratuito y está alojado en el repositorio oficial de temas de dicha aplicación, lo que supone una garantía adicional de calidad, actualización y compatibilidad. De hecho, me he interesado por este tema con el propósito de investigar su funcionamiento en una plataforma como Multiblog, y comprobar si cabía ofrecer a los docentes que tienen blogs alojados en dicho servicio del PNTE la posibilidad de elaborar sus propios portfolios.

Me alegra poder decir que, efectivamente, Portfolio Press no presenta ningún problema en una instalación multisitio de WordPress. Hay que tener en cuenta, en cualquier caso, que para que el tema funcione correctamente, es necesario disponer de una versión actualizada de la aplicación (al menos, la 3.0), pues la plantilla hace uso de dos funcionalidades clave –las taxonomías y los tipos de contenido personalizados-, que sólo se pueden gestionar desde el backend de WordPress a partir de dicha versión.

Tras instalar y activar el tema (para lo cual he utilizado uno de los blogs de prueba de la plataforma) Portfolio Press crea en el menú de la aplicación un tipo de contenido nuevo, denominado Portfolio, con sus correspondientes elementos de interfaz (véanse las figuras 1 y 2). Por supuesto, queda a criterio del usuario utilizar este tipo de contenido de forma exclusiva o combinado con el contenido habitual del blog, pero yo aconsejo optar por la segunda alternativa, pues proporciona al sitio una mayor flexibilidad.

Para poder utilizar el tema es necesario realizar algunos cambios de configuración en el blog que no son demasiado complejos, pero que exigen cierta atención. En el sitio web de su autor hay un buen videotutorial, que me permito incrustar a continuación. No obstante, como está en inglés y algunos de los pasos son poco intuitivos, incluyo tras el vídeo las instrucciones en castellano.

1. Después de activar el tema, hay que regenerar la estructura de enlaces permanentes del blog, para que puedan estar disponibles las nuevas URLs asociadas al contenido personalizado. Esta acción se realiza desde Ajustes > Enlaces permanentes > Guardar cambios.

2. A continuación, se debe crear una página estática en blanco, con el nombre de Portfolio (en realidad, podría ser cualquier otro, pero esta denominación está ya consagrada por el uso y por tanto resulta fácil de interpretar). Esta tarea se lleva a cabo desde el menú Páginas > Añadir nueva. He escogido para la página resultante una plantilla de anchura completa, sin barras laterales (véase la figura 3), pues con ello la página principal del sitio adquiere un aspecto más rotundo y elegante.

3. Tras crear la página del portfolio, es preciso crear otra página estática en blanco, a la que se vinculará el contenido normal del blog (es decir, el que se organiza de forma cronológicamente inversa). Un nombre que suele recomendarse para tal propósito es Blog, pero también podría elegirse otro que sugiera un patrón cronológico de organización, como Noticias, Novedades, etc.

4. Por último, debe configurarse el blog para que la página principal sea la página de Portfolio y el contenido normal sea accesible desde la página Blog. Esta acción se realiza desde el menú Ajustes > Lectura, mediante la selección de las opciones que aparecen destacadas en la figura 4.

A partir de este momento, ya se puede crear el contenido especializado desde el menú Portfolio > Añadir nuevo elemento. Como puede verse en la captura de pantalla representada en la figura 5, el diseñador del tema ha simplificado el editor de WordPress, pues en los artículos del portfolio no se pueden crear resúmenes o campos personalizados, ni tampoco cabe asociarlos a las categorías o las etiquetas habituales en el editor de entradas de WordPress. A cambio, el tipo de contenido personalizado “portfolio” queda asociado a una taxonomía específica, denominada Etiquetas del portfolio, que permite añadir descriptores semánticos específicos para este tipo de artículos.

Con el objetivo de llevar a cabo las pruebas necesarias que me permitieran redactar este artículo, he creado seis artículos (véase la figura 1), y desde el menú Imagen destacada del editor de contenido he asociado a cada uno de ellos una imagen que actúa como miniatura de la entrada en la página principal del blog. El resultado es un sitio web cuya página principal tiene el aspecto que aparece en la figura 6, es decir, un sitio que muestra el contenido del portfolio de forma gráfica, mediante miniaturas de imágenes asociadas a los ítems de contenido. Pinchando sobre cualquiera de ellos se abre el artículo correspondiente (figura 7). Por su parte, el menú de páginas estáticas que aparece en la parte superior derecha de la cabecera (dicho menú se genera automáticamente) permite acceder al resto del contenido del sitio, para lo cual basta con pulsar en el enlace correspondiente, mediante el cual se accede a las entradas del blog, organizadas según su disposición habitual (figura 8).

Como se habrá observado, el frontend del blog está en castellano, pues el diseñador del tema lo ha elaborado de forma que sea posible su traducción mediante los mecanismos que a tal efecto proporciona WordPress. Ahora bien, en su versión actual, el tema no permite una traducción completa, salvo que se realicen varios cambios, a saber:

• Modificar el fichero archive.php, para que el título de las páginas de archivo correspondientes a los meses de un año pueda ser traducido al formato de fecha adecuado.
• Modificar el fichero footer.php, para que la cadena “Powered by” pueda ser traducida.
• Modificar el fichero functions.php para que las cadenas de texto que identifican y describen las zonas de widgets sean traducibles.
• Añadir la identificación del text domain (“portfoliopress”) a aquellos ficheros en los que las cadenas de texto traducibles carecen de él. Se trata de los ficheros full-width-portfolio.php, taxonomy-portfolio-tags.php, type-portfolio.php y /extensions/portfolio-post-type.php. La falta del text domain provoca que, aunque se realice una traducción impecable del tema, queden varias cadenas de texto sin traducir en el backend del blog.

He comunicado todos estos cambios al autor del tema, y espero que los pueda aprovechar para una próxima versión.

Antes de terminar, quiero hacer una precisión sobre la traducción del término “portfolio” para designar el tipo de contenido personalizado alrededor del cual se organiza este tema de WordPress. En primera instancia, lo había traducido como “portafolio”, pero para evitar la incómoda polisemia del término, he preferido no traducirlo (o, mejor dicho, utilizar para la traducción el anglicismo), cuyo significado en la Web, y especialmente en el ámbito educativo (véase el artículo Electronic portfolio), parece ya consagrado por el uso. En todo caso, estoy dispuesto a modificar la traducción si alguien me ofrece mejores argumentos que los que acabo de presentar.

Esta entrada Sobre los temas de WordPress para usos especiales y la traducción del tema Portfolio Press ha sido publicada en primer lugar en La Bitácora del Tigre.

Sobre este último asunto existen varios tutoriales un tanto imprecisos, y por ello recomiendo el titulado Upgrading WordPress MU 2.9.2 to WordPress 3.0, pues tanto en el texto del artículo como en las preguntas y respuestas de los comentaristas se halla la solución a la mayoría de conflictos que pueden aparecer en el proceso de actualización.

Por supuesto, al actualizar una plataforma de blogs a WordPress 3.0 es necesario actualizar también muchos plugins, para evitar incompatibilidades que puedan afectan a la funcionalidad de la aplicación. Esto no debiera constituir un problema con las extensiones “normales” (las instaladas en el directorio /wp-content/plugins), porque el sistema va avisando al administrador de las actualizaciones en el momento en que éstas se producen, y lo lógico es llegar al cambio de versión de la aplicación con la mayoría de las extensiones actualizadas. Sin embargo, tal circunstancia no se produce con las extensiones instaladas en el directorio /wp-content/mu-plugins, a no ser que sean compatibles con el plugin Update Notification, que está incluido en todas las extensiones del servicio de pago WPMU DEV Premium.

Así que el sufrido administrador de la plataforma tiene que hacer un esfuerzo especial por actualizar todas las extensiones de /mu-plugins, la mayoría de las cuales no están en el repositorio oficial de WordPress, bien porque son de pago (caso de las que publica WPMU DEV), bien porque están muy pobremente documentadas, o bien porque ya están “descatalogadas” y no hay manera de actualizarlas, a no ser sustituyéndolas por otras extensiones que hagan funciones parecidas. Todos estos problemas los he padecido en primera persona, y he sabido solventarlos de forma más o menos eficaz, y en algunos casos hasta elegante.

Más dificultosa será la actualización de los casi sesenta temas que en este momento tienen a su disposición los usuarios de la plataforma Multiblog. En rigor, esta es una tarea imposible, porque un buen puñado de los temas instalados ya no tienen continuidad. Sin embargo, los creadores de otros muchos los han ido actualizando para incorporar las nuevas funcionalidades de WordPress 3.0 (menús nativos, nueva estructura de plantillas, cabeceras y fondos personalizados, posibilidad de integrar los contenidos procedentes de taxonomías y tipos de contenido personalizados, etc.), y con tal motivo se impone una revisión a fondo de todos los temas instalados en la plataforma. En rigor, esta no es una tarea urgente, pues aunque los temas no sean del todo compatibles con las novedades de la última versión de WordPress no por ello pierden su funcionalidad.

Lo que en ningún caso debe hacerse sin las debidas precauciones, a pesar de las indicaciones de algunos tutoriales, es borrar los viejos temas que venían por defecto en versiones anteriores de WordPress (es decir, Default y Classic), porque en la plataforma Multiblog (y supongo que lo mismo ocurrirá en otras instalaciones) hay muchos blogs que tienen como tema activo el que hasta ahora utilizaba WordPress por defecto. Teóricamente, una vez actualizada la aplicación a la versión 3.0, dichos blogs deberían haber adoptado por defecto el tema TwentyTen, pero eso no ha ocurrido en nuestro caso, razón por la cual, tras borrar los temas antedicho, cuarenta y tantos blogs se han quedado en blanco (ojalá hubiera leído antes el artículo Change the default theme for sites without a plugin, pero cuando tuve noticia de él ya era tarde).

Cierto es que el problema tenía una importancia menor, pues la mayor parte de los blogs afectados sólo tenían una entrada, y que la solución era tan fácil como la de copiar de nuevo en el servidor los dos temas borrados, pero he preferido optar por una alternativa más sólida y con mayor proyección de futuro, de la que alguna vez ya he tratado en La Bitácora del Tigre: editar minuciosamente en cada blog las opciones template, stylesheet y current_theme (lo cual puede hacerse desde el backend de administración de la plataforma o mediante la oportuna consulta ejecutada directamente sobre MySQL), y sustituirlas por el valor apropiado para cada una de ellas: “twentyten” para las dos primeras y “Twenty Ten” para la tercera. Un incordio bastante fastidioso, la verdad.

Otro problema mucho más difícil de resolver es el que me encontré ayer por la mañana, cuando me di cuenta, al actualizar el tema Tarski, que el usuario administrador de un blog que utilizo para pruebas (no confundir con el super administrador de la plataforma de blogs, propio de las instalaciones multisitio, que no se ve afectado) no podía acceder a la página de opciones de dicho tema. Al principio, pensé que era un problema de la nueva versión de Tarski, pero en seguida me di cuenta de que afectaba a varios temas con páginas de opciones, independientemente de su versión, y a todos los blogs que hacían uso de este tipo de plantillas.

Como el problema era bastante serio, me enfrasqué en encontrar una solución, y después de un par de horas de búsquedas poco fructíferas y de algunas hipótesis infundadas sobre colisiones con plugins y otros conflictos semejantes –véase, como ilustración de mis indagaciones, el hilo que abrí en los foros de soporte de WPMU DEV– di con la solución en varias intervenciones de los foros de WordPress, que cito a continuación en orden vagamente cronológico:

• Capability manage_options vs edit_themes.
• Multi-user set up – users can’t customize themes.
• WP 3.0 MS – User’s can’t See Theme Options Pages.
• WP 3.0 multisite + Constructor.
• Atahualpa WPMU Problems.
• My users can’t see settings of some theme.
• Theme option menu access.

Por lo que yo he podido entender de todo este maremágnum de preguntas y respuestas (véase también el artículo Did your user’s theme options and widgets page disappear?), en las instalaciones multisitio de WordPress 3.0, la capacidad ‘edit_themes’, que en versiones anteriores de la aplicación estaba a disposición de los administradores de blogs individuales, se ha circunscrito o limitado al usuario super administrador del multisitio. Esto provoca que los administradores de blogs individuales no pueden acceder a la página de opciones de aquellos temas cuya configuración se activa invocando dicha capacidad, con los perjuicios consiguientes.

La solución consiste en localizar en cada tema el código que activa la página de opciones, y modificarlo, eliminando la capacidad ‘edit_themes’  y sustituyéndola por otra de la que dispongan los administradores de blogs individuales. En las intervenciones que acabo de citar se proponen varias diferentes: ‘switch_themes’, ‘manage_options’ y ‘edit_theme_options’. Después de un análisis detallado de los casos que se relatan en los foros y de la lectura de los artículos Roles and Capabilities y Adding Administration Menus del Codex de WordPress, creo que la opción más adecuada es la última, aunque, como se verá más adelante, yo he optado por la segunda en los temas que he ido modificando durante estos dos últimos días, porque hasta la tarde de hoy no he dispuesto de toda la información que ahora ofrezco a mis lectores.

Hasta aquí la teoría, aunque en la práctica la situación es todavía más complicada, pues si bien la gran mayoría de temas actuales que disponen de páginas de opciones contienen un código con una estructura semejante a ésta:

<?php add_theme_page( $page_title, $menu_title, $capability, $menu_slug, $function); ?>

sin embargo, no todos activan la página de opciones desde el mismo archivo y de la misma forma. Esta circunstancia hace que la actualización de los temas en una plataforma como Multiblog (muchos de ellos bastante modificados, además), se convierte en una tarea muy fatigosa. A guisa de ilustración de la variedad con la que me ido encontrando, ofrezco a continuación cuatro casos, todos ellos diferentes, correspondientes a otros tantos temas de nuestra plataforma de blogs.

Solución a los problemas con los temas al actualizar un multisitio

1. Tema Arjuna X, versión 1.3.9. En el archivo functions.php, línea 352, donde originalmente dice:

add_theme_page(__('Arjuna Options', 'Arjuna'), __('Arjuna Options', 'Arjuna'), 'edit_themes', basename(__FILE__), 'arjuna_add_theme_page');

debe decir:

add_theme_page(__('Arjuna Options', 'Arjuna'), __('Arjuna Options', 'Arjuna'), 'manage_options', basename(__FILE__), 'arjuna_add_theme_page');

A tenor de mis comprobaciones, el recurso al archivo functions.php es la situación más habitual entre los temas que activan su página de opciones mediante la llamada a “add_theme_page”.

2. Tema Mystique, versión 2.4.2. En el archivo /admin/theme-settings.php, líneas 865-872, donde dice:

function mystique_add_menu() {
     $page = add_theme_page(
          __('Mystique settings', 'mystique'),
          __('Mystique settings', 'mystique'),
         'edit_themes',
         'theme-settings',
         'mystique_theme_settings'
    );

hay que cambiar edit_themes por manage_options.

3. Tema Tarski, versión 2.7.1. En el archivo /library/helpers/admin_helper.php, líneas 226-233, donde dice:

function tarski_addmenu() {
     $page = add_theme_page(
          __('Tarski Options','tarski'),
          __('Tarski Options','tarski'),
         'edit_themes',
         'tarski-options',
         'tarski_admin'
     );

hay que cambiar edit_themes por manage_options.

En este tema, la capacidad ‘edit_themes’ aparece otras cuatro veces en el mismo fichero (en concreto, en las líneas 53, 78, 104, 230 y 248). Hay que asegurarse de cambiarla en todas ellas por ‘manage_options’, para evitar que pueda haber problemas con el funcionamiento del tema en entornos multisitio. Por si acaso la solución no es correcta, y de paso para informar al autor del tema Tarski sobre esta circunstancia, he abierto un hilo en los foros que con tanta eficiencia administra su creador, Ben Eastaugh.

4. Tema Mandigo, versión 1.42. En este caso, son tres los archivos que deben modificarse: /backend/theme_options.php (línea 13), /backend/html_inserts.php (línea 9), en los que hay que cambiar ‘edit_themes’, por ‘manage_options’; y /backend/readme.php (línea 9), donde hay que cambiar la capacidad ‘switch_themes’, por ‘manage_options’.

Un truco antes de acabar: para encontrar la llamada a esta capacidad en cada uno de los temas mencionados, he utilizado una de mis herramientas favoritas de edición web, de la que ya traté en un artículo anterior de este blog. Me refiero a Windows Grep, una utilidad que en tareas complejas de búsqueda de código ofrece unas posibilidades inmensas.

Y esto es todo, al menos por el momento. Estoy casi seguro de que esta apasionante historia no terminará aquí, al menos para un servidor, a quien le toca la ardua tarea de actualizar en próximos días unos treinta o cuarenta temas.

Esta entrada Actualización de una instalación multisitio a WordPress 3.0: ¡cuidado con los temas! ha sido publicada en primer lugar en La Bitácora del Tigre.

Todavía menos satisfactorio es el panorama si prestamos atención a lo que podríamos llamar los márgenes de las aplicaciones, es decir, el conjunto de temas o plantillas, de plugins y extensiones que crece frondoso en torno a los programas de más éxito (en el caso de WordPress, unos y otros se cuentan por miles). A pesar de que las aplicaciones suelen tener normas muy claras para la “internacionalización” y “localización” de plantillas y extensiones (más adelante explicaré estos conceptos), y a pesar también de que se valen de sistemas perfectamente capaces y probados (véase, para el caso de WordPress, los artículos Installing WordPress in Your Language, I18n for WordPress Developers, y Translating WordPress), esas normas se incumplen sistemáticamente, con el resultado esperable de un gran porcentaje de sitios web (en el caso que nos ocupa, blogs) practicantes muy a su pesar de una especie de mezcolanza idiomática que supone para lectores y visitantes no sólo una funcionalidad disminuida, sino sobre todo una falta de respeto.

Los dos últimos episodios relacionados con la traducción de WordPress y demás miembros de su familia en los que me he visto envuelto han sido, en primer lugar, la traducción de la versión 2.5 del tema Tarski, que hace pocos días anuncié en el foro de esta plantilla (por cierto, Tarski es uno de los temas mejor programados desde el punto de vista de la traducción, lo cual permite que sus versiones a otras lenguas sean casi impecables); y en segundo lugar, el hilo de los foros de WPMU Dev Premium que abrí hace algo más de una semana, acerca de determinados problemas planteados por la traducción del tema Corporate para BuddyPress. De este segundo caso, que todavía no he podido resolver a plena satisfacción, al menos he obtenido una enseñanza muy provechosa que aprendí de Ovidiu, uno de los usuarios que acudieron en mi ayuda: la existencia del plugin Codestyling Localization, una extensión de enorme utilidad para quienes se enfrentan cotidianamente a la tarea de traducir WordPress o WPMU, sus extensiones y sus plantillas, y por supuesto para quienes deseen mejorar, o adecuar a sus propios propósitos, las traducciones de terceros.

El plugin Codestyling Localization activa en el blog donde se instala una herramienta de traducción cuyo funcionamiento resultará bastante fácil de entender para quienes ya se han bregado en estas lides, pues es muy parecido a PoEdit, probablemente la utilidad más conocida en este ámbito. Tras ser activado, el plugin crea una entrada en el menú Herramientas, titulada Localización, desde la que se accede a todos los elementos traducibles del blog, es decir, no sólo la propia aplicación, sino también las plantillas y los plugins que han sido codificados para que permitan la traducción mediante las funciones de Gettext, es decir, mediante ficheros .PO/.MO. Codestyling Localization ofrece algunas funcionalidades muy interesantes:

• Creación automática de ficheros .PO (un fichero .PO es un catálogo que contiene, en formato de texto plano, las cadenas de texto originales y sus equivalencias en otra lengua), a partir de los ficheros PHP de la aplicación, el tema o el plugin; por supuesto, esto sólo es posible si aquéllos han sido correctamente programados. El propio plugin genera todos los datos de la cabecera del fichero .PO, identifica los juegos de caracteres (por defecto, UFT-8) y las palabras clave y proporciona la información necesaria para controlar adecuadamente las formas plurales en la lengua de la traducción. Se pueden crear todos los ficheros de lenguas que el usuario necesite, y el plugin genera sus nombres de acuerdo con las convenciones necesarias para que la traducción funcione correctamente en la lengua que se haya determinado.
• Edición de ficheros .PO ya existentes. A veces, dependiendo de la configuración del servidor y de los permisos de los ficheros, hay que modificar éstos para que los ficheros sean editables; aunque esta acción se puede realizar desde el propio interfaz del plugin, hay ocasiones en que se requiere llevarla a cabo mediante una conexión FTP. También puede ser necesario reescanear los ficheros de la aplicación para permitir que el plugin pueda realizar su labor.
• Creación de ficheros .MO (los ficheros, ya compilados en código máquina, que son leídos por el servidor), para lo cual sólo es necesario pulsar sobre el botón correspondiente, una vez completada la traducción del fichero .PO.
• Revisión de los ficheros .PO. Cuando se actualiza una aplicación, una plantilla o un plugin, normalmente suele ser necesario reeditar el fichero .PO, a fin de incluir las nuevas cadenas de texto y descartar las obsoletas. El plugin Codestyling Localization simplifica mucho esta tarea, pues en cualquier momento se pueden reescanear los archivos PHP fuente, y reelaborar el fichero .PO correspondiente.

El interfaz de edición de los ficheros de traducción no planteará ningún problema a quienes ya están acostumbrados a trabajar con utilidades como PoEdit. Se pueden aplicar búsquedas, con operadores muy potentes, tanto a las cadenas originales como a las traducciones, y además existe la posibilidad de traducir las cadenas de texto mediante el API de Google, cuyos resultados no son infalibles ni mucho menos, pero vienen muy bien cuando cuesta encontrar la equivalencia lingüística o se tienen dudas sobre un término. Por último, la traducción se ve facilitada por la función contextual, que permite relacionar cada cadena de texto con su archivo fuente, y por tanto identificar los contextos de uso de las cadenas de texto traducibles en el código PHP original.

Quienes hayan utilizado PoEdit y se manejen bien con este programa o con alguno de sus equivalentes se preguntarán cuáles son las ventajas de traducir online, mediante el plugin Codestyling Localization. A mi modo de ver, esta extensión tiene algunas ventajas indiscutibles sobre la traducción en local:

• Permite generar ficheros .PO con todos los elementos necesarios para crear traducciones impecables. Detalles como el nombre del fichero .PO, los juegos de caracteres o las claves para las formas plurales constituyen un quebradero de cabeza para la mayoría de los usuarios, que ya no tendrán que preocuparse de estas decisiones, pues el plugin las toma de forma automática, basándose en la configuración lingüística del blog y en las características sintácticas de la lengua elegida para la traducción.
• Es un sistema mucho más eficiente, pues permite comprobar los cambios que se llevan a cabo en la traducción de manera casi inmediata, así como actualizar las traducciones cuando se producen cambios de versiones. No hace falta tener a mano en el ordenador donde se está trabajando los ficheros fuente de la aplicación, de la plantilla o de los plugins, porque la edición y publicación de los ficheros de idioma se realiza en línea, esto es, directamente en el servidor. En la práctica, esta circunstancia implica que en el mismo momento que el administrador de un blog localiza un error de traducción, o una cadena no traducida, lo puede corregir y mejorar con muy poco esfuerzo. En blogs multilingües, o en plataformas de blogs que utilizan diversas lenguas (recordemos que el plugin funciona perfectamente en WordPress MU), esta característica ofrece un claro valor añadido, aunque a cambio obliga, o bien a disponer de un usuario administrador que domine varias lenguas, o bien a permitir que los distintos usuarios traductores tengan acceso a las funciones del plugin, lo cual puede suponer ciertos problemas a la hora de administrar la aplicación y garantizar su seguridad.
• Puede identificar y separar las cadenas de texto correspondientes al text domain propio de la aplicación, la plantilla o el plugin (un text domain es algo así como el identificador unívoco de una plantilla o extensión), de aquellas que no han sido identificadas con dicho text domain (a veces los programadores son descuidados, o se olvidan de lo obvio, o recurren, como todo el mundo, al “copia-y-pega”). Esta característica resulta de gran utilidad ante traducciones que carecen, total o parcialmente, de su text domain o cuyo text domain coincide con otro ya existente, circunstancias ambas que producen resultados lingüísticos inesperados y a menudo muy irritantes (porque el sufrido usuario ignora la razón de que determinadas cadenas de texto no aparezcan en su propia lengua o, peor aún, que ofrezcan un resultado distinto al que ha propuesto en su traducción). Evidentemente, el plugin no puede rehacer las fuentes en PHP para incluir el text domain, pero identifica perfectamente los ficheros y las líneas en que se produce este fallo, con lo cual la ingrata tarea de corregir unos y otras se ve muy facilitada. Una vez añadido el text domain a los archivos PHP (proceso que se puede automatizar mediante editores que incorporar funciones de búsqueda y sustitución en bloque, como Notepad++), la regeneración del fichero .PO, su traducción y conversión en fichero de código máquina .MO se convierte en un juego de niños.

A pesar de sus muchas virtudes, el plugin Codestyling Localization tiene ciertas limitaciones relacionadas con el soporte de idiomas, los directorios definidos para las versiones idiomáticas y la dificultad de detectar el text domain, todas ellas superables mediante diversos trucos (véase el epígrafe “Plugin Limits”, en la página de esta extensión). Además, existe una dificultad insuperable no sólo para este plugin, sino para cualquier otra utilidad de traducción: si la plantilla o extensión no han sido “internacionalizadas”, es decir, preparadas para ser traducidas, sólo cabrá recorrer minuciosamente los archivos PHP para sustituir las cadenas originales en inglés por las de la lengua del usuario. Naturalmente, esta alternativa tiene un inconveniente muy serio, y es que una pieza de software traducida “a mano” sólo puede presentar cadenas de texto en el idioma al que se ha sido vertido el código original.

Por otra parte, hay muchas plantillas y plugins que producen traducciones inexactas o incompletas (es decir, cuyo grado de “internacionalización” es parcial), porque olvidan aspectos como las fórmulas de fecha y hora, porque no preparan para su traducción todos los elementos que tienen representación textual, porque consideran que todas las lenguas siguen el mismo orden de palabras que el inglés, etc. (sobre algunas de estas cuestiones,y en relación con el tema Tarski, hace algún tiempo que escribí un artículo en este blog; animo a los interesados en abordar seriamente las complejidades de la internacionalización a que lean dos artículos interesantísimos de Urban Giraffe, Translating WordPress Plugins & Themes y Localizing WordPress Themes and Plugins). En una situación como cualquiera de las que acabo de citar, la mejor herramienta de traducción producirá resultados mediocres, que únicamente pueden mejorarse con trucos más o menos certeros, o rehaciendo el código incorrecto, para lo cual se requiere que el usuario tenga conocimientos de programación en PHP. No es una tarea excesivamente difícil para un programador con experiencia, pero es muy posible que el esfuerzo no merezca la pena.

Se me dirá que bastante hacen los programadores en ofrecer sus creaciones al público gratis et amore, pero esto no es siempre cierto, pues de hecho existen buenos temas y plugins, perfectamente preparados para la traducción y del todo gratuitos, y en cambio productos de pago cuyo grado de traducibilidad es manifiestamente mejorable. Ya sé que citar nombres es peliagudo y que las comparaciones son odiosas, pero entre los primeros se encuentran excelentes plantillas, como la tantas veces citada Tarski, y entre los segundos el famoso Farms 100 big ones theme pack, de WPMU Dev Premium, que en tantas plataformas de blogs se utiliza, no siempre con resultados idóneos.

Desde mi punto de vista de usuario que invierte mucho tiempo y esfuerzo en tareas de traducción (decía Potâchov en la citada e inencontrable intervención en Twitter que él ha debido de traducir unos treinta temas; hace tiempo que yo he dejado de contar los que he traducido, a veces sólo para comprobar, con el cabreo consiguiente, que no me servían, o que era incapaz de resolver sus fallos de internacionalización), creo que los responsables de la gestión de WordPress, y en particular la de los repositorios oficiales de temas y plugins, deberían prestar una atención mucho más precisa y consciente a este asunto. Quizás sea demasiado drástico considerar una adecuada internacionalización como una condición sine qua non para albergar oficialmente las plantillas y extensiones (además, la comprobación exhaustiva de esta característica implicaría un equipo humano de considerables dimensiones), pero la política de gestión de proyectos tan ampliamente usados en todo el mundo, y más cuando afectan al ámbito educativo, debería ir en tal sentido.

Esta entrada Traduciendo WordPress, sus plantillas y extensiones, con el plugin Codestyling Localization ha sido publicada en primer lugar en La Bitácora del Tigre.