Di certo vi stupirà sapere che lo standard POSIX, e quindi anche Linux, prevede il supporto delle regole nazionali per la gestione di set di caratteri, modo di scrivere data, ora, numeri in generale e quindi tutto quello che può (informaticamente parlando) distinguere una paese dall'altro.
Dalla versione 5.2.18 delle GNU libc, tutta la localizzazione è supportata anche da Linux. Ma non basta avere installate delle moderne libc, occorre anche che questa sia stata compilata con determinate opzioni e occorre installare tutta una serie di file e directory che descrivono la ``locale'' Italia. Insomma, compito non facile se la vostra distribuzione non ha già il supporto per la localizzazione...
Per poter influenzare Linux di modo che reagisca secondo la locale scelta, occorre modificare delle variabili d'ambiente. In ordine:
È la variabile ``generale'' del gruppo, serve a definire una regola generale (il paese) con cui poi assegnare le variabili che vengono sotto. Una definizione delle variabili sottostanti annulla però quella di default definita da LANG. Inoltre LANG influenza anche il programma man(1), ci torneremo poi.
Influisce sulle regole di ordinamento alfabetico.
Definisce il set di caratteri usato dal sistema.
Definisce come devono essere scritte le valute, ovvero quale, tra virgola e punto, è il separatore di decimali e migliaia e viceversa; definisce inoltre il simbolo di valuta.
Separatore di decimali e migliaia, formattazione dei numeri.
Definisce i valori ``si'' e ``no''.
Come stampare data e ora (questo influenza date(1) e programmi vari).
Come LANG, solo che questa ignora i valori definiti per ogni singola variabile (forza tutto al suo valore). Come spiegherò in seguito, questa variabile non va usata a meno di non sapere perfettamente quello che si sta facendo.
Piú semplicemente di quello che si crede, basta mettere nel proprio
~/.profile o /etc/profile per
sh-type shells:
export LANG=it_IT
Oppure se avete c-type shells:
setenv LANG it_IT
Perché ``it_IT''?! È solo una convenzione, e il significato è ``lingua_PAESE''. Per fare un esempio potrebbe essere it_CH (Svizzera italiana).
Come sempre la man page di locale(7) è lettura molto consigliata,
come un giro per /usr/share/locale per vedere le locali disponibili.
Solitamente si manifestano con errate definizioni degli alias di locale, quindi definizioni che dovrebbero essere equivalenti danno risultati completamente diversi; per rimediare a questo occorre prelevare le definizioni di locale aggiornate, o installarle (molte distribuzioni non le installano proprio).
Può anche essere che alcune distribuzioni non abbiano proprio il supporto per la locale, al che conviene cambiare distribuzione (l'alternativa è ricompilare a mano la libreria di sistema libc).
Anche qui, come per il problema BS/DEL, se qualcosa non funziona è colpa, quasi certamente, della applicazione.
C'è qui una specie di ``caverna degli orrori''... ;)))
Netscape, se vengono definite le variabili LC_NUMERIC e LC_MONETARY, si mette a stampare e salvare PostScript con punti al posto delle virgole e viceversa, con il risultato che qualsiasi interprete PostScript e in particolare gs(1) vanno in palla...
Se capita, ricontrollate la vostra definizione di locale, e se avete fretta di stampare basta che definiate le variabili seguenti:
LC_NUMERIC=posix
LC_MONETARY=posix
che forzano i valori di default (e permettono di stampare).
Notare che se si è definita LC_ALL, queste due righe qui sopra vengono ignorate: per questo è bene NON definire la variabile LC_ALL.
È probabile che questo problema non sia solo di Netscape: se vi capita un problema simile, sapete ora come ``mettere una pezza'', ma avvisate l'autore del programma in questione della presenza di questo bug.
Spesso perl(1) si lamenta della mancanza della locale; questo è dovuto sia a una non completa implementazione da parte della distribuzione, sia in parte a perl stesso che non riesce a gestire gli alias delle varie locali, e quindi riesce a ``seguire'' la variabile LANG solo se punta a una locale con una reale directory sul disco.
Io sulla mia Debian non sono riuscito a riprodurre il problema (se non settando LANG a una locale inesistente ;) e quindi sospetto che tutto nasca da una difficile interazione tra localizzazione e perl stesso, che verrà risolta sicuramente dalle prossime versioni di perl.
RedHat 5.0 soffre di questo problema, che è stato corretto nella 5.1.
Resta il problema di far capire alle applicazioni ``cattive'' che vogliamo avere i caratteri accentati. Questi hanno l'interessante proprietà di essere lunghi 8 bit, mentre molti programmi ne considerano solo 7, perché è da 7 bit il codice ASCII internazionalmente riconosciuto.
Queste note che scrivo dovrebbero presto finire in soffitta, visto che ormai le applicazioni che non gestiscono bene gli 8 bit o che non sano reagire alla variabile LANG sono in via di estinzione.
Come sempre emacs è molto particolare. Avvisiamolo che vogliamo i caratteri accentati con :
(standard-display-european t)
(set-input-mode (car(current-input-mode))
(nth 1 (current-input-mode)) 0)
Aggiunto al nostro bravo ~/.emacs.
Emacs 20 include MULE, il supporto per l'internazionalizzazione;
è quindi sufficiente mettere questo nel proprio ~/.emacs
(o, per i SysAdmin che usano Debian e vogliono una configurazione
site-wide, in /etc/emacs/site-start.el) per avere lettere
accentate (e molto di più :-) e dirgli che siamo in Europa Occidentale:
(setq-default enable-multibyte-characters t)
(set-language-environment 'Latin-1)
A qualcuno potrebbe far piacere aggiungere questo:
(load "iso-transl")
che consente di inserire le lettere accentate (non solo italiane) digitando ``[Ctrl+x] [8] <ACCENTO> <LETTERA>'', tipo ``[Ctrl+x] [8] ["] [A]'' (grazie a Davide G. M. Salvetti).
Basta editare il file di configurazione /etc/joe/joerc o nel proprio
~/.joerc di modo che comprenda la riga (con il ``-''
sulla colonna 1):
-asis Characters 128 - 255 shown as-is
Basta scegliere il set di caratteri ISO-8859-1 dal menu di configurazione, seguendo le voci ``Setup'', poi ``Configure'' e infine ``character-set''; questo fa uscire le mail in codifica ``quoted-printable'' se contengono caratteri accentati (il che è bene ;).
Tin è perfettamente localizzato, occorre solo scegliere il charset ISO-8859-1 per la visualizzazione nel menú di configurazione (attraverso [M]).
Aggiungere la seguente riga nel file ~/.nn/init:
set data-bits 8
Readline, che è una libreria standard GNU per la gestione dell'input, nonostante sia giovane, pimpante e ben mantenuta, non arriva per definizione con il supporto per i caratteri accentati. Questa libreria è usata dalla shell di default di linux bash(1), per citare una applicazione di larghissimo uso. Non è da considerare un bug (questo comportamento forse è voluto per garantire il funzionamento anche sui vecchi terminali a 7 bit...) ma è chiaro che l'uso dei caratteri accentati deve essere forzato, ad esempio, se si vogliono usare nomi di file con lettere accentate.
Per fortuna basta solo aggiungere nel proprio ~/.inputrc
set meta-flag on
set convert-meta off
set output-meta on
Le manpage sono quelle pagine testuali che si richiamano con il comando man(1), e che rappresentano la documentazione online di ogni buon sistema UNIX, non solo di Linux.
Il comando man è abbastanza intelligente da reagire se è definita la variabile LANG. In pratica man va a cercare le manpages prima in $MANPATH/$LANG e poi in $MANPATH se configurato correttamente, permettendo di leggere le pagine nella lingua preferita.
Chiaramente c'è già chi sta traducendo le pagine; se vi sentite dei traduttori nati non vi resta che saltare al progetto ILDP per saperne di piú e collaborare.
Le pagine già tradotte possono essere tranquillamente installate manualmente, prelevando l'ultima versione da ftp://ftp.pluto.linux.it/pub/pluto/ildp/man e leggendo attentamente le istruzioni allegate. Gli utenti Debian possono trovare nella loro distribuzione il pacchetto manpages-it già pronto.
Oltre tutto questo, c'è una terza e importantissima funzione della NLS: i messaggi dei programmi nella lingua locale.
Per farsi un'idea, agli utenti Linux non tocca editare i sorgenti di un programma, modificare a mano tutte le stringhe e poi ricompilare perché questo si presenti in corretto italiano. Esiste una ``prassi'' di programmazione che permette di specificare un linguaggio di default ``compilato'' nell'eseguibile (di solito inglese, per compatibilità) e invece definire delle catalog, ovvero dei cataloghi di messaggi in un formato particolare, detto portable object, o più brevemente po, che messi in una determinata directory vengono usati semplicemente al posto dei messaggi presenti nel programma.
Non c'è da meravigliarsi che ci abbia pensato mamma GNU stessa a creare una organizzazione nonprofit, Linux International appunto, dedicata a questo, dobbiamo ammetterlo, immane lavoro di traduzione e aggiornamento.
In particolare in questo sito vengono messe a disposizione della comunità UNIX internazionale una serie di liste in cui poter coordinarsi per la traduzione, una per ogni paese piú una serie di liste generiche di ``intracoordinamento''.
Visto che tradurre i messaggi (catalogues) e tradurre manpage e HOWTO sono compiti molto simili, per non creare fastidiose sovrapposizioni i compiti sono stati divisi tra due ambiti. Linux International in cui si definiscono le regole generali di traduzione e si traducono catalogues e programmi GNU ``ufficiali'', e ILDP che invece è piú legata al mondo Linux e maggiormente dedicata alla traduzione di documentazione (HOWTO e manpage) e anche alla sua produzione direttamente in Italiano.
Piú avanti elenco le liste a cui ti puoi iscrivere per collaborare, oppure puoi dare una occhiata all'HOWTO messo a punto dal responsabile del team di traduzione italiano, Marco d'Itri, all'URL http://www.linux.it/~md/IT-NLS-HOWTO.
Ti prego di NON, ripeto NON iniziare nessuna localizzazione senza prima aver sentito i ``colleghi'' di queste mailing list, il tuo lavoro potrebbe venir vanificato in un secondo per un banale doppione.
Ulteriori informazioni possono essere recuperate nei seguenti testi:
locale-tutorial-0.8.txt.gz.