Capitolo 8. I18N e L10N

Indice

8.1. La localizzazione
8.1.1. Logica alla base dell'uso della localizzazione UTF-8
8.1.2. La (ri)configurazione della localizzazione
8.1.3. Codifica per i nomi di file
8.1.4. Messaggi localizzati e documentazione tradotta
8.1.5. Effetti della localizzazione
8.2. L'input da tastiera
8.2.1. The keyboard input for Linux console and X Window
8.2.2. The keyboard input for Wayland
8.2.3. Il supporto per metodo di input con IBus
8.2.4. Un esempio per il giapponese
8.3. L'output sul display
8.4. Caratteri dell'Asia dell'est con larghezza ambigua

Il supporto per le lingue native o M17N (Multilingualization) per un software applicativo è ottenuto in 2 passi.

[Suggerimento] Suggerimento

There are 17, 18, or 10 letters between "m" and "n", "i" and "n", or "l" and "n" in multilingualization, internationalization, and localization which correspond to M17N, I18N, and L10N. See Introduction to i18n for details.

The behavior of programs supporting internationalization are configured by the environment variable "$LANG" to support localization. Actual support of locale dependent features by the libc library requires to install locales or locales-all packages. The locales package requires to be initialized properly.

If neither locales or locales-all package are installed, support of locale features are lost and system uses US English messages and handles data as ASCII. This behavior is the same way as "$LANG" is set by "LANG=", "LANG=C", or "LANG=POSIX".

The modern software such as GNOME and KDE are multilingualized. They are internationalized by making them handle UTF-8 data and localized by providing their translated messages through the gettext(1) infrastructure. Translated messages may be provided as separate localization packages.

The current Debian desktop GUI system normally sets the locale under GUI environment as "LANG=xx_YY.UTF-8". Here, "xx" is ISO 639 language codes and "YY" is ISO 3166 country codes. These values are set by the desktop configuration GUI dialogue and change the program behavior. See Sezione 1.5.2, «La variabile "$LANG

The simplest representation of the text data is ASCII which is sufficient for English and uses less than 127 characters (representable with 7 bits).

Anche un testo in semplice inglese può contenere caratteri non ASCII; le virgolette singole ricurve destra e sinistra per esempio non sono disponibili in ASCII.

“double quoted text” is not "double quoted ASCII"
‘single quoted text’ is not 'single quoted ASCII'

In order to support more characters, many character sets and encoding systems have been used to support many languages (see Tabella 11.2, «Elenco dei valori delle codifiche e loro uso»).

Unicode character set can represent practically all characters known to human with 21 bit code point range (i.e., 0 to 10FFFF in hexadecimal notation).

Text encoding system UTF-8 fits Unicode code points into a sensible 8 bit data stream mostly compatible with the ASCII data processing system. This makes UTF-8 the modern preferred choice. UTF stands for Unicode Transformation Format. When ASCII plain text data is converted to UTF-8 one, it has exactly the same content and size as the original ASCII one. So you loose nothing by deploying UTF-8 locale.

Under UTF-8 locale with the compatible application program, you can display and edit any foreign language text data as long as required fonts and input methods are installed and enabled. For example under "LANG=fr_FR.UTF-8" locale, gedit(1) (text editor for the GNOME Desktop) can display and edit Chinese character text data while presenting menus in French.

[Suggerimento] Suggerimento

Both the new standard "en_US.UTF-8" locale and the old standard "C"/"POSIX" locale use the standard US English message, they have subtle differences in sorting order etc. If you want to handle not only ASCII characters but also handle all UTF-8 encoded characters gracefully while maintaining the old "C" local behavior, use the non-standard "C.UTF-8" locale on Debian.

[Nota] Nota

Alcuni programmi usano più memoria dopo l'inclusione del supporto per l'internazionalizzazione. Questo avviene perché il loro codice è programmato per usare internamente UTF-32(UCS4) per supportare Unicode al fine di ottimizzare la velocità e consumano 4 byte per ogni dato di carattere ASCII, indipendentemente dalla localizzazione selezionata. Ancora una volta usando la localizzazione UTF-8 non si perde nulla.

Per lo scambia di dati interpiattaforma (vedere Sezione 10.1.7, «Supporti di archiviazione removibili»), può essere necessario montare alcuni file system con codifiche particolari. Per esempio, mount(8), se usato senza opzioni, assume che venga usata la codifica CP437 per il file system vfat. È necessario fornire esplicitamente opzioni di montaggio per usare nomi di file UTF-8 o CP932.

[Nota] Nota

Quando una chiavetta USB inseribile a caldo viene automaticamente montata in un ambiente desktop moderno come GNOME, si può fornire una informazione di montaggio di questo tipo cliccando con il tasto destro sull'icona del dispositivo sul desktop, cliccare sulla scheda "Drive", cliccare per espandere "Impostazioni" ed inserire "utf8" in "Opzioni di mount:". La prossima volta che questa chiavetta di memoria verrà montata, sarà abilitato il montaggio con UTF-8.

[Nota] Nota

Se si sta facendo l'aggiornamento di un sistema o spostando dischi da un sistema non UTF-8, i nomi di file con caratteri non ASCII potranno essere codificati con codifiche usate una volta e ora deprecate, come ISO-8859-1 o eucJP. Cercare aiuto sugli strumenti di conversione dei testi per convrtirli in UTF-8. Vedere Sezione 11.1, «Strumenti di conversione di dati testuali».

Samba usa in modo predefinito Unicode per i client più moderni (Windows NT, 200x, XP), ma usa CP850 per client più vecchi (DOS e Windows 9x/Me). Questo comportamento predefinito per i client più vecchi può essere modificato usando "dos charset" nel file "/etc/samba/smb.conf", per esempio usando "CP932" per il giapponese.

Esistono le traduzioni di molti dei messaggi di testo e dei documenti che sono mostrati nel sistema Debian, come messaggi di errore, output standard dei programmi, menu e pagine di manuale. L'insieme di strumenti GNU gettext(1) è usato come strumento di backend per la maggior parte delle attività di traduzione.

aptitude(8) fornisce in "Task" → "Localizzazione" un ampio elenco di utili pacchetti binari che aggiungono alle applicazioni messaggi localizzati e che forniscono documentazione nella versione tradotta.

Per esempio, si possono ottenere i messaggi localizzati per le pagine man installando il pacchetto manpages-LINGUA. Per leggere le pagine man di nomeprogramma in italiano contenute in "/usr/share/man/it/", eseguire il comando seguente.

LANG=it_IT.UTF-8 man programname

GNU gettext can accommodate priority list of translation languages with $LANGUAGE environment variable. For example:

 $ export LANGUAGE="pt:pt_BR:es:it:fr"

For more, see info gettext and read the section "The LANGUAGE variable".

La disposizione dell'ordinamento dei caratteri con sort(1) è influenzata dalla lingua scelta dalla localizzazione. Le localizzazioni spagnola e inglese ordinano in modo diverso.

Il formato della data mostrato da ls(1) è influenzato dalla localizzazione. Il formato della data di "LANG=C ls -l" è differente da quello con "LANG=en_US.UTF-8" (vedere Sezione 9.3.4, «Visualizzazione personalizzata di date e orari»).

I caratteri di punteggiatura usati per i numeri sono diversi nelle varie localizzazioni. Per esempio, nella localizzazione inglese mille virgola uno è rappresentato come "1,000.1", mentre nella localizzazione in italiano è mostrato come "1.000,1". Si può vedere questa differenza nei programmi per fogli di calcolo.

Each detail feature of "$LANG" environment variable may be overridden by setting "$LC_*" variables. These environment variables can be overridden again by setting "$LC_ALL" variable. See locale(7) manpage for the details. Unless you have strong reason to create complicated configuration, please stay away from them and use only "$LANG" variable set to one of the UTF-8 locales.

For GNOME on Wayland desktop system, Sezione 8.2.1, «The keyboard input for Linux console and X Window» can't support non-English European languages. IBus was made to support not only Asian languages but also European languages. The package dependency of GNOME Desktop Environment recommends "ibus" via "gnome-shell". The code of "ibus" has been updated to integrate setxkbmap and XKB option functionalities. You need to configure ibus from "GNOME Settings" or "GNOME Tweaks" for the multilingualized keyboard input.

[Nota] Nota

If ibus is active, your classic X keyboard configuration by the setxkbmap may be overridden by ibus even under classic X-based desktop environment. You can disable installed ibus using im-config to set input method to "None". For more, see Debian Wiki on keyboard.

Linux console can only display limited characters. (You need to use special terminal program such as jfbterm(1) to display non-European languages on the non-GUI console.)

GUI environment (Capitolo 7, GUI System) can display any characters in the UTF-8 as long as required fonts are installed and enabled. (The encoding of the original font data is taken care and transparent to the user.)

Nella localizzazione dell'Asia dell'est i caratteri di disegno di riquadri, i caratteri greci e cirillici possono essere visualizzati più larghi della larghezza desiderata e causare un output su terminale non allineato (vedere Unicode Standard Annex #11).

Questo problema può essere aggirato:

  • gnome-terminal: Preferences → Profiles → Profile name → Compatibility → Ambiguous-wide characters → Narrow

  • ncurses: impostare l'ambiente export NCURSES_NO_UTF8_ACS=0.