Polska Wikipedia - Phase III

Wszystkim biorącym udział w tej dyskusji polecam też lekturę strony Sprawy związane z przejściem na PHP.

Dużej części stron przeciętny użytkownik nigdy nie zobaczy na oczy (niemiecka wersja nawet ich nie tłumaczy), więc proponuję skupić się w pierwszej kolejności na tych najczęściej używanych stringach.

Prefiksy o specjalnym znaczeniu dla wiki-linków nie są jeszcze zaimplementowane w skryptach LanguageXx.php. Chodzi o image i media. Moje propozycje na tłumaczenie to 1) grafika oraz media, 2) brak tłumaczenia.

Przestrzenie nazw File i File_talk (też czekające na implementację; chyba zastąpią Image i Image_talk) proponuję "oczywiście" tłumaczyć Plik oraz Plik_dyskusja.

--Youandme

Moje słowa uznania dla Youandme za ten kawał, porządnej roboty.
Wg mnie jakość tego tłumaczenia jest na tyle dobra, że wydaje mi się że można by od razu go używać.
Trochę się obawiam, że nasze dyskusje nie poprawią w zanaczący sposób tego tłumaczenia, a tylko opóźnią jego finalizację.
--Kpjas

Fałszywa skromność ;) każe mi powiedzieć jedynie "to drobnostka". Czyli co? Zgłaszamy się teraz do Lee Crockera?

Proponuję kontynuować dyskusję co do skrótów dni tygodnia na tej stronie. Przypomnę:

//ym czy musza być z wielkiej litery?
//ym takie skróty sa na codzień spotykane - mało komunikatywne
//taw sugeruje zupełnie zrezygnować ze skrótów nazw miesięcy (po polsku się tak prawie
      wcale nie pisze) i pisać pełną zazwę, w dopełniaczu
      (trzeba będzie sprawdzić czy software nie używa tej samej tablicy raz w dopełniaczu a raz
       w mianowniku, English speakers na pewno o tym nawet nie pomyśleli).
//ym warto mieć skróty, a najlepiej chyba liczby, np. "października" zajełoby 
     ćwierć strony na "Nowe strony" (zob. zrzuty)
//taw na razie nie używamy skrótów i mamy się dobrze (np. na Ostatnie Zmiany)
//kpjas Wg mnie skróty mogą być, unix-owcom są dobrze znane. Bardziej mnie
  razi format daty.

Obecny format daty oczywiście jest nie do przyjęcia (nie miałem jeszcze czasu nim się zająć). Do przyjęcia będzie zapewne taki: 1) 4 października 2002, taki 2) 4 paź 2002 lub taki 3) 4-10-2002. Ale uwaga: w wielu miejscach pojawiają się pojedyncze daty (i wszystko wygląda ładnie), natomiast na wszelkiego typu listach (chyba właśnie oprócz Ostatnich zmian) pojawią się zestawienia w rodzaju poniższego:

 23:40 9 października 2002 Gęś . . 127.0.0.1 
 14:41 4 października 2002 Stilicho . . Chris mahan? (added page) 
 14:20 4 października 2002 Babes in Toyland . . Nairobiny? (first stab)
 itd.

czyli na stronie znajdzie się mnóstwo zbędnej informacji (niestety oprogramowanie obecnie nie grupuje plików i nie opatruje ich nagłówkiem zwierającym wspólną datę). Miło by było czytać stronę z pełnymi nazwami miesięcy lecz w niektórych miejscach dużo byśmy na tym stracili. Moje preferencje są takie 1) 5%, 2) 35%, 3) 60%. Może jakieś głosowanie? Na razie (3 osoby) chyba wygrywają skróty. --Youandme

Widziałem starą dyskusję "monitorowane - obserwowane". Ale nie poznałem argumentów na korzyść monitorowne. Mi podoba się po prostu od dawna zadomowione w języku polskim "obserwowane". Gdyby głosować to widzę, że jest na razie 2:1. --Youandme

Nie będę się upierał. "Obserowowane" też może być.
Kpjas

Wyślij, a jakby co to poprawki stylistyczne można zrobić jak już będzie mieli nowy software. I dodaj, że testową instalację na http://test.wikipedia.com/ trzeba odnowić. --Taw

Ostatni update przesłałem Brionowi w nocy z 20. na 21. września. Dotyczył głównie polskich nazw stron specjalnych. Gdyby chcieć mieć konsekwentnie przetłumaczone wszystkie, to potrzebna by chyba była głębsza ingerencja w kod niż tylko w plik Language. "Śmietnik" towarzyszący polskim literom też nie jest łatwy do "wygładzenia" i nie zachęca nikogo do poświęcania mu więcej czasu (u siebie wciąż próbuje to zrobić, ale jak można się domyśleć bezskutecznie).

Zatem, od tamtej pory zero aktywności ze strony developerów (sztuk 1). Z naszej chyba też :-) Co robimy dalej? --Youandme

No jest instalacja na http://pl.wikipedia.org/, którą powinniśmy użyć do testów i zobaczyć czy wszystko działa, nie ? Jak będzie działać to piszemy do nich że sie przenieść. --Taw

Właśnie ową instalację miałem na myśli. Samo z siebie nie zadziała. Brion jak dotąd nie odpowiedział na ostatni mail (wyżej wspomniany). Jedyną metodą jaka mi przychodzi teraz na myśl to odpluskwianie samemu (a nie mam na to za bardzo czasu) i podsyłanie łat. Może taka metoda drobnych kroczków przyspieszy przesiadkę. BTW czy mamy obstawać przy ISO-8859-2 (czego jestem zwolennikiem) czy zgodzić się na UTF-8? --Youandme

Oczywiście że powinniśmy przejść na UTF-8 i to jest najważniejszy powód do przesiadki. Teraz jedynym sposobem, żeby normalnie pisać na Wikipedii jest pisanie w zewnętrznym programie, zapamiętanie pliku, konwersja na encje HTML, i wklejenie tego do Wikipedii. I w wyniku tej operacji nie będzie się dało czytać tego co się wkleiło bo zamiast normalnych znaków, które przeglądarka potrafi wyświetlać (bo potrafi wyrenderować ostateczną stronę) są encje HTML których o ile wiem nikt nie potrafi w głowie konwertować na znaki.

Wklejka z wikitech-l:

1.
We can't use latinX, we can either use utf8 or latinX +
&lot_of_silly_numeric_entities;

2.
UTF-8 allows you to insert all diactrics and other characters that
happen from time to time in proper names etc. Encoding them in html
codes is huge pita. There is no software that facilitate it.

3.
&silly_numeric_entities; are completely unreadable, and wikipedia
markup language should be easy to read and write.

4.
Interwiki links 100% require utf-8. Making interwiki links using
%-codes is completely out of the question. You can't even use
&silly_entities; in such links, as software don't know in what
encoding should it convert non-ascii characters to %-codes.

5.
General interoperability needs that. You wouldn't even be able to copy
from one wikipedia to another, if they used different charsets,
as software won't know in should convert diactrics to &entities;

A co konkretnie nie działa ? --Taw

Jeden z problemów jest taki, że oprogramowanie nie generuje właściwego meta http-equiv, więc na przykład na angielskiej wikipedii, jak wpiszę coś przy domyślnym kodowaniu (a to jest ISO-8859-1) to się robi kiszka.
druga rzecz, o której już pisałem, to Strona_g%25C5%2582%25C3%25B3wna - to wcale nie jest bardziej czytelne w utf-8 niż przy użyciu encji

--Matusz

Poranny upgrade część spraw załatwił. Podziękowania dla Briona! Pozostaje to co wymienił Matusz i wyszukiwanie (pomijając już tłumaczenie nazw stron specjalnych). Jak macie jakieś poglądowe przykłady czego nie łyka wyszukiwarka, zamieście w Raporcie o błędach -- Youandme

To czy URL jest czytelny czy nie nie ma żadnego znaczenia. Chodzi o to żeby markup wikipedii był czytelny. "Nazwy stron specjalnych" w znaczeniu URLe jmożna zostawić nietłumaczone, vide http://de.wikipedia.org/wiki/Spezial%3ALongpages --Taw

Czytelność w pewnym momencie będzie miała znaczenie (oby jak najszybciej!): ludzie (zwykli, czyli tacy nie znający się na Unicode'ach, charsetach itd.) będą drukować sobie strony z Wikipedii, a by użyć odnośnika w swojej pracy czy sprawdzić nowszą wersję nie będą wiedzieli co wpisać. Takie szczegóły niektórzy zaliczają do PR (Public Relations). Dlatego też warto włożyć dużo wysiłku w tłumaczenie interfejsu, żeby nie raził swoim językiem - to będzie sprzyjać reklamie Wikipedii. Z innej beczki (ale nie do końca innej): w książkowych odnośnikach jak czegoś nie daje się wydrukować stosuje się przynajmniej transliterację (choćby po to żeby porozumiewać się z czytelnikami w jakimś "ludzkim" języku).

Co do tłumaczenia stron specjalnych (nie wszystkich) to jest chyba jak na razie jedyne wyjście.

Co masz na myśli pisząc: żeby markup wikipedii był czytelny? --Youandme

Co do czytelności markupu to zobacz jak wygląda markup w artykule który używa dużo znaków unikodowych, np. w pl:Odmienne części mowy w języku japońskim. To dotyczy nie tylko pl:kanji i innych skryptów, ale również "zwykłych" liter łacińskich z niektórymi akcentami. Taka sytuacja jest zupełnie niedopuszczalna.

A coś jeszcze w owym markupie nie działa? Pod IE 6.0 działa wszystko. Jedyne o co można jeszcze poprosić, to żeby w trakcie konwersji zamnieniono encje na znaki unikodowe. --Youandme

Nie działa to że nic nie widać ! Zamiast normalnych znaków są jakieś nieczytelne numerki. I o nic tu się nie prosi tylko trzeba od softwaru wymagać żeby można było pisać wszystkie znaczki jako znaczki. Software którego używamy teraz jest po prostu zupełnie zepsuty pod tym względem. --Taw

Na niemieckiej strony specjalne są tłumaczone, ich tytuły też, tylko adresy URL nie. Nie sądze żeby to robiło aż tak dużą różnicę.

Nie są tłumaczone bo chyba software tego nie wspiera. Poddaję się... Wstawiłem tylko nazwy stron z przestrzeni Wikipedia. --Youandme

Adresy są w ASCII, więc tu będą numerki niezależnie od tego czy Wikipedia będzie w ISO-8859-2 czy w UTF-8.

A przeglądarka to co wpiszesz, jeśli zawiera znaki spoza ASCII konwertuje na numerki zakładając że to jest UTF-8 (bo nie może znać enkodingu, skoro nie ściagnęła jeszcze strony, a nie może ściągnąć strony nie znając lub nie zgadują enkodingu URLa). Czyli będzie można wpisywać normalnie adresy z pliterkami, co teraz jest niemożliwe. (chyba że to tylko Mozilla tak ma, a inne przeglądarki zachowują się inaczej ...) --Taw

Pod IE 6.0 jak najbardziej mogę wpisać nazwę strony z pliterkami i działa! --Youandme

A to źle że działa. To po prostu nie ma prawa działać - przeglądarka nie ma prawa zakładać ISO-8859-2 jako domyślnego enkodingu do czegokolwiek, choćby dlatego, że URL powinien działać tak samo dla wszystkich, niezależnie od locale. Mozilla zakłada domyślnie UTF-8, co jest bardzo rozsądne (to jedyny encoding który jest kompatybilny z ASCII i zawiera praktycznie wszystkie używane znaki). --Taw

Odpowiedź do obu ostatnich (najbardziej wciętych) komentarzy Tawa

Jest tak: IE 6.0 ma coś takiego jak automatyczne rozpoznawanie kodowania i jak otwieram testową Wikipedię w opcjach przeglądarki (słusznie) pojawia się odhaczony UTF-8. Domyślam się więc, że polskie litery, które wpisuję do adresu konwertowane są poprawnie: UTF-8 -> ASCII. W każdym razie pracując na IE 6.0 widzę wszystko tak jak chciałbym zobaczyć, i w polu edycyjnym są piękne kanji, piękne znaki łacińskie z diakrytykami itd, i na podglądzie tak samo; i mogę wpisać do adresu polskie literki i tytuł nowej strony pojawi się w poprawnej postaci (To nie jest kryptoreklama! Daleko mi do wspierania przedsięwzięć M$). A jeśli chodzi ci o to że widać numerki typu &27345; w polu edycyjnym to, jak mowię, jest to kwestia do załatwienia w trakcie konwersji i trzeba prosić o to developerów. Podsumowując z mojego punktu widzenia (podkreślam tylko z mojego) software jest bez zarzutu z wyjątkiem wyszukiwarki. --Youandme

Nie, ponieważ adres musi zostać przekonwertowany bez wiedzy o kodowaniu strony. To był by typowy problem jajka i kury - trzeba by znać kodowanie żeby zaadresować poprawnie stronę, a żeby ją ściągnąć i sprawdzić trzeba by najpierw mieć jej adres którego nie wiemy jak zakodować.

Kanjisy są ładne do chwili naciśnięcia przycisku Zapisz lub Obejrzyj, po czym zamieniają się w numerki. I tu się nie da żadnej konwersji zrobić - albo dane wysyłasz w UTF-8 (i nie potrzebujesz numerków) albo w ISO-8859-2 (i software nie ma jak wysłać inaczej niż numerkami). No chyba że edycja w UTF-8 a wyświetlanie w ISO-8859-2. Ale to nie tylko bezsensowne komplikowanie sprawy, ale tytuły z diaktrykami innymi niż polskie i tak nie będą działać. --Taw

Przetestwoałem i kanji, i diakrytyki (zobacz Ostatnie zmiany) i wszystko jest OK. Co do jajka i kury: Apache'a (na którym chyba chodzi i ma chodzić także nasza Wikipedia) używam od 2 tygodni i nie przyglądałem się "bebechom" ale widzę, że jest jakiś moduł do negocjacji języka i m.in. enkodingu może on (jakoś) załatwia wszystko? Póki co, dopóki nie zobaczę jak to wygląda z punktu widzenia innej przeglądarki (na żywo), dyskusja staje się dla mnie ciut teoretyczna. Over --Youandme

Drobna kwestia: Tłumaczenie "(Ta strona obecnie nie zawiera tekstu)". Chyba lepiej było by "(Ta strona obecnie jest pusta)". --Taw

Wszystko jedno. Bardziej mnie martwił fakt, że strona odnosi się do całości, czyli artykuł (część edytowalna przez użytkownika) + menu + wszelkie inne wyświetlane dodatki. Jest chyba jasne rozróżnienie między artykułem, a stroną ale już nie sprawdzałem czy do końca konsekwentnie trzymano się tego w angielskiej wersji. Na razie wstawiam tekst bardziej "przyjazny" i idący w stronę owej konsekwentności "(Nie ma jeszcze artykułu o tym tytule. Wybierz Edytuj by go rozpocząć.)". --Youandme