¿Estamos seguros de que estamos publicando para todos los dialectos/zonas correctos? #164
Comments
|
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 |
|
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. |
|
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). |
|
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: y ya puestos me encuentro que: ¡Hala! |
|
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. |
|
@RickieES valdría la pena definir que hacer al respecto para la generación de la versión 2.4. |
|
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. |
|
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. |
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):
[...]
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:
The text was updated successfully, but these errors were encountered: