Re: Format de data incorrecte de «ls -l»
Missatge de Jordi Pujol del dia dv., 25 de
des. 2020 a les 9:42:
>
> Bondia a tothom,
> és la primera vegada que escric a aquesta llista,
> treballo amb sistemes Linux Debian des de fa temps i he desenvolupat
> alguna cosa.
> En aquest cas puc aportar una solució sencilla.
> Es tracta de modificar el "/usr/share/i18n/locales/ca_ES"
>
> # patch ca_ES locale
> sed -i.bak -e '/^ab_alt_mon/,/^[^ ]/ {/"de /s//"/g
> /"d/s//"/g }' \
> -e '/^abmon/,/^[^ ]/ {/"de /s//"/g
> /"d/s//"/g }' \
> -e '/febr./s//feb./' \
> -e '/ag./s//ago./' \
> "/usr/share/i18n/locales/ca_ES"
>
> Aixó es pot fer en un sistema ja instal.lat, sortim del shell i tornem
> a entrar per veure el resultat.
>
> $ ls -lA
> total 44
> -rw--- 1 jpujol users 80183 25 des. 09:30 .bash_history
> -rw--- 1 jpujol users 84057 15 gen. 2020 .bash_history.old
> -rw-r--r-- 1 jpujol users 4380 15 gen. 2020 .bashrc
> drwxr-xr-x 2 jpujol users 4096 15 abr. 2020 Públic
> drwx-- 3 jpujol users 4096 29 ago. 19:56 .sane
> drwx--x--x 2 jpujol users 4096 7 feb. 2020 .ssh
> Salutacions,
>
> Jordi Pujol
>
Gràcies, Jordi
Això seria equivalent (si es volgués fes que al canvi arribés a
tothom) que canviar els valors associats a %b (mesos abreujats).
No m'agrada perquè trenca l'alineament amb el CLDR i perquè canvia les
abreviatures dels mesos que s'usen arreu.
Té el punt positiu (el gran pro) que facilita la presentació en
columnes en els programes de terminal, cert.
Aprofito i amplio la solució per a "date" que he comentat en el correu anterior.
En el mateix fitxer "/usr/share/i18n/locales/ca_ES" que es comenta més
amunt, caldria canviar la línia:
d_t_fmt"%A, %-d %B de %Y, %T %Z"
I posar-hi:
d_t_fmt"%A, %-d %B de %Y, %T"
date_fmt "%A, %-d %B de %Y, %T %Z
Això és, es treu la zona horària de la variable d_t_fmt, i es defineix
una nova variable date_fmt que és la que usa "date".
Es guarden els canvis i, en el meu cas, sortir del shell no ha estat
suficinet, m'ha calgut tornar a generar el locale:
locale-gen
I ara date ja mostra la data correctament.
Faig una última reflexió sobre aquest fil.
La meva intenció en obrir el fil era fer-vos arribar la solució al
problema de «ls -l» que no té res a veure amb el canvi dels mesos del
català. És un problema que em estar tocant molt els nassos i a l'estiu
hi vaig dedicar una estona fins que vaig comprendre per què fallava
«ls -l». I vaig tenir el problema diagnosticat i reportat vaig poder
dormir tranquil. Havia ajudat amb un gra de serro a millorar Debian.
Fins que vaig veure que la causa del problema amb "date" era
completament diferent, ;)
El tema del canvi dels mesos és completament diferent. S'han trencat
coses? Sí. Però permeteu-me que deixí el tema de les abreviatures dels
mesos aquí. Portem un munt de missatges i hi ha arguments a favor i en
contra de les abreviatures actuals. Dubto que ens posem d'acord.
Prefereixo gaudir de les vacances de Nadal amb la família, :)
Dit tot això, retorno al meu "mode ràdio" habitual en la llista.
Gràcies a tothom pels comentaris i aportacions.
Bones Festes!
Joan Montané
Re: Format de data incorrecte de «ls -l»
Hola,
feu un cop d'ull a aquestes ordres, la sol.lució fàcil és modificar el
locale ca_ES
Aquestes ordres son part d'un script molt llarg però en resum es fa:
# patch ca_ES locale
sed -i.bak -e '/^ab_alt_mon/,/^[^ ]/ {/"de /s//"/g
/"d/s//"/g }' \
-e '/^abmon/,/^[^ ]/ {/"de /s//"/g
/"d/s//"/g }' \
-e '/\bfebr[.]/s//feb./' \
-e '/\bag[.]/s//ago./' \
"/usr/share/i18n/locales/ca_ES"
update-locales
Salut,
Jordi Pujol
On Sat, Dec 26, 2020 at 9:58 AM Joan Montané wrote:
>
> Missatge de Ernest Adrogué del dia dj., 24 de des.
> 2020 a les 18:29:
> >
> > 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.
>
> Jo participo al CLDR aportant-hi dades, però no vaig demanar aquesta
> funcionalitat. Els camps van aparèixer a la base de dades i els
> col·laboradors els vam anar omplint. Habitualment els col·laboradors
> per al català al CLDR som: un representant d'Apple, un representant de
> Google, un representant de Microsoft i algun participant individual,
> com jo mateix. El pes del vot dels col·laboradors individuals és molt
> més petit que els dels membres d'Unicode. Curiosament, el cas català
> ja apareixia en la documentació [1]. Interpreto que alguna de les
> grans corporacions anteriors (membres de pes a d'Unicode) és qui ho va
> promoure.
>
> [1]
> http://cldr.unicode.org/translation/date-time-1/date-time-patterns#TOC-When-to-use-Standalone-vs.-Formatting
>
> >
> > > 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.
> >
>
> Estic d'acord amb tu en què hi ha feina de corregir problemes, i que
> potser no es va preveure el cas de programes que usen fonts
> monoespaiades i presenten el contingut en format taula. Caldria haver
> fet un repàs més exhaustiu, especialment quan el canvi pot (i de fet
> ho fa) trencar alguna cosa.
>
> La comunitat d'usuaris també podem ajudar-hi. Per exemple, el problema
> de l'ordre "mes dia" del "ls -l" no té res a veure amb el canvi de les
> abreviatures, i portem mínim des de stretch. Han passat 10 anys fins
> que algú s'ho ha mirat amb "carinyo", i això que afecta un munt de
> llengües, no només el català! Sí, ja sé que tots tenim temps limitat,
> però 10 anys ho trobo exagerat.
>
> Ara que he remirat els apunts de quan em vaig mirar el tema de "ls
> -l", hi ha un tema similar, però que té una causa diferent (tampoc
> relacionada amb el canvi en les abreviatures dels mesos). L'ordre
> "date" a buster mostra primer el mes i després el dia del mes. Per
> què? Perquè al locale manca la variable date_fmt [2]. Interpreto que
> en algun moment "date" va passar d'usar "d_t_fmt" a usar "date_fmt",
> la informació no va arribar als mantenidors dels locales i ja tenim el
> problema.
>
>
> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=24054
>
> > > 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
Re: Format de data incorrecte de «ls -l»
Missatge de Ernest Adrogué del dia dj., 24 de des. 2020 a les 18:29: > > 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. Jo participo al CLDR aportant-hi dades, però no vaig demanar aquesta funcionalitat. Els camps van aparèixer a la base de dades i els col·laboradors els vam anar omplint. Habitualment els col·laboradors per al català al CLDR som: un representant d'Apple, un representant de Google, un representant de Microsoft i algun participant individual, com jo mateix. El pes del vot dels col·laboradors individuals és molt més petit que els dels membres d'Unicode. Curiosament, el cas català ja apareixia en la documentació [1]. Interpreto que alguna de les grans corporacions anteriors (membres de pes a d'Unicode) és qui ho va promoure. [1] http://cldr.unicode.org/translation/date-time-1/date-time-patterns#TOC-When-to-use-Standalone-vs.-Formatting > > > 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. > Estic d'acord amb tu en què hi ha feina de corregir problemes, i que potser no es va preveure el cas de programes que usen fonts monoespaiades i presenten el contingut en format taula. Caldria haver fet un repàs més exhaustiu, especialment quan el canvi pot (i de fet ho fa) trencar alguna cosa. La comunitat d'usuaris també podem ajudar-hi. Per exemple, el problema de l'ordre "mes dia" del "ls -l" no té res a veure amb el canvi de les abreviatures, i portem mínim des de stretch. Han passat 10 anys fins que algú s'ho ha mirat amb "carinyo", i això que afecta un munt de llengües, no només el català! Sí, ja sé que tots tenim temps limitat, però 10 anys ho trobo exagerat. Ara que he remirat els apunts de quan em vaig mirar el tema de "ls -l", hi ha un tema similar, però que té una causa diferent (tampoc relacionada amb el canvi en les abreviatures dels mesos). L'ordre "date" a buster mostra primer el mes i després el dia del mes. Per què? Perquè al locale manca la variable date_fmt [2]. Interpreto que en algun moment "date" va passar d'usar "d_t_fmt" a usar "date_fmt", la informació no va arribar als mantenidors dels locales i ja tenim el problema. [2] https://sourceware.org/bugzilla/show_bug.cgi?id=24054 > > 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. > El tema és que les dades del locale no només s'usen des de programes de terminal. S'usen en tot el sistema. Potser m'equivoco, però la tendència és anar cap a interfícies gràfiques amb finestres i botons, i també missatges de veu sintetitzats a partir
