08-05-07, Holek <holek.n(a)gmail.com> napisał(a): Jak dla mnie dostosowywanie się do konkretnej wyszukiwarki to nie za dobry pomysł. A nie moga szukać według schematu: ^*[[(.*)|(.*)]] ?- ?(.*)$ Tak wygląda niemal każda pozycja w disambigu.

On Tue, 8 May 2007, Tomasz Ganicz wrote: "A może Curie-Skłodowska też?" ;) tak mi się skojarzyło... i mean, przecież grafikę to akurat się faktycznie mniej więcej tak wstawia ;) -- | "<robT> Name ONE thing that your windows comp can do that my MAC cant | <bawss> Right click." - bash.org | \=------=| blue (at) wave460.net |=------=| http://wave460.net |=------

Chodzi o to, że obecnie wiersz na stronie ujednoznaczniającej może mieć dowolny format, może wyglądać np. tak (ze strony Troglodyta): * We [[Francja|Francji]] określa się tym mianem ludzi mieszkających w domach wykutych wewnątrz skał. Jeśli na tej podstawie wyciągnemy wniosek, że słowo "troglodyta" jest synonimem słowa "Francja", to nie będzie to wniosek poprawny. Szablon wymusza wyróżnienie pewnego linku - jego wywołanie wygląda np. tak (przerobiona linijka z artykułu Troglodyta): {{disambig-item|Strzyżyk|Strzyżyk|gatunek ptaka z rodziny strzyżykowatych (Troglodytidae).}} Widać, że "Strzyżyk", który poajwia się jako osobny parametr szablonu, jest wyróżniony. Moglibyśmy dodać inne linki w opisie: {{disambig-item|Strzyżyk|Strzyżyk|gatunek [[ptaki|ptaka]] z rodziny strzyżykowatych (Troglodytidae).}} Tutaj słowo "ptaka" też jest linkiem, ale wyraźnie widać, że słowo "troglodyta" jest inną nazwą słowa "strzyżyk", ale nie słowa "ptak". Gdybyśmy napisali tak jak się pisze obecnie: * [[Strzyżyk]] - gatunek [[ptak|ptaka]] z rodziny strzyżykowatych (Troglodytidae). to nie byłoby widać, który link prowadzi do konkretnego znaczenia ujednoznacznianego słowa, a który w ogóle nie ma związku z tytułem strony ujednoznaczniającej. Pozdrawiam, Michał -- Michał Kosmulski (mkosmul) http://www.netsprint.pl/ http://hektor.umcs.lublin.pl/~mikosmul/

08-05-07, Michal Kosmulski &lt;michal.kosmulski(a)netsprint.pl&gt; napisał(a): [...] Jeśli po linku występuje myślnik, to raczej nie widze szans na to, aby nie prowadził on do ujednoznacznianej strony. Już większe prawdopodobieństwo, że ktoś poda źle parametry w szablonie i nie zauważy, że wyświetla się źle.

Michał! 1. błąd - na tej liście żadko rodzi się coś konstruktywnego (sorry chłopaki, ale po dwóch latach obecności mam swoje zdanie) 2. Zrób listę disambigów, które nie-pasują do potrzebnego ci schematu formatowania, a my spróbujemy je ręcznie poprawić. Punkt 2 jest o tyle istotny, że na bank wyłapie masę lewych disambigów, które i tak musimy poprawić ;) Pozdrawiam AJF/WarX

09-05-07, Przemyslaw 'BlueShade' Idzkiewicz &lt;blue(a)wave460.net&gt; napisał(a): [...] Niech to lepiej robią obok Wikipedii, bo w niej należy tworzyć WYŁĄCZNIE ENCYKLOPEDIE!!! Tworzenie obok mogło by być nawet prostsze, bo mediawiki nie jest oprogramowaniem stworzonym z myślą o takich rzeczach. A tak na marginesie, to jest jakikolwiek powód ku temu, aby robić to na wiki inny niż to, że wikipedyści zrobią to za darmo, a za sprawdzanie prywatnej listy na zewnątrz trzeba by komuś zapłacić?

Zgadza się przykłady podane przez Michała są jednak ciekawe - w przypadku torglodyty jest mnóstwo okresleń słownikowych - w Arizonie jest hasło, które nie brzmi dokładnie Arizona (coś tam). Jak ja to widzę jako nie techniczny :) W disambigu jest istotne to, co jest napisane w nawiasie danego homonimu: *[[Lepton (mechanika kwantowa)]] *[[Lepton (moneta)]] a więc mechanika kwantowa i moneta W przypadku troglodyty nie mamy ani jednego linku do ency hasła (btw - określenie technofoba informatycznego jako torglodyty to OR) W takim przypadku można dać inne rozwiązanie, które nie myliłoby wyszukiwarki. Po * nie ma linku, więc się nie uwzględnia hasła po *, albo lepiej dajemy link z prefiksem [[wikt:Troglodyta|Troglodyta]]. Na fr wiki jest chyba nawet tak, ze jak hasło jest słownikowe, to nie pojawia się pusta strona w Wikipedii, tylko informacja o tym, że jest takie hasło w wikisłowniku (nie sprawdź, tylko jest) - chyba nie jest indeksowane, jak u nas {{nieart}}. Przypadek troglodyty jest bardzo specyficzny. Wyszukiwarka w takim przypadku wykorzystywałaby dodatkowo zasoby Wikisłownika - da się tak? * [[Arizona (wąż)]] * [[Arizona (stan w USA)]] * [[Arizona (film dokumentalny)]] * [[Okręt]] [[USS Arizona]] Tu mamy wąż, stan w USA i film dokumentalny. Co do okrętu trzeba się zdecydować - albo [[Arizona (okręt)]] i redirect albo przenosimy w disambigu do zobacz też, gdzie umieszczamy linki bez (określeń w nawiasach) - albo jakoś inaczej oddzielamy. Hmmm, brakuje mi tu [[Arizona (wino)]] ;) Do obgadania. Czy o to chodzi, czy problem pogrzebany jest gdzie indziej? przykuta

Opis oczywiście powinien być - wyciąłem dla czytelności. Co do leptonu - to jest raczej problem z tytułem - raczej powinno być [[Lepton (cząstka elementarna)]] - od razu wiadomo o co chodzi. No, tu też jest źle, ale gdy będzie * [[Arizona (wąż)]] * [[Arizona (stan w USA)]] * [[Arizona (film dokumentalny)]] * [[Arizona (okręt)]] lub * [[Arizona (wąż)]] * [[Arizona (stan w USA)]] * [[Arizona (film dokumentalny)]] * [[USS Arizona]] - [[okręt]] ... to bot sobie poradzi - IMHO powinien ignorować wszystkie linki, których treść jest różna od tytułu disambigu - w linku [[okręt]] nie ma "Arizona", więc bot ignoruje... A gdyby zrobić jeszcze * [[Arizona (wąż)]] * [[Arizona (stan w USA)]] * [[Arizona (film dokumentalny)]] == Zobacz też == * [[USS Arizona]] - [[okręt]] ... I bot ignoruje wszystko co jest poniżej == Zobacz też == tyle powiedział teoretyk :D Tak czy siak IMHO lepiej się pomęczyć nad botem raz niż zmuszać Bogu ducha winnych wikipedystów by stosowali skomplikowane formuły w disambigach ;) Oczywiście w każdym przypadku powinien być opis i ukryty nawias * [[hasło (coś w nawiasie)|]] - to jest [[to]] i [[owo]] Zaraz zrobię oftopa: <OT>Z | rzadko się korzysta i niepotrzebnie się pisze np. [[Wikipedia:Jakieś dłuższe hasło|Jakieś dłuższe hasło]] zamiast [[Wikipedia:Jakieś dłuższe hasło|]] - mniej czasu się traci na takie ceregiele</OT> to pisałem ja przykuta

Eh, zakładaj dobra wolę :) Mi się prezentacja podobała i liczę na kolejne. W szczególności, że mobilizuje nas to do robienia porządków. (Ta firma była sponsorem konferencji :) No, mamy coś takiego: http://pl.wikipedia.org/wiki/Wikipedia:Strony_ujednoznaczniaj%C4%85ce Nawet niedawno rozbudowałem o przypadki z disambigiem R :) Możemy się przenieść na stronę dyskusji? Te zapiski zginą zasypane lawiną innych postów. przykuta

Spisałem coś krótko w brudnopisie (http://tinyurl.com/23unao). Jak komuś się chce to zapraszam do przejrzenia i poprawek/poszerzenia.

Czesc, dziekuje wszystkim za komentarze, zwlaszcza te krytyczne. Po przemysleniu sprawy, doszedlem do wniosku, ze zaproponowane przeze mnie poczatkowo podejscie faktycznie byloby zrodlem trudnosci przy edycji stron. Wpadlem jednak na pomysl, jak mozna osiagnac [prawie] ten sam efekt bez potrzeby az tak silnej ingerencji w wyglad stron ujednoznaczniajacych. Oczywiscie tak samo jak pierwotna koncepcja, tutaj tez stosowanie tej techniki lub jej nie stosowanie nie byloby w zaden sposob wymuszone. Zatem: zarzucam stara propozycje, a zamiast niej proponuje: 1. Tworzymy szablon o nazwie, dajmy na to, {{link-1-ujednoznacznia}}. 2. Szablon ten jest pusty, tzn. nie wstawia zadnego tekstu w tresc strony. Sluzy on jedynie za marker, tzn. sama jego obecnosc jest pewna informacja. 3. W tresci strony ujednoznaczniajacej wstawiamy ten szablon na koncu linijki, o ktorej wiemy, ze sie trzyma wlasciwego formatu, tzn. ze pierwszy link wewnetrzny prowadzi do hasla opisujacego konkretne znaczenie ujednoznacznianego slowa. 4. Przyklad (znowu lepton): {{Disambig}} *[[Lepton (mechanika kwantowa)]] - grupa 12 cząstek elementarnych: [[elektron]], [[mion]], [[taon]], [[neutrino elektronowe]], [[neutrino mionowe]], [[neutrino taonowe]] oraz odpowiadające im [[antycząstka|antycząstki]].{{link-1-ujednoznacznia}} *[[Lepton (moneta)]] - [[moneta]] [[miedź|miedziana]] bita w [[starożytna Grecja|starożytnej Grecji]].{{link-1-ujednoznacznia}} *Slowo lepton bywa takze stosowane jako [[obelga]], najczesciej w formie ''[[Ty leptonie]]'' Dwa pierwsze znaczenia sa oznakowane szablonem, dzieki czemu bot wie, ze pierwszy link w danym punkcie jest "tym wlasciwym". Ostatni wiersz (oczywiscie wydumany) nie jest zgodny z ustalonym formatem, wiec nie zawiera szablonu i zostanie przez bota zignorowany. Wydaje mi sie, ze takie podejscie byloby znacznie mniej inwazyjne niz to co proponowalem na poczatku i z czego sie wycofuje. Poniewaz padalo wiele roznych uwag, postaram sie do nich zbiorczo ustosunkowac ponizej aby nie mnozyc postow ponad miare: * Problem z pobieraniem PDF: u mnie dziala, ale jest tez kopia na wikimedia.org, pod adresem http://pl.wikimedia.org/wiki/Grafika:Netsprint_2007.pdf - moze ta pojdzie. * Synonimy: uzylem tego slowa w niezbyt scislym znaczeniu. Chodzilo mi nie o synonimy w rozumieniu gramatyki jezyka polskiego, tylko o "alternatywne tytuly hasel" - slowa, ktorych wpisanie w wyszukiwarce powinno skutkowac wyswietleniem innego rekordu. Przykladowo: "Cassius Clay" to prawdziwe imie i nazwisko boksera znanego jako "Muhammad Ali". Jesli uzytkownik wpisze zapytanie "Cassius Clay", powinien moc znalezc strone "Muhammad Ali". Jesli takie haslo jest jednoznaczne, uzywamy redirectow i sprawa jest prosta. Jesli nie jest jednoznaczne, mamy strone ujednoznaczniajaca i tutaj zaczynaja sie schody. Wezmy np. strone "Tygrys (ujednoznacznienie)" - ktos kto wpisze haslo "tygrys", powinien moc znalezc informacje zarowno o zwierzeciu jak i o rzece jak i o niemieckim czolgu PzKpfw VI Tiger. O ile latwo jest z "Tygrys (rzeka)" usunac nawias, to dojsc automatycznie do tego, ze szukajac "tygrys" mamy znalezc m.in. "PzKpfw VI Tiger", raczej sie nie da - wymaga to juz pomocy ze strony czlowieka. Musimy wiedziec, ze mozna bezpiecznie wziac pierwszy link z wiersza, bo w tym wypadku mozna to zrobic, ale juz w kolejnym wierszu z tego samego artykulu: * tygrys &ndash; [[Krzyżówka (genetyka)|krzyżówka]] [[pstrąg potokowy|pstrąga potokowego]] i [[pstrąg źródlany|źródlanego]] nie mozna tego zrobic, bo wyjdzie, ze "krzyzowka" to jedno ze znaczen slowa "tygrys" i ze szukajac slowa "tygrys" mamy znalezc artykul "krzyzowka". Tak wiec istotne jest "znakowanie" tych hasel, ktorych nazwa nie zawiera slowa "tygrys". Z tymi, ktore je zawieraja, program umie sobie poradzic sam. * Udostepnienie danych wygenerowanych na bazie Wikipedii: oczywiscie zawarte w wyniku wyszukiwania z netsprinta streszczenie artykulu z wikipedii jest dostepne na FDLu i mozna z nim robic wszystko, na co licencja pozwala. Aplikacja, ktora te rekordy generuje, jest niestety zamknieta i raczej taka pozostanie - na to nie mam wielkiego wplywu. Jak dokladnie jest z innymi danymi, ktore bot moze wygenerowac, tego nie wiem; sprawy licencyjne ustalal z Polimerkiem kolega z innego dzialu, w razie potrzeby moge dac na niego namiar. Jesli chodzi o prace wikipedystow, to o ile oczywiscie zachecalbym wszystkich do "znakowania" stron ujednoznaczniajacych, to chodzi mi glownie o *mozliwosc* takiego znakowania (czyli ustalenie mechanizmu, ktory nie zrobi zbyt wielkiego zamieszania i nie bedzie przeszkadzal osobom nim nie zainteresowanym), a nie o to zeby ktos cala prace za mnie *wykonal*. Dostawianie szablonow w "trudnych" stronach ujednoznaczniajacych moglbym prawdopodobnie w znacznej mierze wykonac sam (choc oczywiscie wszelka pomoc powitalbym z radoscia). Wyobrazam sobie tez, ze netsprint nie jest jedynym programem, ktory ze struktury stron ujednoznaczniajacyh moglby wyciagnac uzyteczne informacje, tak wiec te znaczniki moglyby sluzyc rowniez innym. * Arizona (wino) - tez sie zdziwilem ze nie ma jeszcze tego artykulu, w sieci sa cale strony poswiecone "winom prostym". Podsumowujac poczatek postu: wycofuje sie z pierwotnej koncepcji, prosze o komentarze do koncepcji nowej, uzywajacej tylko szablonu-markera :) Mam nadzieje, ze nawet jesli ostatecznie koncepcja sie nie przyjmie (ale licze, ze wymyslimy cos co da sie zastosowac w praktyce), to przynajmniej wyniknie z tego jakas uzyteczna dyskusja na temat stron ujednoznaczniajacych. Pozdrawiam, Michal

Racja, nie pomyślałem o tym. Przejrzałem trochę stron ujednoznaczniających i rzeczywiście w tej chwili sporo stron stosuje się do wymienionego wyżej schematu. Kiedy robiłem pierwsze podejście do interpretacji stron ujednoznaczniających przez program, odniosłem wrażenie, że ich format jest raczej swobodny i wypróbowawszy kilka heurystyk, stwierdziłem, że wszystkie dawały zbyt wiele fałszywych synonimów. Wygląda, że od tamtego czasu sporo się zmieniło na plus. Mogę sobie wyobrazić wpis, w którym przypadkowo będzie użyty taki format wiersza, ale pierwszy link nie będzie prowadził do ujednoznacznienia, np. ktoś mógłby napisać: Słowo "wilk" może oznaczać: *[[zwierzę]] - drapieżnego [[ssak]]a ale chyba będzie to raczej wyjątek. Jeśli dałoby się uczynić ze wspomnianego formatu oficalne zalecenie edycyjne, to myślę, że mój problem byłby w znacznej mierze rozwiązany (może pojawią się jakieś niespodziewane wyjątki od tej reguły, ale w tym momencie liczę że nie będzie ich zbyt wiele). Chodzi o to, żeby nie było tak, że ktoś zmieni stronę aby używała nowego formatu, a ktoś inny ją przeformatuje w inny sposób, bo tak będzie jego zdaniem lepiej wyglądało. Jeśli format będzie oficjalnym zaleceniem, takie sytuacje nie powinny już mieć miejsca, a gdyby miały, to zalecenie edycyjne będzie poważnym argumentem za przywróceniem "oficjalnego" sposobu formatowania. Nie do końca rozumiem, o sprawdzenie której listy chodzi? Ważne byłoby dla mnie to, aby nie było wpisów pasujących do ustalonego formatu, ale zawierających w pierwszym linku "niewłaściwą" stronę. Jeśli jakieś strony używałyby innego formatu (bo jeszcze nie zostały sprawdzone), to nie byłoby to problemem - bot po prostu ignorowałby je. Więc jeśli chodzi o moje potrzeby, to nie ma konieczności sprawdzania od razu wszystkich disambigów (choć oczywiście taka akcja na pewno byłaby bardzo pomocna), możnaby to sprawdzanie rozłożyć w czasie (a nawet bez sprawdzania mechanizm powinien działać przyzwoicie). Przy przeszukiwaniu Wikipedii. Zmieniając po raz kolejny strategię proponuję zatem: 1. Na razie dać sobie spokój z szablonami i innymi markerami. Jeśli okaże się, że samo sprawdzanie ujednoznacznień pasujących do ustalonego formatu to za mało, najwyżej za jakiś czas ponownie wrócę do tematu. 2. Dopracować szczegółowo zalecenia edycyjne ze strony http://pl.wikipedia.org/wiki/Wikipedysta:Witek1988/brudnopis i jeśli będzie co do nich zgoda, na umieszczenie ich na http://pl.wikipedia.org/wiki/Wikipedia:Strony_ujednoznaczniaj%C4%85ce jako oficjalnego zalecenia dla tworzących strony ujednoznaczniające. Prawdopodobnie trzeba by też dopuścić oprócz formatu *[[podobna nazwa]] - krótka definicja również dodatkowo *[[podobna nazwa]] (wyjaśnienie) - krótka definicja bo taki format wydaje się być używany na sporej liczbie stron, np. w taki sposób: * [[hrabstwo DeKalb (Alabama)|hrabstwo DeKalb]] ([[Język angielski|ang.]] ''DeKalb County'') – w stanie [[Alabama]] i przenoszenie nazwy oryginalnej za myślnik źle by wyglądało. Pozdrawiam, Michał -- Michał Kosmulski (mkosmul) http://www.netsprint.pl/ http://hektor.umcs.lublin.pl/~mikosmul/

| -----Original Message----- | From: ... Tomasz Ganicz | Sent: Wednesday, May 09, 2007 10:42 AM / | To dopracuj to zalecenie i zgłoś je pod dyskusję w kawiarence | technicznej Z zaznaczeniem, że była owocna dyskusja na liście :-P - niech niechętni liście mają za swoje ;-) . Przy okazji obalono (kolejny raz) tezę Łorksa, że nic sensownego tu nie da(ło) się wypracować. Oczywiście wiem, że taka wypowiedź to była kolejna podpucha łorsksowa, ale wolę to napisać, bo sporo tu nowych i ktoś z nich nie znając naszego ;-) sympatycznego esfałgowca pewnie mógł się wystraszyć. | - jak nikt nie będzie protestował to nie trzeba | przeprowadzać głosowania - jak będą protesty no to trzebaby | to głosować. To zależy od tego jakie będą te hipotetyczne protesty. Jeśli merytoryczne, to jedno, jeśli w stylu "nie bo nie", to nie będzie po co tracić czasu. Sam wprawdzie tylko śledzę dyskusję, i choć z braku czasu nie wnikam w szczegóły, to jednak widzę że jest merytoryczna i prowadzona we wzorcowym wikianym stylu, a wnioski są słuszne i konsensusowe. Przy okazji uznanie dla Michała, który nie bronił swojej koncepcji jak ukochanego dziecięcia lub niepodległości. No i ważny argument, że na enwiki jest to uregulowane jest też istotny - choć oczywiście tak jak m.in. Beno nie uważam, że musimy wszystko kopiować z en. I na marginesie - czy to nie jest pierwszy przypadek współpracy społeczności plwiki z komercją? Poza Helionem oczywiście, ale to coś innego. Pzdr., Janusz "Ency" Dorożyński

On Tue, May 08, 2007 at 08:28:57PM +0200, Michał Kosmulski wrote: Moim zdaniem jest to nadal niepotrzebne komplikowanie życia. Trzeba by poprawić dokładnie wszystkie istniejące disambigi. Lepiej byłoby przyjąć ujednolicony format jak ten z brudnopisu Witka1988 (który zwykle i tak intuicyjnie jest przestrzegany). Na pewno część disambigów trzeba będzie poprawić, ale mniej niż w pierwszym przypadku. Wanted -- +---------------------------------------+ | -o) http://wanted.eu.org/ | /\\ Message void if penguin violated + _\_V Don't mess with the penguin

Dnia Tue, 08 May 2007 20:28:57 +0200, Michał Kosmulski &lt;michal.kosmulski(a)netsprint.pl&gt; napisał: A ja na inny pomysł wpadłem - sprawdzanie botem netsprinta, który link wraca na stronę ujednoznaczniającą. Czyli sprawdzanie czy w artykułach docelowych jest szablon {{DisambigR}}. Wtedy bot wie, który linki są te właściwe. Można też przyjąć, że link właściwy jest pierwszy po znaku *. Chyba, że w nim nie ma {{disambigR}}-a - wtedy bot sprawdza czy drugi link (i tak do końca strony). Taki sposób ma tą zaletę, że nas zmotywuje do wstawiania {{disambigR}} do artykułów. -- Pozdrowienia || Adam Dziura || http://adas.jogger.pl Czy 10 000 małp potrafi napisać encyklopedię? http://pl.wikipedia.org A czy te małpy zwiedzają i opisują świat? http://wikitravel.org/pl/

On Tue, 8 May 2007, Michał Kosmulski wrote: ok, będzie, że szukam dziury w całym, ale przy akurat takim rozwiązaniu, wystarczy, że ktoś teraz zmodyfikuje tekst, nie modyfikując szablonu i już masz błąd... wydaje mi się, że jeśli taki szablon miałby tam być, to musi on być nie tylko pusty i obok, ale jeszcze do tego niezależny od treści, bo nie możesz wymagać od każdego, że będzie wiedział jak tego użyć... pozdrawiam, blueshade. -- | "<robT> Name ONE thing that your windows comp can do that my MAC cant | <bawss> Right click." - bash.org | \=------=| blue (at) wave460.net |=------=| http://wave460.net |=------

Pomysł jest ciekawy, dla mnie takie coś byłoby bardzo wygodne, ale obawiam się, że mogą tu paść podobne zarzuty jak względem poprzednich propozycji opierających się o szablony. Trzeba jednak przyznać, że twoje podejście ma tę zaletę, że nie zmienia w ogóle treści samych wypunktowań, czyli nie utrudnia życia osobom nie zainteresowanym. Może dałoby się nawet zrobić jakąś prostą wizualizację (typu: wąska belka zawierająca tylko listę ujednoznacznianych haseł i ułatwiająca szybką nawigację), aby przekonać więcej osób do stosowania tego szablonu. Pewną trudnością może być lista parametrów zmiennej długości, na pewno można to obsłużyć czymś w rodzaju: {{#if:{{{1|}}}|[[{{{1}}}]]|}} {{#if:{{{2|}}}|[[{{{2}}}]]|}} ... {{#if:{{{100|}}}|[[{{{100}}}]]|}} ale chyba nie byłoby to zbyt eleganckie ani wydajne. Może ktoś kto zna się na szablonach mógłby doradzić? W każdym razie (nie wycofując się z tego co napisałem pozytywnego o ustalonym formacie wypunktowań), uważam koncepcję parametrów w disambig za ciekawą. Pozdrawiam, Michał -- Michał Kosmulski (mkosmul) http://www.netsprint.pl/ http://hektor.umcs.lublin.pl/~mikosmul/

| -----Original Message----- | From: ... Stan Zurek | Sent: Wednesday, May 09, 2007 1:57 PM / | A według mnie pomysł wcale nie jest aż taki ciekawy. Ten | szablon nie jest aż tak potrzebny. Pomyślmy o tych, którzy | zajmują się edytowaniem treści a nie kodu. Disambig w obecnym | kształcie może zrobić każdy. Ale jak ktoś tylko jako tako zna | się na programowaniu, to obsługa szablonu jest dość trudna i | tylko będzie odstraszać nowicjuszy, a tego naprawdę nie chcemy. Ujednoznacznianie nie jest dla nowicjuszy. Tak jak wiele innych rzeczy, choćby parser czy tabele. Na warsztatach w Białowieży dla nowicjuszy nawet o tabelach tylko zająknąłem się. Sam ujednoznacznianie robię rzadko, choć zapewne nowicjuszem nie jestem. Może nawet z czasem to będzie odrębna wikispecjalizacja - ujednoznacznianie ;-) . Pzdr., Janusz "Ency" Dorożyński

| -----Original Message----- | From: ... Stan Zurek | Sent: Wednesday, May 09, 2007 3:08 PM / | A co w przypadku jeśli ujednoznacznienie już istnieje i | trzeba dodać pozycję (np. [[Ruch]] )? Normalnie każdy | nowicjusz może to zrobić, bo jest to dziecinnie proste. W | przypadku szablonu już tak niestety nie będzie. Dopóki będzie dziecinnie proste, to zrobi to, a jak przestanie być dziecinnie łatwe, to zostawi to fachowcom :-)) . Wiki w ogóle była dziecinnie prosta (o ile już znało się trochę hateemela) jakieś 3 lata temu. Teraz się coraz bardziej komplikuje i raczej nie ma od tego odwrotu. Tak przy okazji - oprogramowanie MW ma już około 300 rozszerzeń. | Ale to tylko moje zdanie, bo ja bym się w ogóle bardziej | zajął edycją treści niż zabawą w szablony i inne takie tam. Całkowicie popieram, dlatego mało grzebię w szablonach (zresztą i tak część jest dla mnie zablokowana) i innych takich. Pzdr., Janusz "Ency" Dorożyński

Ogólnie odpowiem na wszystko. Jak dla mnie, to w Wikipedii nie powinno znajdować się nic co nie służy Wikipedii i tutaj swojego zdania nie zmienię. Powinniśmy starać się aby jej treść była przyjazna generowaniu danych na jej podstawie, ale nie powinniśmy umieszczać w niej żadnych elementów służących jedynie innym projektom, czy jak chcecie to nazwać. Dodanie takich parametrów do szablonu disambig służyło by jedynie botowi netsprinta, bo wyświetlanie listy pod którą będzie druga lista to bezsens. A tak na marginesie, to szablonu nie trzeba by modyfikować, bo po prostu zignoruje te parametry. Stosowanie disambigR na stronach typu [[xxx (yyy)]] nie ma moim zdaniem głębszego sensu. Prędzej proponował bym je usunąć. Jeśli ktoś trafi na hasło [[Bitwa pod grunwaldem (obraz)]] to znaczy, że szukał informacji o obrazie, a nie o bitwie. Jak ktoś trafi na [[Bitwa pod grunwaldem]] to już nie wiadomo, więc o ile dobrze się orientuje disambigR służy do tego, aby mógł znaleźć też inne hasła. A co do sprawdzania listy, to chodziło mi o to, aby odrzucać błędnie wygenerowane synonimy. *[[zwierzę]] - drapieżnego [[ssak]]a to totalna skrajnośc, już bardziej na redirectach można się przejechać. A swoją drogą to ciekawe jakie rezultaty dało by generowanie na zasadzie [[(.*)|(.*)]] i pozostawieniu tych kombinacji które występują n razy, oraz odrzucenie tych, w których przypadku skrypt jest w stanie zauważyć, że są odmienionym słowem.

| -----Original Message----- | From: ... Przykuta | Sent: Wednesday, May 09, 2007 5:56 PM / | > [od Witka] | > Jak dla mnie, to w Wikipedii nie powinno znajdować się nic co nie | > służy Wikipedii i tutaj swojego zdania nie zmienię. | | Sorki, ale to Wikipedia jest dla ludzi, więc ludziom powinna | służyć... Taka mała dygresja ;) Przykuta, czy mógłbyś cytaty lepiej formatować? Bo ten powyżej musiałem sam opisać tekstem w kwadratowych nawiasach. Natomiast mnie też zainteresowało bezapelacyjne stwierdzenie o tym co służy Wikipedii. Jak i późniejsze wypowiedzi z konta Radomil ;-) . Obie zaistniały w oderwaniu od realiów, cokolwiek zrozumiałym w naszym jednak półświatku umiejącym edytować na poziomach od średniego do super zaawansowanego. Faktycznie rzecz w tych ludziach. Otóż wiki jest produktem w pierwszej kolejności do czytania - przez większość ludzkości, czyli Wikipedia ma służyć do czytania i w żadnym wypadku nie ma służyć Wikipedii (lub społeczności jej edytorów). Natomiast w drugiej kolejności Wikipedia ma być do edytowania, ale to już jest adresowane do radykalnie mniejszej liczby ludzi. To że my jesteśmy w tej grupie i nieźle się przy tym bawimy nie ma aż tak wielkiego znaczenia wobec celu pierwszego. Bo dla niego znaczenie ma nie łatwość edytowania, tylko popularność i widoczność w wyszukiwarkach, głównie w komercyjnym Googlu. Proszę obalić tezę, że popularność Wikipedia zawdzięcza jakości swojego kontentu a nie pierwszym miejscom spośród miliona wskazań (często pewnie lepszym niż wskazanie na wiki) w wynikach guglania jakiegoś słowa. Jeśli obalić się nie da, to będzie to oznaczało, że wiki jest już uwikłana w relacje w biznesem. Oczywiście można z pozycji religijnych udawać, że tak nie jest, ale z takimi osobami ja osobiście nie będę w stanie porozumieć się, gdyż uważam, że uwikłanie jest. Może nawet groźniejsze niż jestem w stanie podejrzewać. Ale póki co nie widzę powodu, aby w takiej sytuacji nie wspierać - oczywiście jeśli ma to sens i służy Wikipedii, czyli celowi pierwszemu - i współpracować z takim ciekawym rodzimym przedsięwzięciem jak choćby Netsprint. Zresztą ludzie od niego też rodzimi ;-) i sympatyczni. Pzdr., Janusz "Ency" Dorożyński

Ja się z tym zdaniem zgadzam. Wikipedia powinna być jak najbardziej przjazna użytkownikom i jak najbardziej intuicyjna. Obecnie ze smutkiem obserwujędoążenie cześci "technokratycznej" części wikipedystów. W swojej historii wikipedia zrobiła krok w dobrą strone- zastąpienie htmla kodem wiki w budowie tabel, który jestznacznie prostszy, z drugiej strony zaraz potem zrobiłą dwa kroki wstecz wprowadzając szablony warunkowe, które zniszczyły tą łatwość utrudniajac edycję tabel znacznie bardziej niż html. Każde takie posunięcie, przesuwajace jakieś "kompetencje" w tworzeniu wikipedii do poziomu "specjalistów" jest takim krokiem wstecz. Ułatwi to być moze pracę maszynom, ale utrudni ludziom. Zastanówmy się - dla kogo tworzymy Wikipedię - dla ludzi umiejących posługiwać się botami, bazami danych etc. czy dla przecietnego zjadacza chleba, którego to nie interesuje i interesować nie będzie? Każde rozwiazanie komplikujące edycję wikipedii jest odstępstwem od naczelnych zasad tego projektu. Przypominam, że systemem do którego dążymy nie jest technokracja a merytokracja. (To takie moje, laickie POV) Radomil