Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user.catalan > #6515 > unrolled thread

Format de data incorrecte de «ls -l»

Back to article view | Back to linux.debian.user.catalan

Contents

  Format de data incorrecte de «ls -l» Joan Montané <jmontane@gmail.com> - 2020-12-23 19:30 +0100
    Re: Format de data incorrecte de «ls -l» "Josep Ma. Ferrer" <txemaq@gmail.com> - 2020-12-23 21:00 +0100
      Re: Format de data incorrecte de «ls -l» Joan Montané <jmontane@gmail.com> - 2020-12-24 06:50 +0100
        Re: Format de data incorrecte de «ls -l» Joan Montané <jmontane@gmail.com> - 2020-12-24 07:40 +0100
          Re: Format de data incorrecte de «ls -l» Eloi <entfe001@gmail.com> - 2020-12-24 09:10 +0100
            Re: Format de data incorrecte de «ls -l» Joan Montané <jmontane@gmail.com> - 2020-12-24 09:50 +0100
              Re: Format de data incorrecte de «ls -l» Ernest Adrogué <nr9@posteo.de> - 2020-12-24 12:40 +0100
                Re: Format de data incorrecte de «ls -l» Joan Montané <jmontane@gmail.com> - 2020-12-24 13:30 +0100
                  Re: Format de data incorrecte de «ls -l» Ernest Adrogué <nr9@posteo.de> - 2020-12-24 18:30 +0100
                    Re: Format de data incorrecte de «ls -l» Jordi Pujol <jordipujolp@gmail.com> - 2020-12-25 09:50 +0100
                      Re: Format de data incorrecte de «ls -l» Joan Montané <jmontane@gmail.com> - 2020-12-26 10:20 +0100
                        Re: Format de data incorrecte de «ls -l» Jordi Pujol <jordipujolp@gmail.com> - 2020-12-27 15:00 +0100
                          Re: Format de data incorrecte de «ls -l» Joan Montané <joan@montane.cat> - 2020-12-27 16:50 +0100
                            Re: Format de data incorrecte de «ls -l» Jordi Pujol <jordipujolp@gmail.com> - 2020-12-28 17:10 +0100
                    Re: Format de data incorrecte de «ls -l» Joan Montané <jmontane@gmail.com> - 2020-12-26 10:00 +0100
                      Re: Format de data incorrecte de «ls -l» Jordi Pujol <jordipujolp@gmail.com> - 2020-12-26 10:20 +0100

#6515 — Format de data incorrecte de «ls -l»

[Multipart message — attachments visible in raw view] — view raw

Hola,

Arran del correu de l'altre dia de l'automsqlbackup ja vaig indicar
l'enllaç al bug amb la solució, però per si és útil a cap dels presents, us
escric amb detalls com apedaçar Debian (i derivats) perquè no us torneu
bojos en mirar les dates fer un «ls -l». Un petit regal de Nadal, :)


Descripció del problema:
En fer «ls -l» apareix primer la columna del mes i després el dia del mes.
El mes apareix *sense* preposció a scretch i *amb* preposició a buster.

Solució curta:
*Amb permisos de root*, només cal el directori LC_TIME i un enllaç a
coreutils.mo. Això és:

mkdir /usr/share/locale/ca/LC_TIME

ln -s /usr/share/locale/ca/LC_MESSAGES/coreutils.mo
/usr/share/locale/ca/LC_TIME/coreutils.mo

Amb aquestes dues accions, en fer «ls -l» ja hauríeu de tenir primer la
columna del dia, i després la del mes (sense preposició, tant a stretch com
a buster)

Explicació del problema:
Fa 10 anys [1] es va suprimir l'enllaç a coretuils.mo del directori
LC_TIME. Se suposava que no servia de res, i per això se'l van carregar. El
problema és que l'ordre «ls» sí que el necessita. I afecta un munt de
locales, no només al català. Ja està solucionat a sid [2].

Sense aquest enllaç a coreutils.mo, l'ordre «ls -l» usa la cadena original
de l'anglès per al format de data, que  és "%b %e %Y" (mes dia any). A
stretch %b retorna el mes (la glibc no permetia mesos amb preposició), però
a buster, en català, %b retorna mes amb preposició, i el problema encara és
més molest. Però el problema és que usa la cadena original, perquè no
existeix l'enllaç.

Si existeix l'enllaç a coreutils.mo, aleshores «ls -l» usa la cadena de la
traducció. A stretch és "%e %b %Y" (dia mes any) i a buster "%e %Ob %Y"(dia
mes sense preposició any).

En fi, si no voleu esperar a la següent versió de Debian, i us emprenya
tant com a mi el tema del format de data, ja sabeu la solució :)

Bon Nadal i Bon Any Nou!

Joan Montané

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584837
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963513

[toc] | [next] | [standalone]

#6516

El 23/12/20 a les 19:24, Joan Montané ha escrit:
> Hola,
>
> Arran del correu de l'altre dia de l'automsqlbackup ja vaig indicar 
> l'enllaç al bug amb la solució, però per si és útil a cap dels 
> presents, us escric amb detalls com apedaçar Debian (i derivats) 
> perquè no us torneu bojos en mirar les dates fer un «ls -l». Un petit 
> regal de Nadal, :)
>
>
> Descripció del problema:
> En fer «ls -l» apareix primer la columna del mes i després el dia del 
> mes. El mes apareix *sense* preposció a scretch i *amb* preposició a 
> buster.
>
> Solució curta:
> *Amb permisos de root*, només cal el directori LC_TIME i un enllaç a 
> coreutils.mo. Això és:
>
> mkdir /usr/share/locale/ca/LC_TIME
>
> ln -s /usr/share/locale/ca/LC_MESSAGES/coreutils.mo 
> /usr/share/locale/ca/LC_TIME/coreutils.mo
>
> Amb aquestes dues accions, en fer «ls -l» ja hauríeu de tenir primer 
> la columna del dia, i després la del mes (sense preposició, tant a 
> stretch com a buster)
>
> Explicació del problema:
> Fa 10 anys [1] es va suprimir l'enllaç a coretuils.mo del directori 
> LC_TIME. Se suposava que no servia de res, i per això se'l van 
> carregar. El problema és que l'ordre «ls» sí que el necessita. I 
> afecta un munt de locales, no només al català. Ja està solucionat a 
> sid [2].
>
> Sense aquest enllaç a coreutils.mo, l'ordre «ls -l» usa la cadena 
> original de l'anglès per al format de data, que  és "%b %e %Y" (mes 
> dia any). A stretch %b retorna el mes (la glibc no permetia mesos amb 
> preposició), però a buster, en català, %b retorna mes amb preposició, 
> i el problema encara és més molest. Però el problema és que usa la 
> cadena original, perquè no existeix l'enllaç.
>
> Si existeix l'enllaç a coreutils.mo, aleshores «ls -l» usa la cadena 
> de la traducció. A stretch és "%e %b %Y" (dia mes any) i a buster "%e 
> %Ob %Y"(dia mes sense preposició any).
>
> En fi, si no voleu esperar a la següent versió de Debian, i us 
> emprenya tant com a mi el tema del format de data, ja sabeu la solució :)
>
> Bon Nadal i Bon Any Nou!
>
> Joan Montané
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584837 
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584837>
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963513 
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963513>


Moltes gràcies, he aplicat la solució que dius i ara les dates ja es 
formaten correctament.

Però ha aflorat un altre problema: tots els mesos estan abreviats amb 4 
caràcters, excepte febrer (febr.) i agost (ag.), amb 5 i 3 caràcters 
respectivament. Això fa les columnes de l'ordre «ls -l» partir del mes 
desquadrin:

-rw-------  1 usuar usuar 22756 22 abr. 2020 xilerc
-rw-------  1 usuar usuar   343  8 nov.  2019 xillbotsrc
-rw-------  1 usuar usuar   218 21 febr.  2019 xinfocenterrc
-rw-------  1 usuar usuar    60 14 maig  2020 xio_fishrc
-rw-------  1 usuar usuar   128 31 ag.  2019 xiorc
-rw-------  1 usuar usuar    16 24 nov.  2019 xioslaverc

No sé si m'emprenya més que les dates surtin mal formatades o que les 
columnes estiguin desquadrades :)

Bones festes i bon any,

Josep Ma. Ferrer

[toc] | [prev] | [next] | [standalone]

#6517

[Multipart message — attachments visible in raw view] — view raw

Missatge de Josep Ma. Ferrer <txemaq@gmail.com> del dia dc., 23 de des.
2020 a les 20:54:

>
> Però ha aflorat un altre problema: tots els mesos estan abreviats amb 4
> caràcters, excepte febrer (febr.) i agost (ag.), amb 5 i 3 caràcters
> respectivament. Això fa les columnes de l'ordre «ls -l» partir del mes
> desquadrin:
>
>
Tens raó. No me'n recordava.

És un (d)efecte de «ls». Parseja la cadena de format de data per a fer
quadrar les columnes. En concret parseja el primer %b de la cadena, però en
català tenim (a buster) %OB, per això les columnes no quadren.

No té solució senzilla i perfecta. És un problema doble d'i18n, caldria
tocar dues coses en el codi de «ls» perquè ho pogués fer bé per al català.

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.

Les altres opcions requereixen: o molts canvis a «ls», o canviar les
abreviatures dels mesos (afecta a altres programes) o deixar les columnes
desquadrades.

Salutacions,
Joan Montané

[toc] | [prev] | [next] | [standalone]

#6518

Missatge de Joan Montané <jmontane@gmail.com> 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é

[toc] | [prev] | [next] | [standalone]

#6519

El 24/12/20 a les 7:29, Joan Montané ha escrit:
> Missatge de Joan Montané <jmontane@gmail.com> 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'

[toc] | [prev] | [next] | [standalone]

#6520

Missatge de Eloi <entfe001@gmail.com> 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é <jmontane@gmail.com> 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é

[toc] | [prev] | [next] | [standalone]

#6521

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/000095399/basedefs/xbd_chap07.html#tag_07_03

[toc] | [prev] | [next] | [standalone]

#6522

Comento entre paràfrafs,

Missatge de Ernest Adrogué <nr9@posteo.de> 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é

[toc] | [prev] | [next] | [standalone]

#6523

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.

[toc] | [prev] | [next] | [standalone]

#6524

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<U2019>/s//"/g }' \
        -e '/^abmon/,/^[^ ]/ {/"de /s//"/g
        /"d<U2019>/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

[toc] | [prev] | [next] | [standalone]

#6526

Missatge de Jordi Pujol <jordipujolp@gmail.com> 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<U2019>/s//"/g }' \
>         -e '/^abmon/,/^[^ ]/ {/"de /s//"/g
>         /"d<U2019>/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é

[toc] | [prev] | [next] | [standalone]

#6528

Hola Joan i tothom,

On Sat, Dec 26, 2020 at 10:16 AM Joan Montané <jmontane@gmail.com> wrote:
> 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.

Com s'ha de comprovar l'alineament amb el CLDR ?

Em sembla que tenim diferents punts de vista degut a que fem servir
diferents nivells de Debian, els meus sistemes son unstable i aquest
canvi és satisfactori.
Abans "ls -l" posava sempre la preposició "de" i no deixava veure els
noms dels mesos, amb aquest canvi el llistat de directoris amb format
llarg es presenta correctament.

>
> 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
>

aquest canvi que proposes ja s'ha fet al ca_ES de unstable.

> Bones Festes!
Bon nadal i Feliç any nou 1

Jordi Pujol

[toc] | [prev] | [next] | [standalone]

#6529

Missatge de Jordi Pujol <jordipujolp@gmail.com> del dia dg., 27 de
des. 2020 a les 14:57:
>
> Com s'ha de comprovar l'alineament amb el CLDR ?

En el cas que ens ocupa, aquí [1] hi ha les abreviatures dels mesos

[1] https://unicode-org.github.io/cldr-staging/charts/latest/summary/ca.html#360c210ad4f23085

>
> Em sembla que tenim diferents punts de vista degut a que fem servir
> diferents nivells de Debian, els meus sistemes son unstable i aquest
> canvi és satisfactori.

És satisfactori si l'ús principal és terminal, però en escriptori fa
que s'usin abreviatures no estàndards, i en alguns casos no es podrà
escriure la data correctament (amb preposició).

> Abans "ls -l" posava sempre la preposició "de" i no deixava veure els
> noms dels mesos, amb aquest canvi el llistat de directoris amb format
> llarg es presenta correctament.
>

No deixava veure els mesos? Això no hauria de passar mai. «ls -l» no
talla els noms dels mesos. Els noms dels mesos sempre els hauries de
veure. Passa que, a sid,
Si la traducció de «ls» indica %Ob (sense preposició, el que ara
mateix hi ha a la traducció), no apareix la preposició, però «ls» no
enquadra els mesos i es desquadren els mesos d'abril, agost i febrer.
Si la traducció de «ls» indica %b (amb preposició). ls "enquadra" els
mesos i apareix tot en columna

El dubté és si «ls -l» honora la cadena de la traducció o no (això
depèn de l'enllaç que indicava en el primer missatge del fil), però en
qualsevol cas, els mesos sempre s'haurien de veure.

O potser et refereixes que no veies els noms dels mesos en algun altre
programa? Això sí que és important. Hi ha cap programa que talli els
noms dels mesos?

> >
> > Aprofito i amplio la solució per a "date" que he comentat en el correu anterior.
> >
>
> aquest canvi que proposes ja s'ha fet al ca_ES de unstable.

Sí! Com el tema de l'enllaç perquè «ls -l» honori la cadena que indica
el format de data, ja està apedaçat. Tard o d'hora arribarà a stable.

Joan Montané

[toc] | [prev] | [next] | [standalone]

#6530

On Sun, Dec 27, 2020 at 4:25 PM Joan Montané <joan@montane.cat> wrote:
>
> No deixava veure els mesos? Això no hauria de passar mai. «ls -l» no
> talla els noms dels mesos. Els noms dels mesos sempre els hauries de
> veure. Passa que, a sid,
Fa anys passava, ara ho he tornat a provar i ja ho fa bé, per tant en
el meu script he eliminat aquesta part de la modificació i només
queda:

    sed -i.bak -e '/\bfebr[.]/s//feb./' \
        -e '/\bag[.]/s//ago./' \
        "/usr/share/i18n/locales/ca_ES"

Salut,

Jordi Pujol

[toc] | [prev] | [next] | [standalone]

#6525

Missatge de Ernest Adrogué <nr9@posteo.de> 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 de textos generats
programàticament ;) Les abreviatures dels mesos en català estan
estandarditzades, s'usen igual arreu, de veritat a Linux hem de
canviar-les perquè l'ordre «ls -l» quedi com fa 20 anys?

Els programes de terminal cal poder-los usar bé, també en català. «ls»
podria millorar una mica la capacitat d'internacionaltizació,
parsejant internament %Ob, per exemple. O si un equip té un ús
majoritari des de terminal pot tenir apedaçades les abreviatures del
locale català perquè tinguin 4 caràcters.

Altres opcions serien indicar a «ls -l» el mes amb números de 2 xifres
(guanyaríem espai). El format seria "%e/%m". El polonès i el lituà ho
fan així, per exemple.

En el cas concret de mutt m'ho he mirat una mica. Admeto que no
l'havia fet servir mai. mutt no agafa el format de data de l'índex de
missatges de la traducció, això vol dir que d'entrada, totes les
llengües usen el format "mes_abreujat dia". Si les abreviatures de mes
de la llengua en qüestió tenen la mateixa longitud, tot quadra i
s'obté l'aspecte de columnes.
En el nostres cas, doncs, caldria definir un format específic per a
l'índex sempre, abans i ara, La forma de fer-ho és amb la variable
index_format del fitxer .muttrc. Per sort, mutt sí que permet jugar
una mica més que «ls». Amb la línia següent al fitxer .muttrc es veuen
els mesos sense preposició i tot enquadrat en columnes:

set index_format="%4C %Z %-8.8{%e %Ob} %-15.15L (%?l?%4l&%4c?) %s"

En fi, estic segur que el canvi de les abreviatures dels mesos es
podria haver fet millor, però també estic convençut que a llarg
termini és una millora. El sistema de locales mai no arribarà a ser
tan flexible com el CLDR, és obvi, però si al s. XXI ha de ser
possible que generar les dates correctament en català des de GNU
Linux.

Joan Montané

[toc] | [prev] | [next] | [standalone]

#6527

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<U2019>/s//"/g }' \
        -e '/^abmon/,/^[^ ]/ {/"de /s//"/g
        /"d<U2019>/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é <jmontane@gmail.com> wrote:
>
> Missatge de Ernest Adrogué <nr9@posteo.de> 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 de textos generats
> programàticament ;) Les abreviatures dels mesos en català estan
> estandarditzades, s'usen igual arreu, de veritat a Linux hem de
> canviar-les perquè l'ordre «ls -l» quedi com fa 20 anys?
>
> Els programes de terminal cal poder-los usar bé, també en català. «ls»
> podria millorar una mica la capacitat d'internacionaltizació,
> parsejant internament %Ob, per exemple. O si un equip té un ús
> majoritari des de terminal pot tenir apedaçades les abreviatures del
> locale català perquè tinguin 4 caràcters.
>
> Altres opcions serien indicar a «ls -l» el mes amb números de 2 xifres
> (guanyaríem espai). El format seria "%e/%m". El polonès i el lituà ho
> fan així, per exemple.
>
> En el cas concret de mutt m'ho he mirat una mica. Admeto que no
> l'havia fet servir mai. mutt no agafa el format de data de l'índex de
> missatges de la traducció, això vol dir que d'entrada, totes les
> llengües usen el format "mes_abreujat dia". Si les abreviatures de mes
> de la llengua en qüestió tenen la mateixa longitud, tot quadra i
> s'obté l'aspecte de columnes.
> En el nostres cas, doncs, caldria definir un format específic per a
> l'índex sempre, abans i ara, La forma de fer-ho és amb la variable
> index_format del fitxer .muttrc. Per sort, mutt sí que permet jugar
> una mica més que «ls». Amb la línia següent al fitxer .muttrc es veuen
> els mesos sense preposició i tot enquadrat en columnes:
>
> set index_format="%4C %Z %-8.8{%e %Ob} %-15.15L (%?l?%4l&%4c?) %s"
>
> En fi, estic segur que el canvi de les abreviatures dels mesos es
> podria haver fet millor, però també estic convençut que a llarg
> termini és una millora. El sistema de locales mai no arribarà a ser
> tan flexible com el CLDR, és obvi, però si al s. XXI ha de ser
> possible que generar les dates correctament en català des de GNU
> Linux.
>
> Joan Montané
>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user.catalan

csiph-web