1) CSS (hay que declarar una serie de clases para hacer los distintos cambios de mayúsculas y minúsculas permitidos (y necesarios según el caso del idioma) y luego, esas clases tienen que ser metidos en la cabecera de alguna forma (p.ej. interviniendo en header.php e introducir las declaraciones ahí);
2) hacer una sustitución sobre la marcha de instrucciones dadas mediante etiquetas en shortcode (que a su vez hacen la llamada del tipo de conversión de mayús/minús) que emparejan o encapsulan en una definición de clases aquellas palabras / segmentos de cadenas que requieren cambio de mayús/minús y que son sacadas del .mo;
3) (y esto es lo más difícil) hacer que desarrolladores y traductores metan esos shortcode en los temas.

El problema es que, por una parte, la solución más “limpia” es una redefinición de mayús/minús mediante CSS, pero por otra, el meter mano a CSS sin tocar el styles.css de turno puede causar bastantes problemas (por lo cual sospecho que habría que meter más declaraciones del tipo !important de lo que cabe tolerar en un buen diseño.

No veo tan claro cómo llegar a una estrategia de solución que pase exclusivamente por PHP.

En todo caso, sé lo suficiente de PHP como para saber, más bien por intuición, lo que se podría hacer, pero no tanto como para atreverme a tirarme a la piscina… :-(

Y lo siento mucho, pero de “versiones traducidas” que suponen en realidad la publicación de un paquete distinto, con cambios en los archivos nucleares simplemente no me fío ni un pelo.

I trust the English version, full stop.

Cuando deslinden las cosas mediante una simple publicación de archivos .po/.mo (¡y punto!) me lo replantearé. Bueno, no habrá nada que replantearse, porque a partir de ahí, todos trabajamos con el mismo WordPress, sea cual sea el idioma en el que lo mostramos.

Pero claro, el tema es que ese “equipo de traductores oficiales” confunde el mal rollo de los temas mal traducidos (por no estar ni los archivos nucleares ni los temas con que se distribuyen debidamente localizados, es decir: preparados para traducción, que es el problema REAL aquí) con el tema de la distribución nuclear en sí. Y ese es para mi el problema: en lugar de limitarse a ser traductores, el equipo se ha metido en camisas de once varas – y los problemas siguen de ahí.

Increíble.

Este sistema está dando muchos problemas, en mi humilde opinión es mejor volver a lo que se hacía antes, te bajabas el programa y el archivo de traducción sin más. Si no existía ninguna traducción oficial o tardaba demasiado en publicarse, incluso te lo podías traducir tú mismo y ponerlo a disposición de la comunidad.

Me parece más práctico. Sobre todo teniendo en cuenta la cantidad de idiomas a los que se traduce WordPress.

En todo caso, si lo que se pretende es facilitar la instalación a usuarios noveles, podría presentarse un paquete de instalación, con los archivos .mo de todos los idiomas y la carpeta languages ya creada.

De esta forma el usuario solo tendría que rellenar su lenguaje en config.php

¿No os parece más práctico? El esfuerzo que se dedica a modificar el programa y resolver los errores que surgen y los posibles agujeros de seguridad, podría dedicarse a otras cuestiones que están aún por solucionar.

Luego la actualización no tiene nada de nuevo, si han de sacar traducciones oficiales debería basarse en el trabajo de grupo, y esta debe ser lanzada en la misma fecha.

Yo mismo respondí en el foro de TodoWordpress una duda que tenía una compañera sobre el dichoso cartelito, que parece ser que al final salió por buen parecer. Por mi parte, apoyo la idea de Francisco para la creación de un repositorio de traducciones no oficiales, y a partir de ahí cada uno eligiría la que más le convenciese.

Saludos!!!