Re: Format de data incorrecte de «ls -l»
2020-12-24, 13:22 (+0100); Joan Montané escriu: > Caldria veure l'impacte del canvi que indiques. Per exemple en > aplicacions de calendari. Això també trencaria l'alineament amb el > CLDR. Qui va proposar els canvis al CLDR? He intentat investigar-ho, però no he aclarit res. > No tot funcionava perfectament abans del 2016. Aquests canvis són el > que permeten tenir el format de data correctament escrit, amb la > preposició "de" apostrofa quan cal. Per exemple al calendari de > l'escriptori. Em vaig fer un fart de veure "xxx de abril...". > Considero que sí, s'havien de fer. Probablement no calia modificar el local per solucionar un problema al calendari del Gnome. I en el cas improbable que l'única solució fos modificar el local, era previsible que aquests canvis comportarien problemes a altres programes. Les mateixes persones que van fer els canvis s'haurien d'haver responsabilitzat de fer les adaptacions necessàries als programes afectats per tal que seguissin funcionant normalment. Si no estaven disposades a fer-ho, no haurien d'haver modificat el local. No em sembla bé fer modificacions i després desentendre's de les conseqüències negatives d'aquestes modificacions. > Ara hem detectat 2 problemes completament diferents, i és important > diferenciar-los. > > Problema 1: aquest és general. Si un programa usa %b o %B en el format > de data, des del 2016 (en producció des del 2018?) això retorna mesos > amb preposició. Ha canviat la cadena del locale. En aquests casos > només cal corregir la traducció perquè usi %Ob o %OB. Forma part de la > feina de traducció/localització. En canviar els valors %b i %B es va > assumir que hi hauria un temps de transició on les traduccions no es > veurien bé (apareixeria la preposició duplicada o sense preposició). > La majoria de traduccions ja s'ha adaptat a usar %Ob i %OB. En queda > algun? Doncs es corregeix en la traducció. És el que caldria fer a > mutt. És que, a part de la preposició, els noms abreviats dels mesos han passat de tenir tres caràcters a tenir una llargada variable (amb punt inclòs). Aquestes dades del local no semblen adequades per a programes informàtics. Els programes d'interfície de text estan pensats per funcionar en terminals de 80 columnes. 80 columnes vol dir que l'espai és extremadament limitat i que la informació textual ha de ser minimalista. Si comencem a incloure punts, caràcters innecessaris i textos de llargades variables que trenquen l'alineació, l'usuabilitat d'aquests programes es degrada tant que els usuaris probablement no tindran més alternativa que emprar un altre local. Salutacions.
Re: Format de data incorrecte de «ls -l»
Comento entre paràfrafs, Missatge de Ernest Adrogué del dia dj., 24 de des. 2020 a les 12:36: > > Hola, > > 2020-12-24, 09:41 (+0100); Joan Montané escriu: > > En fi, que segueixo pensant que la solució de compromís és usar %b i > > tenir la columna de mesos amb preposició, però ben enquadrada. > > Crec que no té sentit incloure la preposició en els noms mesos > abreviats. Si utilitzem la versió abreviada és que volem estalviar > espai, i si volem estalviar espai, la preposició sobra completament. > Caldria veure l'impacte del canvi que indiques. Per exemple en aplicacions de calendari. Això també trencaria l'alineament amb el CLDR. > Per altra banda, 'ls' no és l'únic programa afectat. Un altre programa > afectat és el 'mutt'. Probablement n'hi ha d'altres. Aquests programes > funcionaven perfectament fins que van modificar el text dels noms dels > mesos en el local ca_ES, l'abril de 2016 [1]. Aquests canvis són > l'origen de tots aquests problemes. Tenint en compte que, després de 4 > anys, ni estan resolts, ni tenim clar com resoldre'ls, em sembla que ens > hem de plantejar seriosament revertir els canvis al local i deixar els > noms dels mesos com estaven. Vejam, crec que barregem coses. No tot funcionava perfectament abans del 2016. Aquests canvis són el que permeten tenir el format de data correctament escrit, amb la preposició "de" apostrofa quan cal. Per exemple al calendari de l'escriptori. Em vaig fer un fart de veure "xxx de abril...". Considero que sí, s'havien de fer. Ara hem detectat 2 problemes completament diferents, i és important diferenciar-los. Problema 1: aquest és general. Si un programa usa %b o %B en el format de data, des del 2016 (en producció des del 2018?) això retorna mesos amb preposició. Ha canviat la cadena del locale. En aquests casos només cal corregir la traducció perquè usi %Ob o %OB. Forma part de la feina de traducció/localització. En canviar els valors %b i %B es va assumir que hi hauria un temps de transició on les traduccions no es veurien bé (apareixeria la preposició duplicada o sense preposició). La majoria de traduccions ja s'ha adaptat a usar %Ob i %OB. En queda algun? Doncs es corregeix en la traducció. És el que caldria fer a mutt. Problema 2: aquest és molt particular de «ls», que era el motiu d'aquest fil. «ls» no fa cas de la cadena de la traducció, perquè fa 10 anys es van carregar un enllaç. I per això fa l'ordre "dia mes" aparegui com en anglès "mes dia" en fer «ls -l». Afectat totes les llengües que volen l'ordre "dia mes" i així ho tenen definit en la traducció de coreutils (curiosament, l'espanyol no ho té). Com veieu, són problemes completament diferents. El primer té fàcil solució. El segon també. El problema "difícil" de resoldre bé és que en solucionar el problema 2, apareix un 3r problema. Problema 3: «ls» internament parseja %b perquè tots tinguin la mateixa amplada i les columnes queden enquadrades. Això és un problema d'i18n. Podem millorar «ls» o triar una solució de compromís. Hi ha altres programes afectats que parsegin les dates internament? Parlem-ne, perquè aleshores sí que podríem millorar l'i18n d'aquests programes. > > Un altre argument a favor de revertir el canvis és que el local ca_ES > actual utilitza extensions que no figuren a l'estàndard POSIX (almenys > jo no trobo cap referència als elements 'ab_alt_mon' i 'alt_mon' a > l'especificació POSIX [2]). És un problema perquè a l'hora d'adaptar > els programes per tal funcionin amb aquest local, al mateix temps > estarem introduint una dependència a aquestes extensions que no formen > part de POSIX. > Interessant. No vaig participar directament en el canvi dels mesos del locale català, però sí que sé que al CLDR el català està definit com ara ho tenim al locale de la glibc (primer es va fer el canvi al CLDR). Potser en un futur l'estàndard POSIX afegirà els mesos alternatius (el català no és l'única llengua que els usa)? O potser no? Joan Montané
Re: Format de data incorrecte de «ls -l»
Hola, 2020-12-24, 09:41 (+0100); Joan Montané escriu: > En fi, que segueixo pensant que la solució de compromís és usar %b i > tenir la columna de mesos amb preposició, però ben enquadrada. Crec que no té sentit incloure la preposició en els noms mesos abreviats. Si utilitzem la versió abreviada és que volem estalviar espai, i si volem estalviar espai, la preposició sobra completament. Per altra banda, 'ls' no és l'únic programa afectat. Un altre programa afectat és el 'mutt'. Probablement n'hi ha d'altres. Aquests programes funcionaven perfectament fins que van modificar el text dels noms dels mesos en el local ca_ES, l'abril de 2016 [1]. Aquests canvis són l'origen de tots aquests problemes. Tenint en compte que, després de 4 anys, ni estan resolts, ni tenim clar com resoldre'ls, em sembla que ens hem de plantejar seriosament revertir els canvis al local i deixar els noms dels mesos com estaven. Un altre argument a favor de revertir el canvis és que el local ca_ES actual utilitza extensions que no figuren a l'estàndard POSIX (almenys jo no trobo cap referència als elements 'ab_alt_mon' i 'alt_mon' a l'especificació POSIX [2]). És un problema perquè a l'hora d'adaptar els programes per tal funcionin amb aquest local, al mateix temps estarem introduint una dependència a aquestes extensions que no formen part de POSIX. [1] https://sourceware.org/git?p=glibc.git;a=blobdiff;f=localedata/locales/ca_ES;h=d9a29d10a26acd58a711c7a8774ae31a0f35c396;hp=6c0105dd3085094ef7421147436be2116b66162f;hb=refs/heads/master;hpb=2e7a46132898c861785cb3da575033936d18fc4e [2] https://pubs.opengroup.org/onlinepubs/95399/basedefs/xbd_chap07.html#tag_07_03
Re: Format de data incorrecte de «ls -l»
Missatge de Eloi del dia dj., 24 de des. 2020 a les 9:06: > > El 24/12/20 a les 7:29, Joan Montané ha escrit: > > Missatge de Joan Montané del dia dj., 24 de des. > > 2020 a les 6:47: > > > >> Tal com ho veig, la millor opció, de compromís, és canviar la cadena a > >> coreutils perquè usi %b en comptes de %Ob. Això només afectaria a «ls». > >> L'únic inconvenient és que a la columna de mesos tindríem la preposició, > >> però les columnes quadraran. > >> > > Si algú vol fer aquesta solució de compromís, no és gens complicat. > > > > En un directori de treball. > > > > Baixeu el fitxer .po (he usat la versió 8.30 per al paquet coreutils de > > buster) > > curl https://translationproject.org/PO-files/ca/coreutils-8.30.79.ca.po > > -o coreutils.po > > > > Canvieu els cadenes amb %Ob a %b del fitxer anterior, amb qualsevol > > editor de text decent o des de terminal. Aquests canvis només afecte a > > «ls -l»: > > sed -e "s/^msgstr \"%e %Ob /msgstr \"%e %b /" < coreutils.po > > > coreutils-fixed.po > > > > Compileu el .po a .mo > > msgfmt coreutils-fixed.po -o coreutils.mo > > > > Amb permisos de root, copieu el .mo al directori que pertoca (si > > voleu, feu-vos còpia del .mo que esteu a punt de sobreescriure) > > sudo cp ./coreutils.mo /usr/share/locale/ca/LC_MESSAGES/ > > > > I ja està, les columnes quadren en fer «ls -l», :) > > > > Salut! > > Joan Montané > > > No ho he provat compilant el locale, però hi hauria una altra possible > solució usant la següent cadena de formatació: "%e %5Ob %Y". > Mmmm, bona idea, com dius quedaria alinea a la dreta. He fet la prova, per a veure com quedaria. Hi ha un altre problema. %5b o %5Ob compta bytes, no caràcters. Això vol dir que falla (no compta bé, segons el nostre interès) al març, perquè en codificació UTF8 la ce trencada ocupa 2 bytes, :_( En aquest cas manca un espai i desquadra la columna. En fi, que segueixo pensant que la solució de compromís és usar %b i tenir la columna de mesos amb preposició, però ben enquadrada. Salut! Joan Montané
Re: Format de data incorrecte de «ls -l»
El 24/12/20 a les 7:29, Joan Montané ha escrit:
Missatge de Joan Montané del dia dj., 24 de des.
2020 a les 6:47:
Tal com ho veig, la millor opció, de compromís, és canviar la cadena a
coreutils perquè usi %b en comptes de %Ob. Això només afectaria a «ls». L'únic
inconvenient és que a la columna de mesos tindríem la preposició, però les
columnes quadraran.
Si algú vol fer aquesta solució de compromís, no és gens complicat.
En un directori de treball.
Baixeu el fitxer .po (he usat la versió 8.30 per al paquet coreutils de buster)
curl https://translationproject.org/PO-files/ca/coreutils-8.30.79.ca.po
-o coreutils.po
Canvieu els cadenes amb %Ob a %b del fitxer anterior, amb qualsevol
editor de text decent o des de terminal. Aquests canvis només afecte a
«ls -l»:
sed -e "s/^msgstr \"%e %Ob /msgstr \"%e %b /" < coreutils.po >
coreutils-fixed.po
Compileu el .po a .mo
msgfmt coreutils-fixed.po -o coreutils.mo
Amb permisos de root, copieu el .mo al directori que pertoca (si
voleu, feu-vos còpia del .mo que esteu a punt de sobreescriure)
sudo cp ./coreutils.mo /usr/share/locale/ca/LC_MESSAGES/
I ja està, les columnes quadren en fer «ls -l», :)
Salut!
Joan Montané
No ho he provat compilant el locale, però hi hauria una altra possible
solució usant la següent cadena de formatació: "%e %5Ob %Y".
Això forçarà que l'amplada del camp del mes sigui de 5 caràcters, la
longitud del mes més llarg, però té els inconvenients que alinea els
mesos a la dreta, el que queda una mica estrany; i que la longitud del
camp està fixada a la cadena de formatació, i si es tornen a canviar les
abreviatures dels mesos s'hauria de reajustar de nou.
Una mostra ràpida de com quedaria, vist amb Python:
>>> locale.setlocale(locale.LC_ALL, 'ca_ES.utf8')
'ca_ES.utf8'
>>> for i in range(12):
... datetime.date(2020, i+1, 15).strftime("%e %5Ob %Y")
...
'15 gen. 2020'
'15 febr. 2020'
'15 març 2020'
'15 abr. 2020'
'15 maig 2020'
'15 juny 2020'
'15 jul. 2020'
'15 ag. 2020'
'15 set. 2020'
'15 oct. 2020'
'15 nov. 2020'
'15 des. 2020'
