i18n (Re: Gdzie jest pakiet gnome-objc30 -przepraszam)

[Marcin 'Qrczak' Kowalczyk]

On Mon, 12 Oct 1998, Tomasz Kłoczko wrote:

> Wogóle przydałaby się jakaś drobna aplikacja, która zmieniałaby globalnie
> domysly język dla wszystkich możliwych zasobach programw jednym ruchem.
> Najlepiej by było żeby poszczególne pakiety rejestrowały takie pliki w
> jakiejś bazie + skrypty do operowania na nich o zunifikowanych parametrach
> jak encoding, LANG czy inne potrzebne, a sam taki program (z frontendem
> lub bez) przelatywał się po wszystkich skryptach wywołując je.

O czymś w tym rodzaju kiedyś mówiłem,
Message-ID: <Pine.LNX.4.03.9809291021420.2855-100000 w qrnik.knm.org.pl>.

Pozwólcie, że trochę pofilozofuję... i zamiast wymyślenia gotowego
rozwiązania, pomacam temat z różnych stron - a nuż ktoś wpadnie na jakiś
fajny pomysł. Przed każdym zdaniem należy dodać `IMHO'.

Tam, gdzie to tylko możliwe, programy powinny dynamicznie reagować na
ustawione locale, zamiast być przekonfigurowywanymi permanentnie - co
jeśli różni użytkownicy zechcą mieć różne języki? To nie takie proste -
nie wystarczy centralne ustawianie - kij ma dwa końce - nie mam zamiaru
przekonfigurowywać całego systemu, żeby np. wydrukować tekst po rosyjsku,
a różni użytkownicy mogą używać różnych języków i już.

Tego niestety na razie nie ma nawet w odniesieniu do fontów ekranowych
i raczej nie będzie, dopóki ustawienie fontu jest wspólne dla całego
systemu (powinno być lokalne względem wirtualnego terminala - mam
nadzieję, że kiedyś będzie).

Jeśli z jakichś powodów nie da się reagować na LC_*, praktycznym zasięgiem
działania danego ustawienia najczęściej jest zalogowanie się danego
użytkownika (który może mieć indywidualne ustawienia, ale jest mała
szansa, że zmienią się w trakcie). Zatem ustawienia powinny być raczej
zapisywane w katalogach domowych. (Swoją drogą, dlaczego to jest zawsze
~juzer/.* zamiast ~juzer/etc/* ?!) Nie zmienia to postulatu, żeby dało się
przerobić wiele programów hurtem - tyle że na poziomie danego użytkownika
- wietnamczyk studiuje na polskiej uczelni, więc wykonuje możliwie mało
ruchów i wszystkie programy, łącznie z doinstalowanymi przez admina
w przyszłości, w miarę możliwości mówią po wietnamsku (łącznie
z fontami!), drukują wietnamskim alfabetem i pozwalają wprowadzać
wietnamskie litery z klawiatury.

Załóżmy więc, że ten centralny konfigurator-internacjonalizator byłby
dostępny dla zwykłego śmiertelnika i ustawiałby indywidualne preferencje
tegoż użytkownika (uch, ale długie słowa mi wyszły!). Ale jak je
technicznie zapisać? Proste przeniesienie pomysłu zacytowanego na początku
spowodowałoby utworzenie kilkunastu plików konfiguracyjnych w jego
katalogu domowym - w których jeśli będziemy mieli szczęście albo ochotę na
przerabianie programów, byłaby zapisana tylko konfiguracja dotycząca
preferencji językowych itp., czyli z dopisaniem się do (a nie zastąpieniem)
ogólnosystemowej konfiguracji danego programu - którą to konfigurację
admin może w każdej chwili zechcieć zmienić, a nie będzie chciał wtedy
grzebać we wszystkich plikach konfiguracyjnych użytkowników ani dodawać
informacji do pokazania po zalogowaniu: "Ścieżka do plików pomocniczych
programu AAA została zmieniona na BBB. Jeśli z niego korzystasz, proszę
zmienić CCC na BBB w pliku ~/.AAArc (rzecz tego gatunku zdarzyła się
właśnie na MIMUWie i byłem świadkiem czyichś kłopotów, które wynikły
z tego, że ssh w przeciwieństwie do telneta nie pokazywał tej informacji).

Różne rodzaje plików konfiguracyjnych plus internacjonalizator zarówno na
poziomie preferencji danego użytkownika, jak i ogólnosystemowym (a co,
admin też chciałby jednym ruchem przekonfigurować cały system!), acz chyba
wygodne i w przypadku wielu programów (niezależnie od spraw językowych)
najsensowniejsze wyjście, robi się niepokojąco rozbudowane - konfigurator
użytkownikowy powinien odpowiednio zareagować zarówno na brak
indywidualnego pliku konfiguracyjnego użytkownika, jak i na dowolnie
namieszaną jego postać po ręcznej edycji, a także skądś muszą się brać
ustawienia nowych programów (jeśli juzer skonfigurował sobie pine, a2ps
i Emacsa do pisania po wietnamsku, to jest duża szansa, że właśnie
zainstalowanego przez admina gimpa też będzie on chciał wykorzystywać do
swoich wietnamskich celów). Dużo plików w katalogach domowych zajmuje
coraz więcej miejsca, a samo się nie kasuje; poza tym nie wszyscy używają
od razu wszystkich programów, więc po co każdy z nich ma od razu zabierać
te 0.5% quoty i czekać na nową wersję danego pakietu, do której
przypadkiem przestanie pasować. Przydałoby się to jakoś lepiej
zorganizować...

Problem tkwi w tym, że różne programy zapisują ustawienia w różnych
miejscach. Umożliwienie zamiany ich hurtem to półśrodek z kilkoma skutkami
ubocznymi. Mimo to ustawienia powinny móc być trwałe, jednak nie powinny
uniemożliwiać chwilowego użycia innych (Polak normalnie ma wszystko
po polsku, ale właśnie chce wysłać pytanie na soc.culture.esperanto,
do czego potrzeba mu sześciu dodatkowych liter). Ustawienie może być
indywidualizowane względem programu albo względem użytkownika; z jednej
strony nie można wykluczyć potrzeby nietypowej konfiguracji jednego
programu u jednego użytkownika, a z drugiej - żeby Linux nie pozostał
do końca systemem "trudnym w konfiguracji" - przydają się ustawienia
domyślne na poziomie użytkownika (dla wszystkich programów) i jedno,
ogólnosystemowe, dla wszystkich programów i użytkowników, dla których
szczegółowa ustawa nie stanowi inaczej.

Ustawienie lokalne względem programu jest łatwiejsze w realizacji,
zwłaszcza że różnych programów dotyczą różne zbiory możliwych ustawień
i w różny sposób się to i nich robi. Za to ustawienia lokalne względem
użytkownika mają większą szansę okazać się wygodnymi w praktyce - o ile
tylko daje się to zrobić (tzn. sens danego ustawienia jest definiowalny
w oderwaniu od konkretnego programu i nie ma problemów technicznych).

Czy musimy więc zmuszać wszystkie programy z osobna do zainteresowania się
plikami ~/.i18n i /etc/i18n? Co z możliwością zrobienia wyjątku dla danego
programu, choćby na jedno uruchomienie? W sumie wychodzi, że pod obydwoma
względami łatwiej jest trzymać tę informację w zmiennej środowiska. Coś to
przypomina... Hura, wymyśliłem koło^H^H^H^Hlocale!

Jakie ustawienia to załatwia? Język, wiadomo. Zestaw znaków - niby też,
można napisać LC_ALL=pl_PL.ISO-8859-2. No ale nie można tego wymagać -
zaraz zaraz, jak wydedukować informację o zestawie znaków, jeśli nie ma
jej jawnie wpisanej? Załóżmy, że się z tym uporamy... Skoro więc i tak
trzeba dostosowywać różne pakiety, to może zamiast wymyślania kwadratowego
koła składającego się z tysiąca nowych części, skorzystamy ze sprawdzonego
pomysłu na locale - trzeba go tylko jeszcze lepiej wykorzystać? Będzie to
pewnie czasem więcej roboty niż dodanie skryptu przekonfigurowującego dany
program, ale na pewno nie więcej niż parsowanie dodatkowych dwóch plików
konfiguracyjnych. Zyskamy łatwą możliwość ustawienia globalnego,
przykrywanego w razie potrzeby przez indywidualne ustawienia użytkownika,
przykrywanych w razie potrzeby przy danym uruchomieniu programu albo danej
sesji.

[ Tutaj przerwa kilku dni w pisaniu - wątek może być nieciągły. ]

To jest trochę złe podejście. Zamiast zwalać robotę na poszczególne
programy i próbować nad tym centralnie panować, należy stworzyć im
łatwe warunki używania różnych zestawów znaków! W tym Unikodu.

glibc przekodowuje zasoby z Unikodu na wybrany zestaw (tylko ośmiobitowy?)
na etapie localedef. Bardzo możliwe, że potem nie ma jak się dostać do
oryginalnego - nawet jeśli program jest przystosowany do Unikodu, jest
ograniczony przez ośmiobitowe zasoby. A może da się jednak tam wcisnąć
UTF-8?

Załóżmy, że piszę program świadomy używanego zestawu znaku, który chciałby
wiedzieć, w czym są zapisane zlokalizowane zasoby. Jak on ma się tego
dowiedzieć? To jest pewna alternatywa względem zasobów w Unikodzie.

Oprócz tego powinno być maksymalnie łatwo programom, które nie zajmują się
zestawami znaków, tak żeby w różnych warunkach (w Xach, na konsoli, na
wydruku) font był zgodny z kodowaniem zasobów i nie było krzaków.

Gdyby wszędzie panował Unikod, byłoby o wiele prościej.

Na pl.comp.os.sys.xwindow jest dyskusja o fontach w Xach i próbach
wymyślenia sposobu na porządek z zestawami znaków.

-- 
 __("<   Marcin Kowalczyk * qrczak w knm.org.pl http://qrczak.home.ml.org/
 \__/       GCS/M d- s+:-- a21 C+++>+++$ UL++>++++$ P+++ L++>++++$ E->++
  ^^                W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP->+ t
QRCZAK                  5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-