WordPress es un proyecto global y uno de sus grandes valores es, precisamente, la localización. Poder instalar WordPress y utilizarlo en nuestra lengua y con expresiones adaptadas a nuestro entorno es fruto del trabajo de miles de voluntarios (y ojalá resuene en tu cabeza «voluntarios» como aquella frase famosa de los Simpsons, «Lisa necesita un aparato. Seguro dental. BRRRRR» en bucle).
Pero precisamente porque ese trabajo es voluntario y los recursos son limitados, (aunque en el grupo de slack piensen que estos recursos son una fuente inagotable de farmear aura), quizá merezca la pena plantear una pregunta: ¿estamos utilizando esos recursos de la mejor manera posible?
No se trata de cuestionar que existan distintas variantes del español. Las diferencias entre países son reales y, en determinados casos, perfectamente justificadas. La cuestión es otra: ¿tiene sentido mantener de forma independiente traducciones que son prácticamente idénticas mientras otras permanecen incompletas, desactualizadas o presentan inconsistencias terminológicas? Y esto es por el simple hecho de que alguien decide que esto es así y listo.
Comparemos las traducciones del core (version 7.1)
Para intentar responder a esa pregunta he comparado los archivos de traducción del core de WordPress de distintos locales españoles tomando es_ES como referencia.
No es un análisis lingüístico exhaustivo. Los porcentajes simplemente permiten medir hasta qué punto las cadenas traducidas coinciden literalmente o son muy similares.
Los resultados son bastante interesantes:
| Local | Cadenas comparadas | Idénticas | Idénticas o ≥ 90 % | Similitud media |
|---|---|---|---|---|
| Argentina | 6.916 | 61,54 % | 80,62 % | 94,17 % |
| Chile | 7.419 | 64,38 % | 76,84 % | 92,81 % |
| Colombia | 7.415 | 75,32 % | 86,54 % | 95,87 % |
| Costa Rica | 7.380 | 70,47 % | 83,98 % | 95,15 % |
| República Dominicana | 3.724 | 98,31 % | 99,01 % | 99,57 % |
| Ecuador | 4.895 | 93,03 % | 96,08 % | 98,63 % |
| Guatemala | 2.389 | 75,26 % | 88,07 % | 96,25 % |
| Honduras | 146 | 60,27 % | 74,66 % | 88,98 % |
| México | 7.527 | 78,00 % | 89,28 % | 96,66 % |
| Perú | 5.572 | 99,30 % | 99,55 % | 99,82 % |
| Puerto Rico | 2.804 | 91,76 % | 97,33 % | 98,98 % |
| Uruguay | 3.296 | 98,18 % | 98,97 % | 99,65 % |
| Venezuela | 4.925 | 91,07 % | 97,10 % | 98,93 % |
Hay casos en los que las diferencias son claras. Argentina, por ejemplo, adapta formas verbales como «tenéis» a «tenés». En Chile encontramos con frecuencia «agregar» donde es_ES utiliza «añadir». Colombia emplea variantes como «ícono» y en Costa Rica aparecen diferencias en el tratamiento al usuario.
Podemos discutir si cada una de esas decisiones es necesaria, pero al menos existe una localización perceptible. En otros casos resulta mucho más difícil encontrarla.
El caso de Perú es especialmente llamativo
De las 5.572 cadenas comparadas entre español de España y español de Perú, 5.533 son exactamente iguales. Eso supone un 99,30 % de coincidencia literal. Si además incluimos las cadenas cuya similitud supera el 90 %, llegamos al 99,55 %, con una similitud media global del 99,82 %.
En otras palabras, podríamos sustituir prácticamente todo el archivo peruano analizado por el español de España y, estadísticamente, sería difícil encontrar qué ha cambiado.
República Dominicana presenta una situación muy parecida: un 98,31 % de cadenas completamente idénticas y un 99,01 % si incorporamos aquellas con una similitud superior al 90 %. Uruguay alcanza un 98,18 % de cadenas idénticas. Incluso Ecuador, Puerto Rico o Venezuela presentan niveles de coincidencia extraordinariamente elevados.
Y aquí es donde creo que merece la pena plantear el debate.
Localizar no debería significar duplicar
Que dos países hablen español no significa que utilicen exactamente el mismo español. Evidentemente existen diferencias de vocabulario, tratamiento, conjugación, ortografía preferida o convenciones locales. Por tanto, tiene sentido que WordPress permita adaptar su interfaz. Pero una localización debería aportar precisamente eso: localización.
Cuando el 98 % o el 99 % de las cadenas son idénticas a otro locale, cabe preguntarse si estamos realmente manteniendo una traducción diferente o simplemente duplicando miles de cadenas para modificar unas pocas decenas.
Y mantener una traducción tiene un coste. No necesariamente económico, porque buena parte del trabajo de traducción de WordPress procede de colaboradores voluntarios (una fuente inagotable de recursos como los voluntarios en los departamentos de la universidad), pero sí existe un coste en tiempo, revisión, coordinación y mantenimiento.
Cada nueva cadena introducida en WordPress debe traducirse. Cada modificación debe revisarse. Cada versión vuelve a generar trabajo pendiente en numerosos proyectos de traducción. Por eso quizá el objetivo no debería ser simplemente tener cuantos más locales mejor, sino conseguir que los locales existentes sean completos, coherentes y de calidad.
Menos cantidad y más calidad
Aquí aparece una cuestión que me parece todavía más importante. Mientras dedicamos esfuerzos a mantener traducciones que en algunos casos son idénticas en más de un 99 %, seguimos encontrando inconsistencias entre traducciones españolas.
Un mismo concepto puede recibir distintas traducciones dependiendo del proyecto, del locale o incluso de la cadena concreta. Y en una aplicación como WordPress la consistencia terminológica importa.
Términos relacionados con bloques, patrones, plantillas, entradas, páginas, medios, plugins, temas, ajustes, capacidades o roles deberían seguir criterios claros y mantenerse de forma coherente.
No significa necesariamente que todos los países tengan que utilizar las mismas palabras. Si existe una diferencia lingüística real y habitual, adaptarla es precisamente el objetivo de una localización.
Pero cuando no existe una razón lingüística para diferenciarlas, quizá sería más útil compartir criterios y esfuerzos.
¿Y si las traducciones heredaran de una base común?
Quizá parte del problema sea el propio modelo. En lugar de considerar cada locale español como una traducción completamente independiente, podría plantearse algún sistema de traducción base con excepciones locales.
Por ejemplo, partir de una traducción común y mantener únicamente aquellas cadenas que realmente necesiten una adaptación para Argentina, México, Chile, Perú, República Dominicana o cualquier otro país.
Conceptualmente sería algo parecido a: Español común → adaptación local → excepciones propias
Así, si una cadena no necesita adaptación, no habría que traducirla trece veces. Y cuando apareciese una nueva cadena en el core, podría heredarse inicialmente de la traducción común hasta que el equipo local considerase necesario modificarla.
Un locale con 40 diferencias reales no necesitaría mantener otras 5.500 cadenas idénticas únicamente para disponer de su propio paquete de idioma.
Los datos tampoco cuentan toda la historia
Hay que introducir además una cautela importante: el número de cadenas comparadas varía muchísimo entre locales.
Mientras México, Chile, Colombia o Costa Rica permiten comparar más de 7.000 cadenas, Honduras apenas cuenta con 146 en este análisis. República Dominicana tiene 3.724 y Perú 5.572. Por tanto, estos porcentajes no sirven por sí solos para afirmar qué traducción es mejor o peor.
De hecho, ahí aparece otro argumento para reflexionar sobre cómo se distribuyen los esfuerzos: una traducción puede ser casi idéntica a otra y, al mismo tiempo, estar bastante menos completa.
La pregunta entonces resulta todavía más interesante: ¿merece la pena mantener miles de cadenas duplicadas si eso no garantiza siquiera disponer de una traducción completa?
No se trata de eliminar variantes del español
Creo que sería un error interpretar este debate como una propuesta para imponer el español de España al resto de países. No se trata de eso. es_ES simplemente ha servido como referencia para realizar la comparación. Podría discutirse perfectamente la creación de una base común diferente, consensuada entre los distintos equipos de traducción.
Tampoco se trata de decidir qué variante del español es «correcta». Todas pueden incorporar particularidades perfectamente legítimas. La cuestión es mucho más práctica: ¿Cuántas de esas diferencias justifican realmente mantener miles de cadenas independientes?
Los datos muestran que en algunos locales sí existe una adaptación considerable. Argentina solo comparte literalmente el 61,54 % de las cadenas analizadas con es_ES; Chile, un 64,38 %. Ahí resulta evidente que estamos ante trabajos de localización diferenciados.
Pero cuando hablamos de un 99,30 % de coincidencia literal, como sucede con Perú, parece razonable al menos preguntarse si existe una forma más eficiente de organizar ese trabajo.
Una cuestión de recursos
WordPress depende enormemente de su comunidad. El tiempo de las personas que traducen, revisan y validan cadenas es un recurso limitado. Precisamente por eso quizá habría que intentar aprovecharlo mejor. Tal vez sea preferible dedicar más tiempo a completar traducciones, revisar cadenas antiguas, corregir errores, establecer glosarios comunes y mejorar la consistencia terminológica, y menos a mantener de forma independiente miles de cadenas que ya son exactamente iguales.
La localización es importante. Las diferencias lingüísticas también. Pero localizar no debería convertirse en duplicar trabajo simplemente porque técnicamente podemos crear un locale para cada país. Los resultados de estas comparaciones no ofrecen una respuesta definitiva, pero sí dejan una pregunta que creo que merece debatirse dentro de la comunidad:
¿Queremos medir el éxito de la localización de WordPress por la cantidad de variantes disponibles o por la calidad, coherencia y utilidad real de sus traducciones?
