Ups, sorry za maila bez tematu :)
2010/3/25 Agnieszka Kwiecien agnieszka.kwiecien@gmail.com:
Cześć,
Czy jest na polskiej Wikipedii jakaś instrukcja z wyjaśnieniem jak definiować przypisy wewnątrz tagu <references>? Nie znalazłam o tym nic na stronie pomocy:
http://pl.wikipedia.org/wiki/Pomoc:Przypisy
Był kiedyś taki wątek na tej liście, ale chyba rozeszło się po kościach. Ja cały czas dodaję przypisy po staremu, w treści, a chętnie przestawię się na bardziej przyjazną metodę.
Pozdrawiam,
Nova, Agnieszka Kwiecień
WikiPL-l mailing list WikiPL-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikipl-l
Dnia 25-03-2010 o godz. 9:41 Agnieszka Kwiecien napisał(a):
Ups, sorry za maila bez tematu :)
2010/3/25 Agnieszka Kwiecien agnieszka.kwiecien@gmail.com:
Cześć,
Czy jest na polskiej Wikipedii jakaś instrukcja z wyjaśnieniem jak definiować przypisy wewnątrz tagu <references>? Nie znalazłam o tym nic na stronie pomocy:
http://pl.wikipedia.org/wiki/Pomoc:Przypisy
Był kiedyś taki wątek na tej liście, ale chyba rozeszło się po kościach. Ja cały czas dodaję przypisy po staremu, w treści, a chętnie przestawię się na bardziej przyjazną metodę.
http://en.wikipedia.org/wiki/Help:Footnotes#List-defined_references
Tylko co do pierwszego przykladu to powinien dzialac - nie wiem jednak co z drugim (tym z "reflist" bo nie wiem czy jest odpowiednik na polskiej wiki.
Osobiscie mi sie nie podoba bo trzeba edytowac CALE haslo zeby wprowadzac takie zmiany - jezeli edytujemy tylko jeden naglowek wszystkie zmiany dotyczace przypisow trzeba wprowadzac na slepo.
Ostatnio zdarzylo mi sie edytowac Okrety podwodne typu Los Angeles i edytowalem to na trzy razy tyle jest tekstu. Dlatego nie podoba mi sie idea ze jakies rozwiazanie uniemozliwia edytowanie paragrafow zmuszajac do edytowania calosci.
PMG
Osobiscie mi sie nie podoba bo trzeba edytowac CALE haslo zeby wprowadzac takie zmiany - jezeli edytujemy tylko jeden naglowek wszystkie zmiany dotyczace przypisow trzeba wprowadzac na slepo.
Niekoniecznie - nie powinno być problemów z przypisami których nie trzeba ruszać. A co do tych które trzeba zmienić - wystarczy w drugiej zakładce otworzyć pełny artykuł i zobaczyć która nazwa skrótowa przypisu do czego się odnosi. Z dwojga złego już wolę ten skrótowy system, niż taki w którym {{cytuj pismo}} z 10 autorami zajmuje więcej miejsca niż samo zdanie do którego się odnosi.
Żeby to jeszcze było kolorowanie składni to byłoby do przełknięcia, ale tak to jest to bardzo niestrawne - szczególnie dla nowicjuszy.
Z tych kilku emaili wynika, że na dzień dzisiejszy każdy stosuje co i jak mu się podoba. Czy nie powinniśmy w końcu wprowadzić jakiegoś ujednolicenia w tym temacie? Problem będzie się tylko pogarszał z czasem...
Pozdrawiam
Zureks
Z dwojga złego już wolę ten skrótowy system, niż taki w którym {{cytuj pismo}} z 10 autorami zajmuje więcej miejsca niż samo zdanie do którego się odnosi.
Moglbys podac z pamieci choc jedno miejsce gdzie autorow jest wicej niz 3 ? Ja moglbym podac wiecej niz jedno miejsce gdzie cytuj strone sklada sie z dokladnie 5 parametrow - z ktorych oczywiscie najdluzszym jest adres samej strony.
Wiec bez przesady.
PMG
Moglbys podac z pamieci choc jedno miejsce gdzie autorow jest wicej niz 3 ?
Ależ proszę bardzo - pierwszy lepszy przykład z brzegu, przypis nr 16 w:
http://pl.wikipedia.org/wiki/Efekt_cieplarniany
Zdanie wygląda tak:
W artykule opublikowanym w 2008 w PNAS dyskutowane są oceny stężenia dwutlenku węgla wykonane na podstawie zagęszczenia porów liści w latach 1000–1500 naszej ery[16].
a przypis do niego tak:
Thomas B. van Hoof, Friederike Wagner-Cremer, Wolfram M. Kürschner, and Henk Visscher, A role for atmospheric CO2 in preindustrial climate forcing, Proceedings of the National Academy of Sciences of the United States of America, 105, 41, 15815-15818, doi: 10.1073/pnas.0807624105
Polecam również w tym samy artykule przypisy np. 10, 22 i 32 - zajmują również kilka linijek.
Inne artykuły są jeszcze gorsze - w kolejnym przykładzie:
http://pl.wikipedia.org/wiki/Globalne_ocieplenie
przypis 60 do zdania:
Badacze w podsumowaniu są jednak zgodni, że nawet ze zwiększoną wrażliwością klimatyczną na promieniowanie słoneczne, większość ocieplenia od połowy XX wieku jest prawdopodobnie związana ze wzrostem stężenia gazów cieplarnianych, a wpływ Słońca na ocieplenie oszacowali na 16% lub 36%[60].
to
Peter A. Stott, i inni. Do Models Underestimate the Solar Contribution to Recent Climate Change?. „Journal of Climate”. Tom 16, 2003-12-03. nr 24. Ss. 4079-4093. Cytat: "Even with such an enhanced climate response to solar forcing, most warming over the last 50 yr is likely to have been caused by increases in greenhouse gases. Indeed we estimate that increases in greenhouse gases were likely to have caused more warming than observed, with a significant cooling trend from the direct and indirect effects of sulfate aerosols counterbalancing the combined warming effects from greenhouse gases and changes in solar irradiance. The best estimate of the warming from solar forcing is estimated to be 16% or 36% of greenhouse warming depending on the solar reconstruction."
I życzę powodzenia każdemu, kto będzie chciał edytować tą kobyłę ze 143 przypisami, które u mnie wyświetlają się jako 4 (cztery) strony bitego tekstu, a w samym haśle większość refów edytowana jest jako:
===== Artykuł z [[2007]] wykazuje brak istotnego związku pomiędzy padającym na Ziemię promieniowaniem kosmicznym, a [[zachmurzenie]]m i temperaturą w ciągu ostatnich 20 lat<ref> {{Cytuj stronę |autor =Richard Black |url =http://news.bbc.co.uk/2/hi/science/nature/7327393.stm |tytuł ='No Sun link' to climate change |praca = |opublikowany =[[BBC]] News Online |data =2008-04-03 |data dostępu =23 maja 2008 |język =en }} </ref><ref> {{Cytuj pismo |nazwisko=Sloan |imię=T |nazwisko2=Wolfendale |imię2=A. W |tytuł=Testing the proposed causal link between cosmic rays and cloud cover |czasopismo=Environmental Research Letters |oznaczenie=Tom 3, 2008-04-03 |strony=1-6 |url=http://www.iop.org/EJ/abstract/1748-9326/3/2/024001/ }} ===== bo przecież inaczej nie sposób tego ogarnąć okiem - wyobraź sobie to pisane ciurkiem i spróbuj edytować. A teraz wyobraź sobie że wiesz sporo na temat hasła a nie masz zielonego pojęcia o wikikodzie i wtedy spróbuj edytować...
Pozdrawiam
Zureks
bo przecież inaczej nie sposób tego ogarnąć okiem - wyobraź sobie to pisane ciurkiem i spróbuj edytować. A teraz wyobraź sobie że wiesz sporo na temat hasła a nie masz zielonego pojęcia o wikikodzie i wtedy spróbuj edytować...
Pozdrawiam
Zureks
A ja mam inny problem:
http://pl.wikipedia.org/w/index.php?title=Globalizacja&action=edit
Z chęcią bym to pozamieniał na refname, bo korzystałem tylko z kilku publikacji (definicje bywają różne, więc dla NPOV jedna bynajmniej nie wystarczająca) ale w każdym przypisie inne strony. Gdyby dało się jeszcze to sparametryzować na zasadzie op. cit. czyli <ref name = "opcit:xxx; s:23"> <ref name = "opcit:xxx; s=25-28"> to już byłoby o niebo lepiej. O polonizacji taga nie wspominając :)
przykuta
A ja mam inny problem:
http://pl.wikipedia.org/w/index.php?title=Globalizacja&action=edit
Z chęcią bym to pozamieniał na refname, bo korzystałem tylko z kilku publikacji (definicje bywają różne, więc dla NPOV jedna bynajmniej nie wystarczająca) ale w każdym przypisie inne strony. Gdyby dało się jeszcze to sparametryzować na zasadzie op. cit. czyli <ref name = "opcit:xxx; s:23"> <ref name = "opcit:xxx; s=25-28"> to już byłoby o niebo lepiej. O polonizacji taga nie wspominając :)
"Opcita" to raczej kiepsko widzę, ale z polonizacją taga to może dałoby przynajmniej nieco poprawić - może jakoś tak (?):
http://pl.wikipedia.org/wiki/Szablon:%C5%B9r%C3%B3d%C5%82o
{{Szablon:Źródło}}
Pozdrawiam
Zureks
2010/3/25 Przykuta przykuta@o2.pl:
bo przecież inaczej nie sposób tego ogarnąć okiem - wyobraź sobie to pisane ciurkiem i spróbuj edytować. A teraz wyobraź sobie że wiesz sporo na temat hasła a nie masz zielonego pojęcia o wikikodzie i wtedy spróbuj edytować...
Pozdrawiam
Zureks
A ja mam inny problem:
http://pl.wikipedia.org/w/index.php?title=Globalizacja&action=edit
Z chęcią bym to pozamieniał na refname, bo korzystałem tylko z kilku publikacji (definicje bywają różne, więc dla NPOV jedna bynajmniej nie wystarczająca) ale w każdym przypisie inne strony. Gdyby dało się jeszcze to sparametryzować na zasadzie op. cit. czyli <ref name = "opcit:xxx; s:23"> <ref name = "opcit:xxx; s=25-28"> to już byłoby o niebo lepiej. O polonizacji taga nie wspominając :)
przykuta
WikiPL-l mailing list WikiPL-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikipl-l
Jak się uprzeć to można użyć parametru group który jest zastosowany np. tu: http://pl.wikipedia.org/wiki/Pierwsze_Damy_Stan%C3%B3w_Zjednoczonych do oddzielenia przypisów i adnotacji. Zdefiniować że jedna pozycja to grupa "a" druga "b" i mamy przypisy a1,a2,b1,b2,b3 itd.
Plushy
Jak się uprzeć to można użyć parametru group który jest zastosowany np. tu: http://pl.wikipedia.org/wiki/Pierwsze_Damy_Stan%C3%B3w_Zjednoczonych do oddzielenia przypisów i adnotacji. Zdefiniować że jedna pozycja to grupa "a" druga "b" i mamy przypisy a1,a2,b1,b2,b3 itd.
Plushy
Niezupełnie - w tym przypadku a1, a2, to ten sam przypis, a jak są to inne strony w książce to już nie to samo.
przykuta
2010/3/25 Przykuta przykuta@o2.pl:
Jak się uprzeć to można użyć parametru group który jest zastosowany np. tu: http://pl.wikipedia.org/wiki/Pierwsze_Damy_Stan%C3%B3w_Zjednoczonych do oddzielenia przypisów i adnotacji. Zdefiniować że jedna pozycja to grupa "a" druga "b" i mamy przypisy a1,a2,b1,b2,b3 itd.
Plushy
Niezupełnie - w tym przypadku a1, a2, to ten sam przypis, a jak są to inne strony w książce to już nie to samo.
przykuta
Chodziło mi o coś takiego: http://pl.wikipedia.org/wiki/Wikipedysta:Plushy/brudnopis/przypisy
Plushy
Jak się uprzeć to można użyć parametru group który jest zastosowany np. tu: http://pl.wikipedia.org/wiki/Pierwsze_Damy_Stan%C3%B3w_Zjednoczonych do oddzielenia przypisów i adnotacji. Zdefiniować że jedna pozycja to grupa "a" druga "b" i mamy przypisy a1,a2,b1,b2,b3 itd.
Plushy
Niezupełnie - w tym przypadku a1, a2, to ten sam przypis, a jak są to inne strony w książce to już nie to samo.
przykuta
Chodziło mi o coś takiego: http://pl.wikipedia.org/wiki/Wikipedysta:Plushy/brudnopis/przypisy
Niegłupie to, ale trzeba by to jakoś zszablonować bo się ciężko połapać z tymi grupami.
Zureks
Nie dość, że refy to jeszcze szablony. Nie za dużo tego dobrego. Nie rozumiem jak szablony mogą być prostsze od zwykłego znacznika. O ile w refie wystarczy wpisać "z palca" zawartość, to w przypadku szablonów wymaga się, aby każdy korzystający znał jego wywołania, co dla znacznej części osób "nietechnicznych" jest nie do przejścia. PA
25-03-10, Stan Zurek zureks@gmail.com napisał(a):
Jak się uprzeć to można użyć parametru group który jest zastosowany np. tu: http://pl.wikipedia.org/wiki/Pierwsze_Damy_Stan%C3%B3w_Zjednoczonych do oddzielenia przypisów i adnotacji. Zdefiniować że jedna pozycja to grupa "a" druga "b" i mamy przypisy a1,a2,b1,b2,b3 itd.
Plushy
Niezupełnie - w tym przypadku a1, a2, to ten sam przypis, a jak są to inne strony w książce to już nie to samo.
przykuta
Chodziło mi o coś takiego: http://pl.wikipedia.org/wiki/Wikipedysta:Plushy/brudnopis/przypisy
Niegłupie to, ale trzeba by to jakoś zszablonować bo się ciężko połapać z tymi grupami.
Zureks
WikiPL-l mailing list WikiPL-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikipl-l
Nie dość, że refy to jeszcze szablony. Nie za dużo tego dobrego. Nie rozumiem jak szablony mogą być prostsze od zwykłego znacznika. O ile w refie wystarczy wpisać "z palca" zawartość, to w przypadku szablonów wymaga się, aby każdy korzystający znał jego wywołania, co dla znacznej części osób "nietechnicznych" jest nie do przejścia. PA
więc uważasz, że to rozwiązanie:
http://pl.wikipedia.org/w/index.php?title=Globalizacja&action=edit
jest lepsze od tego:
Chodziło mi o coś takiego: http://pl.wikipedia.org/wiki/Wikipedysta:Plushy/brudnopis/przypisy
?
przykuta
więc uważasz, że to rozwiązanie:
http://pl.wikipedia.org/w/index.php?title=Globalizacja&action=edit
jest lepsze od tego:
Chodziło mi o coś takiego: http://pl.wikipedia.org/wiki/Wikipedysta:Plushy/brudnopis/przypisy
?
Tak, tak uważam. To pierwsze trzyma jakiś standard. To drugie jest radosną twórczością (zwykłym ORem) niestosowanym nigdzie indziej, a przez to także nieintuicyjnym. Ja, mając od nastu lat do czynienia z pozycjami posiadającymi przypisy dopiero po chwili załapałem o co chodzi. A czy zrozumie to czytający nie znający się na cytowaniu... nie sądzę. PA
Chodziło mi o coś takiego: http://pl.wikipedia.org/wiki/Wikipedysta:Plushy/brudnopis/przypisy
Plushy
Wrzuć tu, żeby nie zapomnieć:
http://pl.wikipedia.org/wiki/Dyskusja_pomocy:Przypisy
im mniej kodu, tym lepiej
Warto przedyskutować, czy nie dać jako zalecenia dla sytuacji, w której mamy wiele stron, a mało pozycji bibliograficznych :)
przykuta
Dnia 25-03-2010 o godz. 13:01 Przykuta napisał(a):
Jak się uprzeć to można użyć parametru group który jest zastosowany np. tu:
http://pl.wikipedia.org/wiki/Pierwsze_Damy_Stan%C3%B3w_Zjednoczonych
do oddzielenia przypisów i adnotacji. Zdefiniować że jedna pozycja to grupa "a" druga "b" i mamy przypisy a1,a2,b1,b2,b3 itd.
Plushy
Niezupełnie - w tym przypadku a1, a2, to ten sam przypis, a jak są to inne strony w książce to już nie to samo.
Wydaje mi się (zastrzelcie mnie ale nie mogę tego sprawdzić przy moich transferach) że jest coś takiego na en.wiki jak harwardzki styl przypisów czy coś takiego.
Wtedy piszę się (chyba - piszę z pamięci) {{przypis|nazwa_przypisu|strona}} czyli {{przypis|Klimczyk|39}}. Jak ktoś może poszukać tego na en.wiki to może się potwierdzi.
PMG
Wydaje mi się (zastrzelcie mnie ale nie mogę tego sprawdzić przy moich transferach) że jest coś takiego na en.wiki jak harwardzki styl przypisów czy coś takiego.
Wtedy piszę się (chyba - piszę z pamięci) {{przypis|nazwa_przypisu|strona}} czyli {{przypis|Klimczyk|39}}. Jak ktoś może poszukać tego na en.wiki to może się potwierdzi.
To się stosuje w tekście, a nie jako przypisy (footnoty) PA
W dniu 2010-03-25 13:21, Paelius pisze:
Wydaje mi się (zastrzelcie mnie ale nie mogę tego sprawdzić przy moich transferach) że jest coś takiego na en.wiki jak harwardzki styl przypisów czy coś takiego.
Wtedy piszę się (chyba - piszę z pamięci) {{przypis|nazwa_przypisu|strona}} czyli {{przypis|Klimczyk|39}}. Jak ktoś może poszukać tego na en.wiki to może się potwierdzi.
To się stosuje w tekście, a nie jako przypisy (footnoty)
Tak mi się przypomniało - miał być zreformowany interfejs przez Wikię, TOR coś o tym opowiadał ze 2 lata temu. A jak to wygląda teraz, wie ktoś?
Przypisy siłą rzeczy zaciemniają tekst i będzie ich coraz więcej - w odróżnieniu od infoboksów, które były dla nas problemem i nadal straszą nowych użytkowników, ale są tylko na początku hasła. Przydałaby się metoda ich ukrywania w widoku domyślnym.
W dniu 25 marca 2010 13:30 użytkownik Daniel Koć kocio@linuxnews.pl napisał:
W dniu 2010-03-25 13:21, Paelius pisze:
Wydaje mi się (zastrzelcie mnie ale nie mogę tego sprawdzić przy moich transferach) że jest coś takiego na en.wiki jak harwardzki styl przypisów czy coś takiego.
Wtedy piszę się (chyba - piszę z pamięci) {{przypis|nazwa_przypisu|strona}} czyli {{przypis|Klimczyk|39}}. Jak ktoś może poszukać tego na en.wiki to może się potwierdzi.
To się stosuje w tekście, a nie jako przypisy (footnoty)
Tak mi się przypomniało - miał być zreformowany interfejs przez Wikię, TOR coś o tym opowiadał ze 2 lata temu. A jak to wygląda teraz, wie ktoś?
Wikia reformuje - ale tylko swojego forka MediaWiki. Starczy wejść na dowolną Wikię, żeby zobaczyć ich intrefejs :-)
Pracuje też "usuability project" - którego wyniki pracy można oceniać włączając różne nowe gadżety i przechodząc na wersję beta. Problem w tym, że nawet jeśli zmieni się MediaWiki to ogromna część utrudnień dla newbies to jest nasze dzieło - to znaczy dzieło społeczności projektów i na to, żeby to inaczej było muszą zapracować same społeczności. W dodatku deweloperzy MediaWiki nie mogą zmieniać wielu mechanizmów, to znaczy muszą to robić tak, żeby stare rozwiązania też działały. A jak działają to wielu je siłą rozpędu i przyzwyczajenia wciąż stosuje i to się tak niestety ciągnie, a cały system zmian ma bardzo dużą inercję.
W dniu 2010-03-25 13:57, Tomasz Ganicz pisze:
Tak mi się przypomniało - miał być zreformowany interfejs przez Wikię, TOR coś o tym opowiadał ze 2 lata temu. A jak to wygląda teraz, wie ktoś?
Wikia reformuje - ale tylko swojego forka MediaWiki. Starczy wejść na dowolną Wikię, żeby zobaczyć ich intrefejs :-)
A więc jednak fork. No, nietopsz...
Pracuje też "usuability project" - którego wyniki pracy można oceniać włączając różne nowe gadżety i przechodząc na wersję beta. Problem w
Już dawno ta beta jest - jak wynikło ze statystyk większość ją polubiła, a ona załatwia tylko kwestie dookoła tekstu. Czy to będzie tak jak z GMailem (światowy wzorzec wiecznej bety)? Niech przynajmniej to wdrożą jako produkcyjną kiedyś.
tym, że nawet jeśli zmieni się MediaWiki to ogromna część utrudnień dla newbies to jest nasze dzieło - to znaczy dzieło społeczności projektów i na to, żeby to inaczej było muszą zapracować same społeczności. W dodatku deweloperzy MediaWiki nie mogą zmieniać wielu
W wypadku (plus-minus) graficznej edycji tekstu to społeczności nie mają chyba specjalnego wpływu - to po prostu zaszłość historyczna, że się edytuje wszystkie znaczniki jedynie ręcznie. To jest w moim mniemaniu dość duży i oczywisty problem do zajęcia się na już.
Wiadomo, że efekty nie będą jutro, bo banalne to nie będzie, to chociaż żeby był jakiś horyzont czasowy rozwiązania.
W dniu 25 marca 2010 15:01 użytkownik Daniel Koć kocio@linuxnews.pl napisał:
W dniu 2010-03-25 13:57, Tomasz Ganicz pisze:
Tak mi się przypomniało - miał być zreformowany interfejs przez Wikię, TOR coś o tym opowiadał ze 2 lata temu. A jak to wygląda teraz, wie ktoś?
Wikia reformuje - ale tylko swojego forka MediaWiki. Starczy wejść na dowolną Wikię, żeby zobaczyć ich intrefejs :-)
A więc jednak fork. No, nietopsz...
No fork - ale na GPL (inaczej zresztą być nie może) - a deweloperzy fundacyjni i wikiowi są z sobą w kontakcie :-) Niektóre funkcjonalności wikii są jednak niepotrzebne dla projektów Wikimedia (np: lepsze mechanizmy wyświetlania reklam) i vice versa.
http://www.mediawiki.org/wiki/Category:Extensions_by_Wikia,_Inc.
http://dev.wikia.com/wiki/Main_Page
Pracuje też "usuability project" - którego wyniki pracy można oceniać włączając różne nowe gadżety i przechodząc na wersję beta. Problem w
Już dawno ta beta jest - jak wynikło ze statystyk większość ją polubiła, a ona załatwia tylko kwestie dookoła tekstu. Czy to będzie tak jak z GMailem (światowy wzorzec wiecznej bety)? Niech przynajmniej to wdrożą jako produkcyjną kiedyś.
Beta się cały czas stopniowo zmienia na razie :-) Pewnie produkcyjna będzie na końcu, choć słyszałem, że skórka wikimediowa ma być celowo inna od produkcyjnej - po to żeby nie było tak jak teraz - że każda "goła" wiki na MediaWiki przypomina "na dzień" dobry Wikipedię, bo wersja produkcyjna używa monobooka jako standardową skórkę.
Zresztą ta wersja MediaWiki na której chodzą projekty Wikimedia to też już w zasadzie jest fork - bo są tam podobno różne rzeczy, których nie ma w wersji produkcyjnej, choć odstępstwa nie są duże.
Wiadomo, że efekty nie będą jutro, bo banalne to nie będzie, to chociaż żeby był jakiś horyzont czasowy rozwiązania.
No niby jest - do końca działania Usability project:
http://usability.wikimedia.org/wiki/Wikipedia_Usability_Initiative/Project_S...
W dniu 2010-03-25 15:16, Tomasz Ganicz pisze:
No fork - ale na GPL (inaczej zresztą być nie może) - a deweloperzy fundacyjni i wikiowi są z sobą w kontakcie :-) Niektóre funkcjonalności wikii są jednak niepotrzebne dla projektów Wikimedia (np: lepsze mechanizmy wyświetlania reklam) i vice versa.
Jestem FLOSS-owcem, samo słowo "fork" mnie nie przeraża =} , ale przy braku zauważalnych efektów zabrzmiało właśnie jak "my już nic, a oni poszli we własną stronę". Znacznie lepiej by mi brzmiało: "pracujemy razem nad tym w MW, a Wikia robi do tego własne dodatki".
Beta się cały czas stopniowo zmienia na razie :-) Pewnie produkcyjna będzie na końcu, choć słyszałem, że skórka wikimediowa ma być celowo inna od produkcyjnej - po to żeby nie było tak jak teraz - że każda "goła" wiki na MediaWiki przypomina "na dzień" dobry Wikipedię, bo wersja produkcyjna używa monobooka jako standardową skórkę.
W takim razie nieźle. Jeśli to ma być do (praktycznie już osiągniętego - marzec 2010 właśnie mija) końca tego projektu, to bardzo się cieszę.
Domyślam się oczywiście, że koniec tego projektu to faktycznie tylko zakończenie procesu formowania się działu pracującego nad tymi zagadnieniami, a skończony czas wynika z dobrego zwyczaju rozpisywania dobrze określonego zadania na konkretne terminy.
No niby jest - do końca działania Usability project:
http://usability.wikimedia.org/wiki/Wikipedia_Usability_Initiative/Project_S...
Ale ja mówię konkretnie o graficznej edycji tekstu, a nie w ogóle usprawnieniach użyteczności, a tu z nowości to widzę tylko graficzne przechodzenie do poszczególnych sekcji - ale edycja nadal w trybie ściśle tekstowym:
http://prototype.wikimedia.org/pl.wikipedia.org
Moim zdaniem to jest najbardziej zapuszczona rzecz w projektach Wikimediów, bardziej nawet niż proces dodawanie źródeł przed BATUTĄ.
2010/3/25 Daniel Koć kocio@linuxnews.pl:
W dniu 2010-03-25 13:57, Tomasz Ganicz pisze:
Tak mi się przypomniało - miał być zreformowany interfejs przez Wikię, TOR coś o tym opowiadał ze 2 lata temu. A jak to wygląda teraz, wie ktoś?
Wikia reformuje - ale tylko swojego forka MediaWiki. Starczy wejść na dowolną Wikię, żeby zobaczyć ich intrefejs :-)
A więc jednak fork. No, nietopsz...
Chciałbym bardzo zakrzyknąć "sam jesteś fork" ;), ale nie mogę. Mogę natomiast powiedzieć: to nie do końca tak.
(Uwaga: w tekście poniżej "nasz", "nasze", etc. odnosi się do Wikia jako firmy.)
W skrócie: * nie, to nie jest klasyczny fork * ale, tak, duża część ulepszeń UX i UI zależy od naszej customowej skórki * natomiast w ograniczonym zakresie wspieramy też Monobooka i (w perspektywie) Vectora
Teraz bardziej szczegółowo:
W Wikia dla własnych potrzeb utrzymujemy oddzielne, stabilne środowisko i codebase MediaWiki, z modyfikacjami i patchami dodawanymi wedle naszych potrzeb. Staramy się jednak, aby ingerencje w tzw. "core" były minimalne i na dziś dzień ograniczają się one głównie do dodawania nowych hooków w wymaganych miescach.
Większość pracy jaką wykonujemy na codzień zamyka się w wydzielonych kawałkach kodu znanych pewnie wszystkim tutaj jako rozszerzenia (extensions). Ich kod dostępny jest publicznie pod poniższym adresem: http://trac.wikia-code.com/browser/wikia/trunk/extensions/wikia
Ponadto, nasz "core" jest uaktualniany do najnowszej stabilnej wersji MediaWiki tak szybko jak to możliwe po jej opublikowania przez zespół MediaWiki. Przy okazji tego upgrade'u sprawdzamy wszystkie nasze rozszerzenia i w miarę potrzeb poprawiamy, tak by chodziły sprawnie z najnowszą wersją softu.
Z powyższego wynika, że w teorii większość rozszerzeń przez nas pisana powinna być gotowa do wykorzystania na dowolnej instalacji MediaWiki -- tj. jeśli dane rozszerzenie nie korzysta z naszych specjalnie dodanych hooków (a 90% nie korzysta), powinno działać.
W praktyce jest jednak tak, że istnieją nie zawsze udokumentowane współzależności, oczywiste dla nas jako developerów, ale problematyczne dla potencjalnych użytkowników z zewnątrz. Czasem są to współzależności pomiędzy jednym lub więcej rozszerzeniami, często -- zależności od naszej skórki (Monaco) i ładowanych przez nią skryptów JS. Niezmiernie rzadko zdarzają się rozszerzenia wymagające infrastruktury identycznej z naszą (lwia część tych przypadków to takie, które i tak nie przydadzą się na pojedynczych wiki i zastosowanie mają tylko na wikifarmach).
O konkretne przypadki można śmiało pytać -- chętnie odpowiem, w miarę możliwości czasowych doradzę lub pomogę.
Natomiast jeśli chodzi o "reformowanie", to mówiłem wtedy, poza skórką, także o edytorze WYSIWYG -- a ten należy (a przynajmniej powinien :P) do grupy rozszerzeń niezależnych od naszych specyficznych zmian w core. Z tego co mi wiadomo, całość powinna bez problemu ruszyć na "waniliowej" MediaWiki.
Reszte kwestii UX i UI rozwiązujemy, wydaje mi się, podobnie, ucząc się od siebie na wzajem. Pamiętajcie, że potrzeby Wikipedii i Wikia jeśli chodzi o skórkę są dość różne, więc -- nic dziwnego, że pojawiają się różnice.
Pozdrawiam Łukasz 'TOR' Garczewski Wikia Technical Team
Łukasz Garczewski pisze:
Chciałbym bardzo zakrzyknąć "sam jesteś fork" ;), ale nie mogę. Mogę
Krzycz sobie, krzycz. On Wikipl-l no one can hear you scream. ;-}
Teraz bardziej szczegółowo:
Serdeczne dzięki za wiadomości! Bardzo mi brakowało aktualizacji wiadomości z tej dziedziny, choćby raz na kilka miesięcy.
Natomiast jeśli chodzi o "reformowanie", to mówiłem wtedy, poza skórką, także o edytorze WYSIWYG -- a ten należy (a przynajmniej powinien :P) do grupy rozszerzeń niezależnych od naszych specyficznych zmian w core. Z tego co mi wiadomo, całość powinna bez problemu ruszyć na "waniliowej" MediaWiki.
Fajnie, że jest i że powinna działać na waniliowej MediaWiki, ale dla mnie zasadnicze pytanie brzmi: czy Wikimedianie w ogóle planują z tym edytorem coś robić?
Ale do ciebie też mam pytanie o niego. Pamiętam (chyba jeszcze z twojego wystąpienia), że różne rzeczy poza tekstem traktujecie ostrożnie i w razie rozpoznania "niepewnych" elementów edytor przechodzi do zwykłego trybu tekstowego. Jak wygląda teraz z grubsza lista "pewnych" i "niepewnych" elementów? Do której grupy należą np. szablony typu infoboksy albo te na dole hasła (np. z filmografią albo dyskografią, współpracownikami i hasłami pokrewnymi), przypisy, sekcje itp.? Jak zaawansowane są prace i jakie są główne przeszkody i cele?
Tak sobie myślę, że jeśli nawet na Wikimediach nie zrobimy szybko WYSIWYG, to może chociaż kolorowanie składni w JavaScripcie, żeby zwykły tekst się odróżniał od przypisów, szablonów i grafik ilustrujących (jak nie są oddzielone pustym wierszem to czasem się wtapiają w tekst z szablonami)? Może też licznik akapitów dla ułatwienia poruszania sie w długich dokumentach?
Reszte kwestii UX i UI rozwiązujemy, wydaje mi się, podobnie, ucząc się od siebie na wzajem. Pamiętajcie, że potrzeby Wikipedii i Wikia jeśli chodzi o skórkę są dość różne, więc -- nic dziwnego, że pojawiają się różnice.
Cieszę się, że to tak działa. Mimo różnic w potrzebach jedno podobieństwo jest chyba jasne: nie tylko nie gryźć, ale i nie straszyć nowicjuszy. Na razie my (Wikimedia) straszymy, a przypisy będą ten stan najwyraźniej pogarszać.
2010/3/26 Daniel Koć kocio@linuxnews.pl:
Tak sobie myślę, że jeśli nawet na Wikimediach nie zrobimy szybko WYSIWYG, to może chociaż kolorowanie składni w JavaScripcie, żeby zwykły tekst się odróżniał od przypisów, szablonów i grafik ilustrujących (jak nie są oddzielone pustym wierszem to czasem się wtapiają w tekst z szablonami)?
Wiked nie widziałeś?
--leafnode
W dniu 2010-03-26 08:59, Leszek Krupiński pisze:
Wiked nie widziałeś?
Na Wikipedii et consortes? Dotąd jakoś nie. =} A tak poważnie - nie chodzi mi o samo istnienie rozwiązań, ale o plan wdrażania tego typu usprawnień do projektów Wikimediów.
Ale jak patrzę sobie tu:
http://en.wikipedia.org/wiki/Wikipedia:WIKED
to nie do końca jest czytelne - wybijają się na czerwono linki (ja bym raczej je zrobił łagodniej - np. na niebiesko), szablony są takim samym kolorem co linki (ja bym zrobił szare), ale i tak lepsze to niż wszystko ciurkiem.
Nie przypadkiem dowolny edytor kodu dla programistów ma dziś podświetlanie składni jako standard - my na Wikimediach wciąż nie umiemy się przyznać, że istnieje jakaś składnia i że to dawno nie jest już po prostu tekst. =}
W dniu 26 marca 2010 08:59 użytkownik Leszek Krupiński wiki@leon.w-wa.pl napisał:
2010/3/26 Daniel Koć kocio@linuxnews.pl:
Tak sobie myślę, że jeśli nawet na Wikimediach nie zrobimy szybko WYSIWYG, to może chociaż kolorowanie składni w JavaScripcie, żeby zwykły tekst się odróżniał od przypisów, szablonów i grafik ilustrujących (jak nie są oddzielone pustym wierszem to czasem się wtapiają w tekst z szablonami)?
Wiked nie widziałeś?
No właśnie - WikiEd to robi - można go sobie włączyć w preferencjach w zakładce gadżety. Ale WikiEd działa tylko w przeglądarkach z silnikiem mozilli i powiem szczerze, że po krótkim czasie używania go jednak go wyłączyłem, bo potwornie spowalnia edycje - jak się robi copy-paste to zachowuje formatowanie, które potem trzeba usuwać i ogólnie używanie go jest mocno uciążliwe. Ponadto czasem gubi zawartość okna edycji (choć to może tylko mój lokalny problem) - np: po kliknięciu w "podgląd" treść hasła edycji znika a podgląd jest pusty i traci się całą robotę, bo "cofinij" też nie daje dobrego efektu... Do tego jeszcze ta masa malutkich ikonek od której się dostaje oczopląsu. Fajnie by było mieć samo kolorowanie składni bez WikiEda :-)
2010/3/26 Daniel Koć kocio@linuxnews.pl:
Łukasz Garczewski pisze:
Natomiast jeśli chodzi o "reformowanie", to mówiłem wtedy, poza skórką, także o edytorze WYSIWYG -- a ten należy (a przynajmniej powinien :P) do grupy rozszerzeń niezależnych od naszych specyficznych zmian w core. Z tego co mi wiadomo, całość powinna bez problemu ruszyć na "waniliowej" MediaWiki.
Fajnie, że jest i że powinna działać na waniliowej MediaWiki, ale dla mnie zasadnicze pytanie brzmi: czy Wikimedianie w ogóle planują z tym edytorem coś robić?
Ja niezmiennie, od ponad roku, trzymam kciuki. ;) Wiem, że reszta firmy też chętnie widziałaby ten edytor na Wikipedii. Będziemy prezentować postępy na tegorocznym MediaWiki DevMeet w Berlinie, zobaczymy, może ktoś się zachwyci i sprawa ruszy.
Ale do ciebie też mam pytanie o niego. Pamiętam (chyba jeszcze z twojego wystąpienia), że różne rzeczy poza tekstem traktujecie ostrożnie i w razie rozpoznania "niepewnych" elementów edytor przechodzi do zwykłego trybu tekstowego. Jak wygląda teraz z grubsza lista "pewnych" i "niepewnych" elementów? Do której grupy należą np. szablony typu infoboksy albo te na dole hasła (np. z filmografią albo dyskografią, współpracownikami i hasłami pokrewnymi), przypisy, sekcje itp.? Jak zaawansowane są prace i jakie są główne przeszkody i cele?
Przez ostatni rok prace w tym względzie poszły mocno do przodu. Inez Korczyński i Maciej Brencz (główni programiści tego projektu) odwalili kawał dobrej roboty idącej, jak mi się wydaje, w setki godzin pracy. Nie jestem w tej chwili w stanie podać wyczerpującej listy wyjątków, po napotkaniu których edytor się poddaje, ale odpowiadając na Twoje pytanie: * infoboksy i szablony działają * są w edytorze pokazywane jako mały zielony puzel (placeholder) * po najechaniu na puzla pokazywany jest podlgąd wyglądu szablonu w dymku * po kliknięciu puzla otwiera się edytor szablonu, tj. formularz, w którym możemy zmienić jego parametry :) (jeśli ma jakieś)
W tej chwili fallback do zwykłego edytora tekstowego zdarza się w sytuacjach "bardzo dziwnych" z naszego punktu widzenia. Po powrocie z urlopu spróbuję wyciągnąć od chłopaków listę takich przypadków. Mam wrażenie, że referencje są jedną z nich, ale głowy nie dam. :)
Na pewno będziemy zmierzać w kierunku zmniejszenia tej listy. I referencje też w końcu doczekają się obsługi -- dla Wikia są mniej priorytetowe bo i mniej używane, niż na Wikipedii.
Łukasz Garczewski pisze:
Ja niezmiennie, od ponad roku, trzymam kciuki. ;) Wiem, że reszta firmy też chętnie widziałaby ten edytor na Wikipedii. Będziemy prezentować postępy na tegorocznym MediaWiki DevMeet w Berlinie, zobaczymy, może ktoś się zachwyci i sprawa ruszy.
OK, to ja też trzymam i nastawiam budzik na połowę kwietnia! =} Swoją drogą trudno mi było znaleźć link po tym skrócie nazwy:
http://meta.wikimedia.org/wiki/Wikimedia_Conference_2010/Developers%27_Works...
Kto się zajmuje kwestią ew. wdrażania WYSIWYG w projektach Wikimediów (tzn. jest w miarę decyzyjny albo inicjatywny i w związku z tym można lobbować w tej sprawie)? Niekoniecznie ktoś personalnie - może istnieje jakaś strona/podprojekt gdzie można o tym dyskutować?
Przez ostatni rok prace w tym względzie poszły mocno do przodu. Inez Korczyński i Maciej Brencz (główni programiści tego projektu) odwalili kawał dobrej roboty idącej, jak mi się wydaje, w setki godzin pracy.
Po takim wstępie skoczyłem po prostu na Wikię i obejrzałem wdrożenie produkcyjne - faktycznie już sobie radzi ze standardowymi hasłami (np. takim: http://warszawa.wikia.com/index.php?title=Dom_bez_Kant%C3%B3w&action=edi... ). Świetna robota, gratulacje!
A jak się nazywa ten podprojekt/rozszerzenie, gdzie ma stronę na której da się śledzić jego rozwój i kontaktować z autorami? Skoro mamy już ogólną orientację, to temat może znów na jakiś czas zejść z listy i toczyć się poza nią.
- infoboksy i szablony działają
- są w edytorze pokazywane jako mały zielony puzel (placeholder)
- po najechaniu na puzla pokazywany jest podlgąd wyglądu szablonu w dymku
- po kliknięciu puzla otwiera się edytor szablonu, tj. formularz, w
którym możemy zmienić jego parametry :) (jeśli ma jakieś)
Moje uwagi na gorąco do produkcyjnego WYSIWYG na Wikii:
* zwiększenie czytelności poszło za daleko, tzn. MSZ szablony powinny być normalnie widoczne, a przynajmniej rodzaj ukrywanego elementu powinien się różnić na pierwszy rzut oka, np. szablony - zielony klocek, przypisy - fioletowy itp. (nie czepiam się - pewnie to jest tylko najprostsza sensowna implementacja)
* edytor (nawet jego pasek narzędziowy) jest przetłumaczony tylko w części
* obrazek można usunąć, ale do zmodyfikowania trzeba się zarejestrować =} (może chodzi tu o modyfikację samego obrazka, ale ja tylko chciałem zmienić parametry jego wyświetlania)
* w sumie po przejściu do trybu tekstowego podświetlanie składni też by się przydało - jedno drugiego nie wyklucza, bo dlaczego ułatwiać życie tylko niezaawansowanym?...
referencje też w końcu doczekają się obsługi -- dla Wikia są mniej priorytetowe bo i mniej używane, niż na Wikipedii.
Dla Wikipedii to w tej chwili już kluczowe, ale na szczęście na produkcji już wstępnie działają - tzn. są ukrywane i nie powodują wypadu do trybu tekstowego. Edytować trzeba nadal tradycyjnie, ale i tak spełnia to zasadniczy postulat czytelności i niestraszenia początkujących.
Jak się uprzeć to można użyć parametru group który jest zastosowany np. tu: http://pl.wikipedia.org/wiki/Pierwsze_Damy_Stan%C3%B3w_Zjednoczonych do oddzielenia przypisów i adnotacji. Zdefiniować że jedna pozycja to grupa "a" druga "b" i mamy przypisy a1,a2,b1,b2,b3 itd.
Plushy
Niezupełnie - w tym przypadku a1, a2, to ten sam przypis, a jak są to inne strony w książce to już nie to samo.
przykuta
Chodziło mi o coś takiego: http://pl.wikipedia.org/wiki/Wikipedysta:Plushy/brudnopis/przypisy
Niegłupie to, ale trzeba by to jakoś zszablonować bo się ciężko połapać z tymi grupami.
Nie dość, że refy to jeszcze szablony. Nie za dużo tego dobrego. Nie rozumiem jak szablony mogą być prostsze od zwykłego znacznika. O ile w refie wystarczy wpisać "z palca" zawartość, to w przypadku szablonów wymaga się, aby każdy korzystający znał jego wywołania, co dla znacznej części osób "nietechnicznych" jest nie do przejścia. PA
Popieram. Moim zdaniem spokojnie wystarcza jeżeli stosuje się zasadę że wszystkie przypisy dotyczace stron i pozycji znajdują się w zwykłych refach, a przypisy rzeczowe (uwagi, które nie są bibliografią, ale jakimiś opisami szczegółów czy coś takiego) w refgrupach.
W ten sposób przyzwyczaja się czytelnika do tego że jezeli ma w tekście
blablabla[18]. Blablabla[19].
to wie że nie musi korzystać z linków i lecieć na dół strony (no chyba że akurat chce to sprawdzić, gdzie w jakiej pozycji i na jakiej stronie zostało to napisane).
Natomiast jeżeli ma w tekście
blablabla[19]. Blablabla[uwaga 1]. Blablabla[20].
to jeżeli go interesują szczegóły to może skoczyć na dół i sprawdzić sobie co to za ciekawostkę umieścił autor hasła.
i na dole umieszcza się
== Uwagi == <references group="uwaga" />
{{przypisy}}
i zaraz wiadomo co trzeba klikać a co nie.
Bo zwykłemu czytelnikowi nic z tego że tam będą podane strony - to tylko jak ktoś będzie chciał poszerzyć wiedzę. Natomiast uwagi mogą się przydać. Dlatego moim zdaniem tak ważne jest rozdzielanie tego.
Natomiast dla edytora spokojnie może być tak:
blablabla<ref>Klimczyk, Pancerniki ...., s.19</ref> blablabla<ref>Klimczyk, Pancerniki ..., s.20</ref>.
{{przypisy}} == Bibliografia == * Klimczyk, Pancerniki, Wydawnictwo jakieś tam, Warszawa 2010
Naprawde nie uważam że taki krótki wpis jak tutaj podany jest tragedią wymagającą systemowego rozwiązania. Dla edytora podany tutaj przykład jest idealny - te przypisy będą TAKIE krótkie. A przeciętnego czytelnika nie interesuje w jaki sposób to będzie wstawione o ile będzie mógł on odróżnić uwagi od przypisów.
PMG