Di certo vi stupirà sapere che lo standard POSIX, e quindi anche Linux, prevede il supporto delle regole nazionali, che vogliono dire set di caratteri, modo di scrivere data, ora, numeri in generale e i messaggi di sistema.
Dalla versione 5.2.18 delle libc, tutta la localizzazione è supportata (diciamo anche la prima, ma con una caterva di bug ;). Visto che usare libc-5.2.18 comporta installare il nuovo kernel, ricompilare e reinstallare tutte le parti vitali (e pericolose) del sistema, per ora calo un velo (pietoso?!) sulla localizzazione completa. Appena saranno disponibili delle nuove distribuzioni con kernel 2.0.x e libc aggiornate, allora se ne potrà riparlare.
Governano la cosa delle variabili d'ambiente. In ordine:
E' 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), andando
a cercare le manpages prima in $MANPATH/$LANG e
poi in $MANPATH.
In pratica, se traducete la manpage di tin(1),
la piazzate in /usr/man/it/man1/tin.1
, settate LANG a
it e date man
, ottenete la manpage in italiano.
Bellissimo, vero?! Dai, allora, cosa aspettate a tradurre le
manpage?!
Influisce sulle regole di parsing di alcune funzioni C, principalmente il sort.
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, il simbolo di valuta.
Sepratore di decimali e migliaia, formattazione dei numeri.
Come stampare data e ora (questo influenza date(1) e programmi vari).
Definisce i valori ``si'' e ``no''.
Definisce come deve essere stampata l'ora corrente.
Come LANG, solo che questa ignora i valori definiti per ogni singola variabile (forza tutto al suo valore).
Per prima cosa l'ottavo bit deve sopravvivere nel kernel, quindi è buona cosa
dare questo comando (anche se stty(1) di default ha queste impostazioni,
controllare con stty -a
):
stty cs8 -istrip -parenb
Inoltre, visto il mio alto senso dello Stato, e vista la fiducia in un roseo
futuro, consiglio di aggiungere questo nel proprio
$(HOME)/.profile
o /etc/profile
per
sh-type shells:
export LANG=it_IT export LC_CTYPE=iso-8859-1
Oppure se avete c-type shells:
setenv LANG it_IT setenv LC_CTYPE iso-8859-1
Il primo serve per scaramanzia (sembra che XFree86 ne tenga conto...), mentre il secondo è una forzatura per evitare problemi.
Come sempre la man page di locale(7) è lettura molto consigliata,
come un giro per /var/X11R6/lib/locale
, che sembra essere l'unica
implementazione di locale oggi funzionante.
Tutti finito, direte voi. Beh, quasi...
Ora il problema è far capire alle applicazioni ``cattive'' che vogliamo avere i caratteri accentati. Questi hanno la interessante proprietà che sono lunghi 8 bit, mentre molti programmi ne considerano solo 7, perché è da 7 bit il codice ASCII internazionalemte riconosciuto.
Se si vogliono usare nomi di files con lettere accentate è bene
aggiungere anche questo nel proprio $(HOME)/.inputrc
set meta-flag on set convert-meta off set output-meta on
Come sempre emacs è molto particolare. Avvisiamolo che vogliamo i caratteri accentati con :
(standard-display-european t) (set-input-mode nil nil 1) (require 'iso-syntax) (load-file "iso-insert.el") (define-key global-map [?\C-.] 8859-1-map)
Aggiunto al nostro bravo $(HOME)/.emacs
Inoltre, se si usa Emacs in un Xterm (NO XEmacs o LEmacs!!!), è anche
necessario aggiungere nel proprio $(HOME)/.XDefaults
:
XTerm*VT100.Translations: #override\n\ Ctrl <KeyPress> . : string("\0308")
Basta editare il file di configurazione /usr/lib/joe/joerc
di modo che
comprenda la riga (con il ``-'' sulla colonna 1):
-asis Characters 128 - 255 shown as-is
Aggiungere le seguenti righe nel file /var/lib/elm/elm.rc
o nel
proprio $(HOME)/.elm/elmrc
:
displaycharset = iso-8859-1 charset = iso-8859-1 textencoding = 8bit compatcharsets = ISO-8859-1 US-ASCII
In particolare l'ultima riga serve a evitare di ricorrere a metamail(1) per ogni messaggio in arrivo.
Aggiungere questo nel proprio $(HOME)/.profile
o
/etc/profile
per sh-type shells:
export MM_CHARSET=iso-8859-1
Oppure se avete c-type shells:
setenv MM_CHARSET=iso-8859-1
Aggiungere la seguente riga nel file /usr/local/lib/pine.conf
o nel
proprio $(HOME)/.pinerc
:
# character-set should reflect the capabilities of the display # you have. Normal default is US-ASCII. Typical alternatives # include ISO-8859-x, where x is a number between 1 and 9. character-set=ISO-8859-1
oppure direttamente da menù di configurazione, seguendo le voci ``Setup'', poi ``Configure'' e infine ``character-set''.
Aggiungere la seguente riga nel file $(HOME)/.nn/init
:
set data-bits 8
Basta aggiungere nel proprio $(HOME)/.telnetrc
la riga:
set binary true
Inizialmente pensavo che X(1) ricavasse i parametri sulla localizzazione
dalle variabili d'ambiente. Invece non è così. Si risolve il problema forzando
i valori, ovvero aggiungendo nei propri $(HOME)/.Xdefaults
o
$(HOME)/.Xresources
i valori:
*basicLocale: it_IT *timeFormat: it_IT *numeric: it_IT *displayLang: iso_8859_1 *inputLang: iso_8859_1
I files con caratteri Latin1 devono poter essere correttamente visualizzati da
ls(1), quindi editiamo il file /etc/DIR_COLORS
e aggiungiamo
alla voce OPTIONS
il valore -N
, di modo che sia:
OPTIONS -N -F -T 0
Aggiungere questo nel proprio $(HOME)/.profile
o
/etc/profile
per sh-type shells:
export LESSCHARSET=latin1
Oppure se avete c-type shells:
setenv LESSCHARSET latin1
Linux permette di cambiare il font standard presente nella ROM della scheda video, in modo da avere il set di caratteri ISO-8859-1 completo a disposizione. La cosa può essere semplicemente ottenuta con :
# carica il set di caratteri Latin1 (ISO-8859-1) setfont /usr/lib/kbd/consolefonts/lat1-16.psf # attiva la mappa di traslazione nulla mapscrn /usr/lib/kbd/consoletrans/trivial # rende attiva la nuova mappa di traslazione echo -ne '\033(K'
Il primo comando carica un nuovo set di caratteri, il secondo permette di eseguire una traslazione ``al volo'' tra caratteri richiesti e voluti e il terzo rende attiva la nuova coppia tabella-tavola di traslazione.
Ad esempio di default non viene caricata nessuna tabella e viene eseguita la traslazione Latin1 (quello che Linux vuole) con CP437 (quello che il PC ha). Ovviamente le manpages di setfont(1) e mapscrn(1) sono utili letture.
Ovviamente, se la propria scheda video supporta modi testo diversi da 80x25, è
anche conveniente caricare un font di dimensione diversa. Si possono
controllare i font e le mappe di traduzione disponibile nelle directory
/usr/lib/kbd/consolefont
e /usr/lib/kbd/consoletrans
.
Questo approccio ha vantaggi e svantaggi, però. Il vantaggio è che si ha il set completo Latin1 in console. Lo svantaggio è dovuto al fatto che molti programmi (mc(1) e dialog(1) in primis) dipendono, per disegnare le belle finestrelle di testo, dalla presenza del set di caratteri CP437. Attivando il set di caratteri Latin1 si ottiene, in pratica, mc con lettere accentate e altre schifezze come bordi delle finestre...
Ma la cosa non è poi così grave. Se non si ha veramente bisogno di tutte le lettere maiuscole accentate e dei caratteri particolari del set Latin1, è abbastanza naturale, per noi in Italia, rimanere con i font di default. Questo perché noi italiani, dei caratteri estesi utilizziamo praticamente solo le lettere accentate minuscole, raramente le lettere accentate maiuscole (perché non ci sono nella tastiera) e di solito comunque solo la ``É'', caratteri comunque presenti nella CP437.
Buona parte dei caratteri installati con X seguono lo standard Latin1, e idem i font PostScript normalmente reperibili (come quelli dell'ATM). Quindi, nessun problema!!!
Se stampate file DVI, PostScript o comunque in grafica, non ci sono problemi. Ci penserà il vostro programma per la stampa a convertire il vostro file nel formato matrice-di-punti più consono alla vostra stampante. Ma se volete stampare in puro testo, senza formattazioni? Resta, soprattutto per le stampanti ad aghi, il metodo più veloce. Ma quanto è standard il set ISO-8859-1?
ISO-8859-1 è il set di caratteri di Unix in generale, di Windows, Amiga, OS/2. Mancano all'appello il DOS e Macintosh. Ma in DOS la CP850 è in pratica il set Latin1, con i caratteri rimescolati un po' per essere compatibile verso il basso con la CP437. Sentitevi liberi quindi da qualsiasi ``sindrome da 8 bit'', e usate tranquillamente questo set di caratteri. Se dovete importare dei testi Linux in Macintosh, semplicemente usate il filtro per ``puro testo Windows'' o cose simili.
Se volete stampare puro testo con le accentate da Linux, a questo punto non vi resta che provare una delle soluzioni seguenti:
recode latin1:cp850 file
dove file
è il file da
convertire, che viene sovrascritto.
Per automatizzare la procedura si può anche installare come filtro
per la stampa.
NLS sta per National Language Support, ovvero il supporto che linux ha per la ``italianizzazione'' dei programmi.
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 catalogs, ovvero dei cataloghi di messaggi in un formato particolare, detto portable object, o più brevemente po, che messi in una determinata directory consentono di essere ``linkati dinamicamente'' nel programma, ovvero usati semplicemente al suo posto.
I problemi qui sono 2:
Il primo problema è praticamente risolto, nel senso che ormai è buona prassi fare i programmi con il supporto NLS.
Il secondo problema richiede una grande collaborazione ma un altrettanto grande sforzo di collaborazione, e inoltre più che riguardare Linux riguarda il mondo GNU in generale. Non c'è da meravigliarsi che ci abbia pensato mamma GNU stessa a creare una mailing list (o meglio, un sito intero dedicato a questo) come supporto tecnico a questo, dobbiamo ammetterlo, immane lavoro.
É possibile accedere a questa mailing list iscrivendosi, con il solito
subscribe it Nome Cognome
nel corpo del messaggio, all'indirizzo
it-request@li.org, ovviamente la
mailing list si chiama
it@li.org. Vi
prego di NON, ripeto NON iniziare nessuna localizzazione senza prima
aver sentito i ``colleghi'' di questa mailing list, il vostro lavoro
potrebbe venir vanificato in un secondo.
Tutto il lavoro svolto fino ad ora è reperibile all'url ftp://alpha.gnu.ai.mit.edu/gnu/po/. In particolare:
ABOUT-NLS
spiega in dettaglio il progetto, che cosa si intende
per NLS, come si installa il supporto per la internazionalizzazione.
conf96-i18n.ps.gz
è il testo della relazione di Ulrich Drepper
all'ultima conferenza della FSF per la presentazione di NLS,
disquisendo sull'implementazione GNU e altre facezie.
gettext-N.M.O.tar.gz
ovvero le beta release del pacchetto gettext
che serve per l'internazionalizzazione. Le versioni ufficiali si
trovano comunque su
ftp://prep.ai.mit.edu/pub/gnu.
maint/PACKAGE/it.po
, ovvero le ultime versioni dei file .po
originali in inglese da cui partire con le traduzioni.
trans/it/PACKAGE-VERSION.po
, ovvero le versioni già tradotte
dei file .po.
Tutto questo materiale e anche altro è disponibile anche all'url ftp://svpop.com.dist.unige.it:/pub/Linux/gnu/po.
Ulteriori informazioni possono essere recuperate nei seguenti testi:
locale-tutorial-0.8.txt.gz
,
versione ``smanettona'' del precedente mini-HOWTO.