Jeśli jesteś właścicielem tej strony, możesz wyłączyć reklamę poniżej zmieniając pakiet na PRO lub VIP w panelu naszego hostingu już od 4zł!

Str. główna i mapa serwisu

Dostosowanie programu M2 – klienta poczty i news Opery 8.x do prawidłowej obsługi polskich liter oraz do pracy wielojęzycznej

Wsparcie producenta dla wersji 8.x zakończyło się. Najwyższa wypuszczona wersja tej generacji to 8.54. Bardzo zalecana jest aktualizacja do aktualnej wersji.

M2 ma niezwykle ograniczone możliwości konfiguracyjne. Jedynie można wybrać dla każdego z kont poczty i news podpis i domyślne kodowanie (można dla każdego konta również zmienić wrotkę, ale wymaga to edycji pliku accounts.ini, o czym niżej). Zmienne podpisy można wstawiać ręcznie z notatek – patrz niżej. M2 bardzo dobrze sprawuje się w środowisku językowym używającym jednego kodowania, gdy listy, na które się odpowiada, są poprawne technicznie, ale w przypadku pracy wielojęzycznej konieczna jest każdorazowa ręczna zmiana charsetu na właściwy (o ile tym właściwym nie jest UTF-8).

W planach podobno jest możliwość łatwego przełączania konta, z jakiego dany list ma być wysłany, co umożliwi łatwą (choć nadal ręczną) zmianę wrotki, podpisu i domyślnego kodowania. Na razie ta funkcjonalność nie została zaimplementowana.

Niektóre zmiany opcji obejmują edycję pliku accounts.ini. Zmiany w tym pliku mogą być dokonywane tylko po zamknięciu wszystkich okien Opery. Przed grzebaniem w pliku accounts.ini zalecam zrobienie kopii zapasowej!

Spis treści:

  1. Zmiana języka interfejsu
  2. Kodowanie:
    1. Ustawienia charsetu – czyli jak ustawić ISO-8859-2,
    2. Problemy z odpowiadaniem na listy bez deklaracji charsetu – czyli co zrobić z niepoprawnymi technicznie postami z nieskonfigurowanych OE, masowo zaśmiecającymi polskie grupy dyskusyjne,
    3. Ustawienie kodowania transportowego – czyli jak ustawić wysyłanie treści w Quoted-Printable, a jak w 8-bit,
  3. Tekst wprowadzający, czyli wrotka,
  4. Podpis,
  5. Dodatek: Sprawdzanie pisowni w różnych językach,
  6. Dodatek: Niedogodności programu mające wpływ na obsługę znaków narodowych w czytanych i wysyłanych listach, ale nie będące bugami,
  7. Dodatek: Wyświetlenie dowolnego pola nagłówka czytanego listu,
  8. Gdzie i kiedy nie używać polskich liter (ani innych znaków narodowych lub specjalnych),
  9. Linki.

Taki znaczek: strona zewnętrzna przy odsyłaczu oznacza, że odsyłacz prowadzi do strony zewnętrznej.
A taki znaczek: link prowadzi do podstrony – że odsyłacz prowadzi do innej strony w tym serwisie.

1. Zmiana języka interfejsu

Istnieje możliwość zmiany języka interfejsu na polski. W tym celu należy ściągnąć ze strony www.opera.com/download/languagefiles/ strona zewnętrzna polski plik językowy właściwy dla używanej wersji Opery i umieścić go np. w katalogu, w którym jest zainstalowana Opera (tam już będzie plik językowy o rozszerzeniu .lng). Można go umieścić w dowolnym miejscu, choć zwykle warto utrzymywać porządek. Należy też zapamiętać i miejsce, i nazwę pliku. Następnie należy otworzyć okno preferencji (Tools ⇒ Preferences…, skrót klawiszowy Alt+P), i na zakładce General kliknąć na przycisk „Details…”:

W nowo otwartym oknie w polu na górze wpisuje się ścieżkę i nazwę pliku (np. w przypadku wersji 8.54 i typowej instalacji pod Windowsem c:\program files\opera\ouw854_pl.lng):

Po kliknięciu na OK nastąpi natychmiastowa zmiana języka menu i podpisów pod standardowymi przyciskami, nie trzeba restartować przeglądarki. Jedynie przyciski pozycje menu dodane przez użytkownika pozostaną nieprzetłumaczone. Oryginalny język interfejsu przywraca się analogicznie.

2. Kodowanie

2.1 Ustawienia charsetu

Jedyną umiejętnością M2 w zakresie doboru charsetu jest zaproponowanie wysłania w UTF-8. W przeciwieństwie do wielu innych programów nie ma żadnej możliwości automatycznego doboru 8-bitowego charsetu w zależności od treści. Jedynie można mieć osobne konta pocztowe do korespondencji w różnych językach, dla których ustawione zostaną różne, odpowiednie charsety w zależności od języka. Dla kont używanych do korespondencji w języku polskim w prawie każdej sytuacji odpowiednie będzie kodowanie ISO-8859-2:

Gdy cytowany list zawiera znaki spoza tego kodowania, przy odpowiadaniu bez powiadamiania użytkownika wybierze kodowanie UTF-8. Gdy cytowany list nie zawiera takich znaków (w tym gdy zawiera tylko znaki US-ASCII), M2 wyśle w kodowaniu domyślnym ustawionym dla danego konta. Zachowanie to jest niezależne od kodowania listu, na który się odpowiada. Jeżeli więc z jakichś powodów nie chcemy lub nie możemy wysyłać wszystkiego w UTF-8, pozostaje niestety pamiętanie za każdym razem o tym, by ręcznie wybierać odpowiednie kodowanie 8-bitowe. Patrz też dyskusja na temat doboru kodowania 8-bitowego w zależności od używanego języka lub języków link prowadzi do podstrony.

2.2 Problemy z odpowiadaniem na listy bez deklaracji charsetu

Problemem jest to, że M2 nie ma dobrze działającego ustawienia domyślnego kodowania znaków spoza US-ASCII w listach nie zawierających deklaracji kodowania i przy odpowiadaniu uznaje je, że należą one do zbioru znaków ISO-8859-1. Zachowanie to, choć uciążliwe w polskich warunkach i nieuzasadnione (czemu akurat ISO-8859-1, a nie jakieś inne?), nie jest nieprawidłowe. Wynika to wprost z RFC 2046, p. 4.1.2, gdzie jest powiedziane, iż brak deklaracji charsetu jest równoznaczny z deklaracją US-ASCII – a więc czytnik ma prawo być tą sytuacją zmylony (wbrew deklaracji w treści są znaki spoza US-ASCII) i zachować się nieprzewidywalnie lub nieoptymalnie. Jedynie gdy zaznaczy się przed odpowiadaniem fragment (lub całość) listu, na który się odpowiada, M2 zastosuje do zaznaczonego fragmentu ustawione domyślne kodowanie, o ile będzie to możliwe. Innym, równie dobrym rozwiązaniem, jest zmiana kodowania z automatycznego na ISO-8859-2 (lub odpowiednio innego) w menu Widok ⇒ Kodowanie. Pewnym problemem jest to, że (używając standardowych ustawień) przed odpowiadaniem nie wiadomo, że odpowiada się na nieprawidłowy technicznie list. Aby to zmienić, należy dodać do listy wyświetlanych nagłówków jeden ze standardowych nagłówków – ten, który normalnie zawiera deklarację charsetu.

Istnieje możliwość dodania dowolnego nagłówka do wyświetlanych w oknie podglądu. Brak wyświetlenia tego nagłówka oznacza, że mamy potencjalnie do czynienia z listem wadliwym technicznie. Aby dodać wyświetlanie zawartości nagłówka Content-Type: (w którym znajduje się również deklaracja charsetu dla danego listu), w pliku mime.css należy dodać np. na końcu listy (lub w dowolnym miejscu, ma to wpływ na kolejność wyświetlania nagłówków) podobnie wyglądających wpisów linię
omf|hdr[name="content-type"] {display:table-row;}
(w powyższej linii między nawiasem kwadratowym a klamrowym jest tabulator). Oto efekt:

Czerwona strzałka pokazuje wyświetloną zawartość nagłówka Content-type:. Gdy nie ma tej linii w liście, na który odpowiadamy, linia ta nie zostanie wcale wyświetlona. Dzięki temu już zawczasu będziemy poinformowani o tym, że należy uważać przy odpowiadaniu.

Tą metodą można dodać wyświetlanie dowolnego pola nagłówka, postępuje się analogicznie zastępując content-type nazwą żądanego pola nagłówka.

Należy pamiętać, że każda instalacja Opery (nowej wersji lub reinstalacja) nadpisuje pliki css – po instalacji trzeba niestety ponownie wprowadzać zmiany.

Znacznym ułatwieniem życia są przyciski szybkiej zmiany kodowania. Na stronie Opera wiki – Przyciski link do str. zewnętrznej można znaleźć kilka przycisków zmieniających jednym kliknięciem kodowanie. Instalacja przycisków jest niewiarygodnie prosta – wystarczy przeciągnąć myszą żądany przycisk na wybrany pasek narzędziowy, w dowolne miejsce, i po upuszczeniu przycisku jedynie kliknąć Tak w oknie dialogowym proszącym o potwierdzenie dodania przycisku. Przyciski po instalacji będą wyglądały inaczej (będą mniejsze i będą dostosowane do wyglądu Opery. Dla wygody zamieszczam dwa przyciski z tej strony:

Uwaga: klikanie na przyciski w innych przeglądarkach nie tylko nie ma sensu, ale może mieć nieprzewidywalne następstwa!

kodowanie   ▼ – rozwijane menu kodowania na dowolnym pasku,

Auto / ISO-8859-2 – przełączanie między automatycznym wyborem kodowania a kodowaniem ISO-8859-2, najczęściej spotykanym w polskim usenecie.

Na podstawie informacji z tej strony opracowałem kilka przycisków, które mam nadzieję będą użyteczne. Oto one:

Auto / ISO / CP / UTF   ▼ – przełączanie kolejnymi kliknięciami między automatycznym wyborem kodowania, kodowaniem ISO-8859-2, kodowaniem CP-1250, kodowaniem UTF-8 i z powrotem automatycznym wyborem kodowania, plus rozwijalne menu wyboru kodowania. Aktualnie używane kodowanie pokazane jest jako podpis pod przyciskiem. Raczej jedyne kodowania polskich liter spotykane u opslukowców,

Auto    ISO-8859-2   CP-1250   UTF-8  – cztery przyciski, z których każdy ustawia po prostu dane kodowanie. Najprostsza obsługa, jaką można sobie wyobrazić (jedno kliknięcie), okupiona zużyciem miejsca na pasku narzędziowym.

Inne ułatwienie to dodanie do okien kompozycji listy kodowania, na której wyświetli się kodowanie wybrane przez M2 dla pisanego listu:


Dzięki temu będzie widać, w jakim kodowaniu wysłany będzie dany list.

Gdy z jakichś powodów używane kodowanie nam nie odpowiada, możemy je tam przestawić. W przypadku gdy treść będzie zawierała znaki spoza tego kodowania (w tym na przykład polskie znaki, które M2 przez brak deklaracji charsetu uznała za znaki z ISO-8859-1), pojawi się komunikat o niemożności wysłania listu w wybranym kodowaniu:

Normalnie należy wybrać pierwszą opcję (Tak – czyli Wyślij w UTF-8) lub ostatnią (Anuluj [wysyłanie] i albo z treści usunąć znaki spoza charsetu, albo wybrać inny charset), ale przy odpowiadaniu na list bez deklaracji charsetu można jak najbardziej wybrać opcję środkową, czyli Nie – znaczącą Wyślij w wybranym kodowaniu, a znaki spoza charsetu zamień na znaki zapytania.

Dodam tutaj, że mimo dopuszczenia unikodu (w transformacji UTF-8) jako równorzędnego z ISO-8859-2 na grupach hierarchii pl.* (patrz posty: qvdjwrm4esfu.dlg@falcon.sloth.hell.pl link do str. zewnętrznejdlptqd$csg$1@news.pse.pl link do str. zewnętrznej, oraz wcześniejsze: wątek cmrv87$ltf$3@debi.pekin.net.pl link do str. zewnętrznej, podwątek zaczynający się od 3dT2dac3kIpn6N34%chopin@akson.sgh.waw.pl link do str. zewnętrznej i post 5kT2kao5eI1s9N34.chopin@akson.sgh.waw.pl link do str. zewnętrznej) zaleca się stosować zasadę używania najwęższego możliwego charsetu, co oznacza, że nie należy słać w UTF-8 postów, które nie zawierają znaków spoza ISO-8859-2. Zgodnie z RFC2046 link do str. zewnętrznej p. 4.1.2 (ostatni akapit) i z opinią wyrażoną w poście qvdjwrm4esfu.dlg@falcon.sloth.hell.pl link do str. zewnętrznej

[...] należy się stosować do zasady najmniejszego
niezbędnego charsetu - pisząc czysto po angielsku należy używać US-ASCII,
pisząc po polsku (czesku, słowacku itd.) - 8859-2, pisząc w języku nie
mającym odpowiedniego ISO 8859-N (albo naraz w kilku językach używających
różnych N) należy używać UTF-8.

Ostatnią możliwością jest użycie konwertera MIME-Proxy link prowadzi do podstrony – każdy list bez deklaracji charsetu przechodzący przez MIME-Proxy będzie miał dodaną deklarację, którą można ustawic w opcjach. Rozwiazanie to jest o tyle niedogodne, że list bez deklaracji może byc w kodowaniu innym niż np. ISO-8859-2 i nie ma możliwości zmiany kodowania dla tego listu po stronie klienta M2, konieczna jest zmiana kodowania domyślnego w opcjach MIME-Proxy i następnie ponowne ściągnięcie danego listu.

Opisane powyżej ustawienia najbardziej zbliżają M2 do zgodności z tym warunkiem, niestety w dalszym ciągu konieczna będzie ingerencja użytkownika – wydaje się, że z czysto technicznego punktu widzenia oraz ze względu na netykietę i reguły hierarchii pl.* usenetu lepiej by było, gdyby krzaki pochodzące ze źle skonfigurowanego OE były zastępowane znakami zapytania, a nie wysyłane tak, jakby były znakami z ISO-8859-1 (co wymusza użycie UTF-8), gdyż nie istnieje żadne uzasadnienie, by kodowanie ISO-8859-1 miało być domyślne dla wszystkich języków świata. Z drugiej strony takie rozwiązanie jest nieczytelne (łatwiej jest odcyfrować, jaka polska litera miała być w miejscu krzaka, niż w miejscu znaku zapytania – patrz tablica ilustrująca m.in. krzakowe odpowiedniki polskich liter link prowadzi do podstrony). Oczywiście najlepiej by było, gdyby M2 przy odpowiadaniu używał ustawionego domyślnego kodowania, a nie zakładał ISO-8859-1, choć jak wspomniałem nie jest to zachowanie nieprawidłowe technicznie. Należy zwracać uwagę na obecność lub brak deklaracji charsetu, naciskać na Operę, by zrezygnowała z bzdurnego i niczym nie uzasadnionego faworyzowania ISO-8859-1, zaś opslukowców psujących polskie litery przez brak deklaracji charsetu należy odsyłać na jedną ze stron ilustrujących prawidłową konfigurację, opornych i niereformowalnych opslukowców zwalczać. Poza tym M2 nie potrafi automatycznie dobrać najmniejszego wymaganego charsetu – o ile odpowiadając na list kodowany UTF-8 i zawierający tylko znaki z ISO-8859-2 zostanie wysłany w ISO (przy powyższych ustawieniach), to przy odpowiadaniu na list zawierający znaki spoza ISO-8859-2 list dalej będzie wysłany w UTF-8 nawet po usunięciu tych znaków z treści, o ile użytkownik sam nie przestawi kodowania. Tak samo jest z listami nie zawierającymi znaków spoza US-ASCII – M2 wyśle w kodowaniu domyślnym, a nie w US-ASCII. Należy zdawać sobie sprawę z ograniczeń tego programu i niestety czasem ręcznie przestawić kodowanie.

Ostatnie możliwe rozwiązanie jest wylewaniem dziecka z kąpielą, gdyż o ile zapobiegnie wysyłaniu krzaków w UTF-8 (zastępując znaki spoza ISO-8859-2 w cytowanym tekście przez znaki zapytania – w tym polskie znaki zepsute w wyniku braku deklaracji charsetu w oryginalnym poście), to zepsuje znaki prawidłowo zakodowane w UTF-8 (przypominam – dopuszczonego do używania w hierarchii pl.*). Sposób ten polega na zmianie w pliku accounts.ini jednego wpisu, dzięki czemu M2 będzie wymuszał dla odpowiedzi kodowanie ISO-8859-2 (czy inne ustawione jako domyślne). Ta linia to
Force Charset=0
Zmiana 0 na 1 da opisywany efekt.

Zgodnie z moją wiedzą nie istnieje niestety żadne pełne rozwiązanie problemu krzaków w odpowiedziach na posty ze źle skonfigurowanego OE.

2.3 Ustawienie kodowania transportowego

Ustawienia kodowania transportowego możliwe są wyłącznie przez edycję pliku accounts.ini. Domyślnie przy wysyłaniu listów zawierających znaki spoza US-ASCII M2 używa kodowania Quoted-Printable dla nagłówków (Temat, Nadawca, Organizacja, X-nagłówki) i 8-bit dla treści. Jest to zachowanie jak najbardziej standardowe i prawidłowe, taka forma wysyłania treści jest też zalecana na grupach dyskusyjnych hierarchii pl.*. Jeżeli z jakichś powodów chcesz użyć również kodowania Quoted-Printable dla treści, to musisz dla danego konta zmienić wpis w linii
Allow 8Bit Transfer=1
z 1 na 0. Nie pomyl się i nie zmieniaj linii
Allow 8Bit Headers=0
- zmiana tej linii spowoduje, że M2 zacznie wysyłać w nagłówkach znaki w postaci 8-bit, co jest niedopuszczalne technicznie (patrz RFC 2822 link do str. zewnętrznej p. 2.2) i spowoduje, że inni będą widzieli krzaki (może z wyjątkiem użytkowników OE).

(wyżej wymienione posty zostały napisane przez administratorów najważniejszych serwerów news w Polsce). Pamiętaj, że użycie kodowania Quoted-Printable dla treści, choć całkowicie poprawne technicznie i akceptowane, nie jest zalecane z uwagi na brak obsługi tego kodowania przez niektóre czytniki (jest ich coraz mniej w użyciu) i błędy w jego obsłudze przez OE (w odpowiedzi na tekst kodowany Quoted-Printable OE nie wstawia znaków cytowania przed cytowanymi liniami). W hierarchii pl.* oficjalnie zaleca się użycie kodowania 8-bit, choć stosowanie Quoted-Printable nie jest zakazane (patrz oficjalne stanowisko właściciela hierarchii link do str. zewnętrznej).

3. Wrotka

Nie ma żadnej możliwości przełączania wrotek – można jedynie przygotować wrotkę uniwersalną, zrozumiałą we wszystkich językach używanych w korespondencji z danego konta. Należy znaleźć plik accounts.ini, a w nim sekcję [AccountX], gdzie X oznacza numer konta. Na podstawie wpisów należy się zorientować, o które konto nam chodzi. W przypadku konta pocztowego w danej sekcji znajdujemy dwie linie, zaczynające się od:
Reply=
Forward=
(pierwsza odpowiada za wrotkę przy odpowiedzi, a druga przy przesyłaniu w załączeniu). W przypadku konta news w danej sekcji znajdujemy trzy linie zaczynające się od:
Reply=
Followup=
Forward=

(pierwsza odpowiada za wrotkę, gdy komuś odpowiadamy na priva, druga – gdy odpowiadamy na grupę, a trzecia – gdy przesyłamy post w załączeniu).
W liniach tych możemy wpisać dowolny tekst używając zmiennych symbolicznych:
%f – nadawca (from) listu, na który odpowiadamy – imię i nazwisko lub ksywka oraz adres e-mail,
%n – nadawca (from) listu, bez adresu e-mail,
%e – sam adres e-mail nadawcy (from) listu,
Można też użyć zmiennych odnoszących się do konkretnych nagłówków. Najczęściej spotykane to:
%:From: – nadawca listu, na który odpowiadamy (to samo, co %f powyżej),
%:Date: – data listu, na który odpowiadamy,
%:Subject: – temat,
%:Message-Id: – M-ID (identyfikator wiadomości),
%:Newsgroups: – grupa dyskusyjna,
%:Organization: – organizacja, jaką reprezentuje osoba, której odpowiadamy,
%:To: – adresat wiadomości, na którą odpowiadamy,
%:Cc: – lista innych odbiorców (CC – czyli Do Wiadomości),
\n – oznacza miejsce złamania wiersza (nowa linia).
Należy pamiętać, by polskie litery (i inne znaki spoza US-ASCII) były zakodowane w UTF-8.
Na przykład zalecana linia konfigurująca linie wprowadzające dla forwardu na prhn zgodnie z FAQ grupy będzie wyglądać następująco:
Forward=From: %:From:\nSubject: %Subject:\nNewsgroups: %:Newsgroups:\nMessage-ID: %:Message-Id:\nDate: %:Date:\n\n

Przy okazji warto zwrócić uwagę, że Opera domyślnie używa nieprawidłowego sposobu zapisu identyfikatorów wiadomości z grup dyskusyjnych – traktuje je jak URL-e i poprzedza protokołem z dwukropkiem i dwoma ukośnikami. Prawidłowo nie powinno być ukośników, czyli zamiast news://abcdefgh@news.serwer.pl powinno być news:abcdefgh@news.serwer.pl. Usunięcie dwóch ukośników z odpowiedniego miejsca w tym pliku załatwia sprawę. Szukaj wpisu news://%:Message-Id: – zastąp go przez news:%:Message-Id:, zaś bezsensowny w tym wypadku termin „URL” zastąp czymś bardziej poprawnym (Identyfikator, Message-ID itp.). Aby zrobić z identyfikatora wiadomości URL, należałoby podać w ścieżce jeszcze nazwę serwera news, np. w postaci news://news-archive.icm.edu.pl/%:Message-Id:, ale to bezcelowo zmuszałoby czytelników do użycia danego serwera, skonfigurowania sobie dostępu do niego, i żaden serwer nie jest otwarty dla wszystkich, więc podawanie identyfikatorów wiadomości usenetowych w takiej postaci jest normalnie uciążliwe i odradzane.

4. Podpis

Normalnie, z poziomu interfejsu użytkownika, M2 pozwala na zdefiniowanie jednego podpisu na konto. Można jednak posłużyć się notatkami – aby wstawić podpis z notatki, wystarczy ustawić kursor w oknie kompozycji na koniec pisanego listu, po czym dwa razy kliknąć na daną notatkę. Wówczas możemy nie konfigurować żadnego podpisu w opcjach danego konta, a jeżeli przewidujemy częste zmiany podpisu, to nawet nie powinniśmy tego robić. Przed wstawieniem podpisu z notatki należy wyciąć ewentualnie wstawiony już podpis zdefiniowany we właściwościach konta. Notatki zawierające podpisy muszą zaczynać się od sekwencji
-- 
(czyli minus, minus, spacja, wszystko w pierwszej, osobnej linii podpisu).

Inne rozwiązanie (niekoniecznie wygodniejsze, podaję głównie jako ciekawostkę) to przygotowanie sobie osobnych plików z podpisami. Opera przechowuje podpisy w plikach tekstowych w katalogu %profil%\mail jako signatureX.txt, gdzie X to po prostu kolejny numer pliku. Informacje o przyporządkowaniu plików Podpisów do kont są zawarte w pliku accounts.ini. Nawet gdy Opera jest otwarta, przed otwarciem okna kompozycji można podmienić plik z danym podpisem na plik z innym podpisem i w ten sposób uzyskać przełączanie podpisów przy użyciu prostych plików wsadowych DOS. Robi się to następująco:

Należy pamiętać, że pliki z podpisami zawierają na początku tzw. znacznik BOM i są kodowane UTF-8. Do edycji tych plików należy wykorzystać albo okno konfiguracji podpisu we właściwościach konta, albo edytor znający ten format (na przykład UniRed link do str. zewnętrznej dla Windows, który jest freeware i ma również polski interfejs). Windowsowy Notatnik może plik podpisu zepsuć.

Dzięki użyciu kodowania UTF-8 pliki podpisów mogą zawierać teksty w dowolnych językach i używać dowolnych znaków.

5. Dodatek: Sprawdzanie pisowni w różnych językach

Aby dodać funkcję sprawdzania pisowni, należy zainstalować „napęd” Aspella link do str. zewnętrznej oraz co najmniej jeden słownik link do str. zewnętrznej, a następnie po zamknięciu Opery znaleźć plik spellcheck.ini (w katalogu, w którym zainstalowana jest Opera) i w nim dodać następujący wpis:
[Spell check]
Spell check engine=C:\Program Files\Opera\spellcheck.dll
Default Language=pl

(normalnie w tym pliku są już obecne dwie pierwsze linie, z czego druga może się nieco różnić w zależności od tego, w jakim katalogu zainstalowana jest Opera, zaś zamiast pl w ostatniej linii można wstawić oznaczenie innego języka, w którym pisuje się najczęściej). Sprawdzanie pisowni działa również w polach formularzy www (np. na forach dyskusyjnych) z wyjątkiem pól o wysokości jednej linii tekstu (jak np. pole przeznaczone na wpisanie szukanego tekstu w wyszukiwarkach). Uruchamiane jest przyciskiem w oknie kompozycji maila, z menu Edytuj ⇒ Sprawdź pisownię (ang. Edit ⇒ Check spelling) – w przypadku formularzy kursor musi być umieszczony w danym polu, oraz z menu kontekstowego po kliknięciu drugim przyciskiem myszy na treści pisanego listu lub w danym polu formularza:

Niedogodnością jest to, że zmiana języka słownika używanego do sprawdzania pisowni możliwa jest dopiero po otwarciu okna modułu sprawdzania. Zachęcam również do zapoznania się z odpowiednim wątkiem na polskim forum Opery link do str. zewnętrznejdrugim wątkiem, również na polskim forum Opery link do str. zewnętrznej.

Opera szuka Aspella na podstawie wpisu w rejestrze, w kluczu HKEY_LOCAL_MACHINE\SOFTWARE\Aspell, ciąg Path.

banner strony „Bykom stop!”
autor niniejszej strony popiera akcję „Bykom stop!” propagującą poprawne pisanie po polsku: z polskimi literami i bez błędów strona zewnętrzna

6. Dodatek: Niedogodności programu nie będące bugami

1. Niestosowanie domyślnego charsetu w stosunku do cytatów z postów, które nie zawierają deklaracji charsetu (głównie pochodzące z nieskonfigurowanych OE)
Opis problemu: Treść takiej wiadomości przy odpowiadaniu będzie potraktowana tak, jakby miała deklarację ISO-8859-1. Zgodnie z RFC 2046 link do str. zewnętrznej p. 4.1.2. brak deklaracji jest tożsamy z deklaracją US-ASCII i o ile można dyskutować nad sensownością domyślności ISO-8859-1, nie jest to zachowanie technicznie niepoprawne.
Metoda obejścia: Nakłaniać opslukowców do poprawienia konfiguracji, opornych tępić. Możliwe jest użycie konwertera MIME-Proxy link prowadzi do podstrony dla obejścia tego problemu.

2. Brak umiejętności doboru optymalnego (najwęższego możliwego) charsetu
Opis problemu: RFC 2046 link do str. zewnętrznej p. 4.1.2. zaleca stosowanie najwęższego możliwego charsetu, np. by używać deklaracji US-ASCII dla postów nie zawierających znaków spoza US-ASCII. Przyjęte też jest nieużywanie unikodu, gdy treść może być zakodowana w jednym z 8-bitowych charsetów ISO-8859-x.
Metoda obejścia: W gołym M2 brak. Możliwe jest użycie konwertera MIME-Proxy link prowadzi do podstrony dla obejścia tego problemu.

3. We współpracy z niektórymi przeglądarkami litery ze znakami diakrytycznymi i znaki specjalne zawarte w linkach mailto: nie są obsługiwane poprawnie
Opis problemu: Standard HTML pozwala na konstruowanie odsyłaczy uruchamiających okno kompozycji domyślnego mailera z już wstawionym adresem odbiorcy oraz wypełnionymi innymi częściami: tematem, treścią i ewentualnie innymi nagłówkami. Odsyłacz taki wygląda następująco: mailto:adres@server?subject=tytuł_maila&body=początek_treści_maila. Znaki spoza ASCII zawarte w tych linkach mogą ulec zepsuciu, efekt zależny jest od używanej przeglądarki – efekty zawierają się między pełną obsługą, przez obsługę tylko znaków z kodowania odpowiadającego ustawieniu regionalnemu (mogą wystąpić różne efekty w zależności od sposobu zapisania znaków spoza US-ASCII – jako znaki 8-bitowe, encje numeryczne czy ciągi hex), po brak obsługi. Problem bierze się stąd, że z jakichś powodów sposób użycia znaków spoza US-ASCII w linkach mailto jest nieunormowany (patrz RFC 2368 link do str. zewnętrznej p.2).
Metoda obejścia: Wydaje się, że problem nie istnieje, gdy znaki te są zakodowane jako UTF-8 i zapisane symbolicznie w postaci %hh.

7. Dodatek: Wyświetlenie dowolnego pola nagłówka czytanego listu

Zostało to opisane w p. 1.2, należy jedynie podstawić za content-type nazwę żądanego pola nagłówka. W zależności od potrzeb można nowe wpisy umieszczać na końcu lub między już istniejącymi wpisami, dzięki temu można wyświetlić nagłówki w żądanej kolejności.

Należy pamiętać, że każda instalacja Opery (nowej wersji lub reinstalacja) nadpisuje pliki css – po instalacji trzeba niestety ponownie wprowadzać zmiany.

8. Gdzie i kiedy nie używać polskich liter (ani innych znaków narodowych lub specjalnych)

Oprócz oczywistej sytuacji, gdy wiemy, że odbiorca nie będzie w stanie odczytać polskich (czy innych) liter – np. jest za granicą, korzysta z kafejek internetowych lub z uprzejmości gospodarzy i nie może skonfigurować komputera do wyświetlenia wszystkich znaków – bardzo zalecane jest nieużywanie żadnych takich znaków w nazwach załączników. Spowodowane jest to tym, że znaki spoza US-ASCII mogą być zakodowane na jeden z trzech sposobów:

Aby odbiorca mógł otworzyć załącznik, jego program musi obsługiwać użytą metodę kodowania. Brak obsługi danego sposobu kodowania u odbiorcy skutkuje zmianą nazwy załącznika – gdy list zawiera kilka załączników z opisem ich zawartości w treści, jest to bardzo uciążliwe. Innym problemem jest to, że oprócz zmiany nazwy pliku często zmieniane jest też rozszerzenie (na nic nie mówiące .dat, .att lub .bin), z czym mniej zaawansowany odbiorca sobie nie poradzi. Dodatkowo, nawet gdy program odbiorcy obsługuje metodę kodowania użytą przez nadawcę, w przypadku metod RFC dodatkowo jego system operacyjny i aplikacje używane do otwierania tego typu plików muszą obsługiwać znaki użyte w nazwie. Z kolei w przypadku załączników wysłanych bez kodowania nazwy (tryb Raw) znaki spoza US-ASCII w nazwie mogą zostać wyświetlone w przypadkowym kodowaniu (np. kodowaniu systemowym lub ISO-8859-1), skutkiem czego w nazwie będą krzaki. Nie istnieje proste, w pełni skuteczne rozwiązanie powyższych ograniczeń, jedyny sposób, który na 100% zadziała u wszystkich, to użycie wyłącznie znaków US-ASCII w nazwie załącznika i dbanie o to, by nazwy załączników, nawet niezawierajace znaków narodowych, były krótkie (kilkanaście znaków).

Należy również pamiętać, że niektóre formaty plików co prawda pozwalają na umieszczenie w treści znaków narodowych, ale nie przenoszą informacji o użytym kodowaniu, przez co w wypadku przesłania takiego pliku jako załącznik u odbiorcy znaki narodowe mogą się nie wyświetlić prawidłowo. Najbardziej powszechny przykład to pliki tekstowe (o rozszerzeniu .txt). W typowym systemie Windows plik taki otwierany jest w systemowym Notatniku, w którym zawsze używane jest kodowanie systemowe i nie ma żadnej możliwości zmiany kodowania treści. Znaki narodowe będą pokazane prawidłowo tylko w sytuacji, gdy komputer odbiorcy używa tego samego kodowania systemowego, którego używa komputer nadawcy. Kodowanie systemowe zależy od locale systemowego (w przypadku korespondencji z osobami przebywającymi w innych krajach należy założyć, że locale nadawcy i odbiorcy będzie się różnić) oraz używanego systemu operacyjnego. Przed przesłaniem takiego załącznika należy się upewnić, że odbiorca będzie mógł zobaczyć znaki narodowe w treści.

9. Linki

Rozwiązania przetestowane na programie Opera w wersji 8–8.54 pod Windows 2000 SP4 English. Opracowano m.in. na podstawie strony o konfiguracji M2 link do str. zewnętrznej.

licznik