Si tienes WordPress 2.7.1 instalado, seguramente desde ayer WordPress te pide actualizar a la misma versión que tienes. Y te preguntas… si ya tengo 2.7.1 ¿para qué voy a actualizar a 2.7.1? La respuesta es simple y para descubrirla solamente tienes que seguir el enlace.
Esto se debe a que no vas a actualizar a WordPress 2.7.1, vas a actualizar a WordPress 2.7.1-es_ES, vamos, a la traducción oficial que desde TodoWordPress no recomendamos por tocar archivos del corazón de WordPress. Si quieres continuar con nuestra traducción (mil gracias) simplemente tienes que pulsar sobre Ocultar esta actualización y ya no te volverá a molestar (hasta la próxima versión de WordPress).
Ahora toca algo de crítica
¿Cómo es que a estas alturas aparece el mensaje?
Eso es responsabilidad de las personas que realizan la traducción “oficial”, que lanzaron la traducción de 2.7 el mismo día del lanzamiento oficial. Pero… para esta versión han tardado casi un mes en modificar una línea, que es en lo que se diferencia la traducción de 2.7 a la de 2.7.1.
Yo ya tengo la traducción de TodoWordPress, ¿para qué tengo que actualizar?
Buena pregunta y me gustaría que los chicos de Automattic respondieran.
¿No es posible añadir una función, al igual que pasa con los plugins, para que se actualicen las traducciones no oficiales?
Y si ya tienes una traducción no oficial, ¿no sería posible evitar el mensaje que te actualiza a la oficial?
La comunidad que se encarga de traducir WordPress no solo al castellano o español, sino a otros idiomas ¿no merece el mismo respeto que quien realiza la traducción oficial, que además crea incompatibilidades por tocar cosas que no debería tocar?
Se supone que una traducción es solo el archivo .mo ¿Por qué cuando actualizo se actualizan todos los archivos de WordPress, no solamente se añade el archivo, y modifica el wp-config.php?
Lo primero que sería imposible, ya que la traducción oficial no solo se limita a los .mo sino que modifica el core de WordPress para que la traducción sea más exacta ¿Pero a cambio de qué? A cambio de incompatibilidades con muchos plugins y posibles brechas de seguridad.
Y lo segundo es que, los chicos de Automattic en vez de hacer un repositorio de traducciones y que el usuario del CMS decida lo que más le conviene (como los plugins), confiaron el trabajo a una sola persona olvidando al resto de la comunidad que diariamente lucha por WordPress y saca las traducciones al momento del lanzamiento. ¿Eso es una comunidad?
Una sola persona realiza una traducción que obtiene de forma arbitraria un carácter oficial, mediante su alojamiento en wordpress.org. Muchos usuarios prefieren otra traducción no oficial porque la oficial les da problemas, ven este mensaje, actualizan y se quedan con la traducción oficial, quieran o no, tirando por la borda el trabajo de la comunidad que había detrás de la traducción que WordPress acaba de eliminar. ¿Es esa la fisolofía del software libre?
Posibles soluciones
- Un repositorio de traducciones: Al igual que la hay para los plugins ¿por qué no uno de traducciones donde el usuario elija que traducción quiere tener instalada?
- Volver al sistema tradicional: ¿No sería mejor volver a hacerlo como siempre y evitar problemas?
- “Oficial” pero sin pisar a los demás: Si no queda más remedido de que una traducción sea más que el resto (algo que no me gusta para nada), al menos que si el sitio ya se encuentra con otra traducción “no oficial”, que la “oficial” no la pise y elimine así como así el trabajo de la comunidad detrás de esa traducción “no oficial”
¿Y tú que piensas? Deja tu comentario.
12 comentarios
04/03/2009
Me parece muy lógico lo que dices, aunque yo tenga instalada la traducción oficial y aún no me haya dado ningún problema, no me fio debido a la cantidad de gente que notifica problemas de este tipo.
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!!!
04/03/2009
Al ver que tenia que actualizar la versión de WordPress a la misma versión creí que era un bug o algo parecido. Luego de ver que el mensaje continuaba opto por actualizar, pero no se podia, para hacerlo hay que desactivar algunos plugins.
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.
04/03/2009
Parece que, efectivamente, está llegando la hora de abrir un debate sobre la comunidad de WordPress en español. Por esta y por muchas otras razones.
04/03/2009
Pues respecto a las traducciones y las actualizaciones, me parece que se dijo que en 2.8 la actualización automática incluiría las traducciones oficiales de WordPress (http://es.wordpress.org), pero no sé nada sobre traducciones no oficiales…
04/03/2009
Yo también leí algo sobre lo que comenta Marc, pero no recuerdo si podría ser una especie de repositorios para elegir el idioma desde el panel de administrador.
05/03/2009
Para mí el mayor problema está sobre todo en la modificación del core. Creo que las traducciones presentarían menos problemas si se limitaran a usar los archivos .pot y .mo, como se hacen con los plugins. Además el equipo de desarrolladores habituales de WordPress no perdería el control del programa.
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.
05/03/2009
Añado mi pleno apoyo (y más que nada, cabreo) a lo expuesto por Francisco y Ángeles. Me parece absolutamente ridículo que te dé la lata sólo porque algunos han ofrecido un mínimo cambio, evidentemente sin comprobación de forma alguna de la versión sobre la cual WP está de hecho funcionando (porque de hacerlo, sabría que ya está actualizada a la última versión disponible).
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.
05/03/2009
Alvaro, creo que has dado en el clavo, lo que deberían hacer los traductores “oficiales” es justamente eso, preparar la localización, que es el origen del problema, y no solo de la traducción española, sino de todas.
05/03/2009
Francamente tengo un esbozo de solución en la cabeza, pero creo que es un plugin bastante complicado, por tener que meter mano a:
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… :-(
05/03/2009
A mi tambien me extraño la actualizacion, pero yo actualice y hasta ahora ningun problema
12/04/2009
bueno, pues si alguien estaba esperando un error de wordpress por culpa de esta pseudoactualización furtiva, pues yo lo tienen: el mío. Actualicé inconscientemente y a los días problemón: me desaparecieron las categorías, etiquetas y enlaces.
Primero pensé en la base de datos pero no. Reinstalé wp 2.7.1-es_ES y me siguió dando error. Con la oficial wp 2.7.1 y esta traducción parece que todo vuelv a funcionar.
17/04/2009
eloradorsobreelparamo, me alegro que pudieras solucionarlo ¡menudo susto!
Trackbacks
Deja tu comentario