[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


Reply to: