¿Estamos seguros de que estamos publicando para todos los dialectos/zonas correctos?

[olea]

Caolán me ha lanzado una duda que me ha dejado bastante sorprendido refiriéndose a la localización es_PH: https://src.fedoraproject.org/rpms/mythes-es/pull-request/1#comment-4290

Hasta donde he podido descubrir cada código local debe estar oficialmente registrado y en particular no encuentro rastro del es_PH.

Pero, ya peor, me he puesto a hacer alguna comprobación en mi sistema y observo que en particular LibreOffice no maneja varios de los diccionarios instalados:

como se comprueba en

Obsérvese que LO no parece usar los diccionarios de ANY, es_US ni es_PH.

Todo esto ussando libreoffice-writer-5.3.7.2-6.fc26.x86_64 y las versiones 2.3 de los diccionarios:

Me es muy complicado encontrar bibliografía de referencia. En particular de ISO 639-*, que es pagoware. Al menos en los código

Por ejemplo en la localización en libstdc++ sí se menciona es_US pero no es_PH.

Ídem interrogando la orden locale (en Linux):

$ locale -a|grep es|sort
eesti
es_AR
es_AR.iso88591
es_AR.utf8
es_BO
es_BO.iso88591
es_BO.utf8
es_CL
es_CL.iso88591
es_CL.utf8
es_CO
es_CO.iso88591
es_CO.utf8
es_CR
es_CR.iso88591
es_CR.utf8
es_CU
es_CU.utf8
es_DO
es_DO.iso88591
es_DO.utf8
es_EC
es_EC.iso88591
es_EC.utf8
es_ES
es_ES@euro
es_ES.iso88591
es_ES.iso885915@euro
es_ES.utf8
es_GT
es_GT.iso88591
es_GT.utf8
es_HN
es_HN.iso88591
es_HN.utf8
es_MX
es_MX.iso88591
es_MX.utf8
es_NI
es_NI.iso88591
es_NI.utf8
es_PA
es_PA.iso88591
es_PA.utf8
es_PE
es_PE.iso88591
es_PE.utf8
es_PR
es_PR.iso88591
es_PR.utf8
es_PY
es_PY.iso88591
es_PY.utf8
es_SV
es_SV.iso88591
es_SV.utf8
estonian
es_US
es_US.iso88591
es_US.utf8
es_UY
es_UY.iso88591
es_UY.utf8
es_VE
es_VE.iso88591
es_VE.utf8

[...]

Tras mucho arrebuscar creo que he encontrado una buena referencia: en el «CLDR - Unicode Common Locale Data Repository» http://cldr.unicode.org/. Particularmente en:

https://www.unicode.org/repos/cldr/tags/release-32-0-1/common/main/, a su vez publicados en https://unicode.org/Public/cldr/1.8.0/core.zip y efectivamente para lengua española tendríamos los siguentes códigos: es_AR, es_BO, es_BR, es_BZ, es_CL, es_CO, es_CR, es_CU, es_DO, es_EA, es_EC, es_ES, es_GQ, es_GT, es_HN, es_IC, es_MX, es_NI, es_PA, es_PE, es_PH, es_PR, es_PY, es_SV, es_US, es_UY y es_VE

además de: es y es_419 que no acabo de saber como tenerlos en cuenta exactamente. Tampoco es igual la manera de presentar los contenidos en https://www.unicode.org/repos/cldr/tags/release-32-0-1/common/main/ y en https://unicode.org/Public/cldr/1.8.0/core.zip. Parece que en el primero las configuraciones en cada fichero son completas por código local mientras que en el segundo parece que cada código local contiene las diferencias de configuración respecto al general es.xml.

Conclusiones

Pues después de tanto divagar llego hasta:

• publicar es_PH parece que es una pérdida de tiempo puesto que ninguna herramienta sería capaz de usar ese código;
• nos faltaría es_GQ para Guinea Ecuatorial, que también tiene español como lengua oficial;
• ¿hay un bug en, al menos, LibreOffice, que no permite usar es_US que es un código reconocido?
• ¿estamos publicando correctamente es_ANY?, es decir, ¿nos consta que las herramientas usan este código?

[cosmoscalibur]

La verdad no pude encontrar documentación al respecto, pero al ver la opción de configuración de lenguaje de LibreOffice es posible ver una lista de lenguajes por defecto independiente de los locale reconocidos en el sistema operativo y de los paquetes instalados. Por ejemplo, se puede observar en dicha lista que justo las dos variantes regionales discutidas no figuran, así como tampoco figuran otras lenguas (por ejemplo, esta la opción de inglés de filipinas pero no de filipino que también es lengua oficial). Me atrevería a afirmar que si la variante del corrector de ortografía no coincide con las opciones de lenguaje predefinidas en LibreOffice, simplemente no será reconocida.
Aún así, creo que la generación de las variantes (ANY, US, PH e incluso GQ si aparecen aportes) vale la pena, no como extensión de LibreOffice pero si al menos los archivos planos que pueden ser usados en editores que permitan la configuración con estos.

[olea]

Si se confirma que LO no reconoce los códigos es_US y es_GQ entonces creo que debemos reportarlo como un bug. Y ya puestos sería apropiado que verificáramos algunas herramientas más.

Lo de la nomenclatura ANY no sé si es terminología LibreOffice pero al menos no es la típica que he salido ver en i18n+l10n general ni en las referencias técnicas identificadas arriba.

Y lo de generar artefactos codificados es_PH, si bien entiendo la lógica general y la buena intención ¿tiene sentido si ninguna herramienta del mundo podría usarla? Sería como regalar tuercas para las que no haya llave compatible.

Otra cosa es compilar material «es_PH», si alguien quiere y puede dedicar esfuerzo. Pero publicarlo como otro diccionario LO hasta donde he comprendido sería como una pieza de Lego que no encaja en ninguna parte :-/

Quiero enfatizar que estos códigos no son arbitrarios ni siquiera son un esquema genérico de nomenclatura. El sistema existe pero cada código ha de ser explícitamente registrado y aprobado en CLDR. Como lo han sido antes es_US y es_GQ. Al menos así es hasta donde he sabido entender.

[cosmoscalibur]

En ese sentido es necesario aclarar si este recurso se dirige para herramientas que solo aceptan diccionarios asociados a configuraciones locales predefinidas o registradas en CLDR (como parece ser LO) o para herramientas en general que permitan agregar un diccionario de ortografía (porque invocan directamente a hunspell con las rutas de los archivos). En la wiki del proyecto se documenta como generar el diccionario para herramientas en las cuales las variantes mencionados no poseen problema por depender de configurar una ruta (por ejemplo, yo he usado es_ANY en TexMaker y en Atom, y las variantes US, PH y GQ funcionarían igualmente sin problema).
También me parece importante resaltar que en los 3 casos regionales mencionados, podemos encontrar una academia de la lengua española. Es decir, efectivamente son variantes en uso y "reguladas" (siendo la filipina más antigua que la estadounidense y que la ecuatoguineana).
En mi caso, por el poco tiempo en el proyecto, carezco del contexto de algunas orientaciones del proyecto, y me parece vital dejar documentada la aclaración de esta discusión.

[olea]

La cosa va a ser más loca aún de lo que yo creía:

esto es lo que ve gedit-3.22 con la misma configuración de diccionarios de antes:

que a su vez usa:

enchant-1.6.0-16.fc26.x86_64
gedit-3.22.1-1.fc26.x86_64
gspell-1.4.2-1.fc26.x86_64
hunspell-1.5.4-2.fc26.x86_64

y ya puestos me encuentro que:

$ hunspell  -D
RUTA DE BÚSQUEDA:
.::/usr/share/hunspell:/usr/share/myspell:/usr/share/myspell/dicts:/Library/Spelling:/home/olea/.openoffice.org/3/user/wordbook:.openoffice.org2/user/wordbook:.openoffice.org2.0/user/wordbook:Library/Spelling:/opt/openoffice.org/basis3.0/share/dict/ooo:/usr/lib/openoffice.org/basis3.0/share/dict/ooo:/opt/openoffice.org2.4/share/dict/ooo:/usr/lib/openoffice.org2.4/share/dict/ooo:/opt/openoffice.org2.3/share/dict/ooo:/usr/lib/openoffice.org2.3/share/dict/ooo:/opt/openoffice.org2.2/share/dict/ooo:/usr/lib/openoffice.org2.2/share/dict/ooo:/opt/openoffice.org2.1/share/dict/ooo:/usr/lib/openoffice.org2.1/share/dict/ooo:/opt/openoffice.org2.0/share/dict/ooo:/usr/lib/openoffice.org2.0/share/dict/ooo
DICCIONARIOS DISPONIBLES (ruta no obligatoria si usa la opción -d):
/usr/share/myspell/es_PE
/usr/share/myspell/es
/usr/share/myspell/es_ES
/usr/share/myspell/es_BO
/usr/share/myspell/es_US
/usr/share/myspell/es_PY
/usr/share/myspell/es_PR
/usr/share/myspell/es_PH
/usr/share/myspell/en_US
/usr/share/myspell/es_PA
/usr/share/myspell/es_UY
DICCIONARIO CARGADO:
/usr/share/myspell/es_ES.aff
/usr/share/myspell/es_ES.dic
Hunspell 1.5.4

¡Hala!

[RickieES]

es_ANY, en el dictionaries.xcu del repositorio de diccionarios de LibreOffice, tiene este valor como locales incluidos:

es-AR es-BO es-CL es-CO es-CR es-CU es-DO es-EC es-ES es-GT es-HN es-MX es-NI es-PA es-PE es-PR es-PY es-SV es-UY es-VE

Efectivamente, en esa lista faltan es_PH y es_US. Faltan porque, tanto en dictionaries_full.xcu como en el script make_dict.sh, la lista de locales está hard-coded en lugar de construirse a partir de los directorios existentes dentro de l10n. A nivel general, tendríamos que añadir es_GQ, como comentas tú, @olea.

[cosmoscalibur]

@RickieES valdría la pena definir que hacer al respecto para la generación de la versión 2.4.

[RickieES]

Añadir las variantes que faltan (tres, ¿verdad? es_GQ, es_PH y es_US) es fácil como tarea en sí. El problema viene porque, a diferencia de los archivos de lemas, no es posible actualmente añadir una regla adicional a una bandera en afijos.txt y que sirva para todas las variantes regionales: hay que insertar la regla localización por localización. Añadir tres variantes supone tres archivos más para mantener y, si a efectos prácticos nadie los usa, es trabajo desperdiciado (una vez añadida la localización, es imprescindible mantenerla al día, no podemos dejarla "ahí" hasta que algún día alguien la reclame).

Si encontráramos una solución sencilla (o no) para el mantenimiento del archivo afijos.txt de forma que tuviéramos un afjos.txt maestro y archivos regionales con únicamente las especialidades de cada localización, no habría que pensárselo mucho, se añade y listo.

No quiero decir que esté en contra de añadir las localizaciones nuevas, sino que hacerlo tiene un coste que nos afectará cuando queramos añadir reglas a los afijos, y que cuantas más localizaciones tengamos, más valor tendrá solucionar el problema con afijos.txt.

Confieso que, después de tanta información, no sé si son tres, dos o una las localizaciones que hay que añadir. Si lo aclaramos entre todos y los demás se pronuncian también, lo podemos solucionar a tiempo de la 2.4.

[olea]

Decir por aquí que he recapitulado todo el asunto de las etiquetas l10n «oficiales» en una entrada en mi blog: https://olea.org/diario/2020/04/25/l10n-lengua-espannola.html

En la práctica la parte más relevante es la del alcance y complitud del corrector para identificar, en su caso, y documentarlos definitivamente (por ejemplo en el wiki), que ya estamos comentando también en Telegram.