On 9/27/06, PIBWL <> wrote: Punktem honoru dla każdego powinno być linkowanie do haseł, a nie redirectów albo disambigów. Same redirect "ang." powstał po prostu przez lenistwo i dla wygody leniwych linkujących bo nie wyobrażam sobie aby ktoś szukał dokładnie takiego hasła... Linkowanie do stron przekierowujących wygląda brzydko i nieprofesjonalnie dlatego to także dla mnie jest "punktem honoru" aby takie śmieci wyczyścić. -- Michal Rosa

Rozumiem, że masz własne poglądy, popularne nawet, ale co do jasnej.. ma wspólnego z tym profesjonalizm? Rozumiem, że trzeba argumentowac swoje poglądy jaknajmocniej, ale wypadałoby także z sensem. Beno

On 9/27/06, Przemyslaw 'BlueShade' Idzkiewicz <> wrote: W jaki sposób wpływa to negatywnie na Wikipedię? -- Michal Rosa

On 9/27/06, Gemma <> wrote: Profesjonalnie = dobrze, porządnie, nie na skróty. -- Michal Rosa

On Wed, 27 Sep 2006, Michal Rosa wrote: nie bardzo wydumany, tylko jak najbardziej z życia wzięty - być może akurat w artykule o Athlonie taki problem nie wystąpił, ale pojawił się w przypadku komputerów Amiga i w innych - proponuję spojrzeć do wątku o Tawbocie... a jeśli nie o tym mówiłeś, to tym bardziej powinieneś to wziąć pod uwagę, bo być może w przypadku podanym przez Ciebie, linkowanie bezpośrednie jest jak najbardziej na miejscu, ale linkowanie do redirectów przydaje się w innych sytuacjach, które akurat dla Ciebie są lenistwem i pójściem na skróty, a dla innych praktyką pomagającą w sensownym organizowaniu treści wikipedii, którą krótkowzroczne osoby z podejściem "ja-wiem-lepiej" niszczą dla własnego widzimisie... chyba eot, bo widzę, że raczej nie ma sensu wskrzeszać martwej dyskusji... pozdrawiam, blueshade. -- "A breathalyzer? Was this guy serious? Those pedestrians had been extremely agile. There was no way Butch could have mowed down as many as he did if he'd been drunk." - choppingblock.org

Nadal bełkoczesz. Funkcja profesonalizmu nie oznacza, że coś jest na skróty lub nie. To są rzeczy bez związku z profesjonalnością. Wiele publikacji profesjonalnych uprawia przecież skróty. A Ty użyłes po prostu nieadekwantngo terminu. Pomiędzy profesonalizmem, a kwestią użycia skrótów (bądź ich nie użycia) nie ma po prostu relacji. Beno

Różnica jest, faktycznie. Nie sądziłem, że takie drobiazgi tak wpływają na wielkość bazy. Tak dla porządku, nie w każdym przypadku pierwszy link można zastąpić drugim - tekst linku wynika z potrzeb autora i stylu danego artykułu - ale zawsze link [[Stany Zjednoczone|Stanów Zjednoczonych]] można zastąpić [[USA|Stanów Zjednoczonych]]. Tyle, że link [[USA]] prowadzi do redira, a tego chyba nie lubimy. A co z pomysłem dymków z rozwinięciami skrótów? W tej chwili w dymkach podawana nazwa faktycznej strony, do której link prowadzi (przynajmniej w domyślnej skórce MonoBook i przy wyłączonych popupsach). Rozwiązuje to jakoś problem objaśniania skrótów w przypadku, gdy skrót jest podlinkowany, a docelowa strona ma nazwę, która jest jego rozwinięciem. Jest to co prawda pod prąd uwagi Bena powyżej, ale w przypadku skrótu ang. pięknie się sprawdza. Gorzej jest w przypadku linkowania [[Stany Zjednoczone|USA]] - informacja o znaczeniu skrótu jest, ale rozwinięcia skrótu nie ma. Czy warto zawalczyć o rozwijanie w dymkach tych skrótów, które nie są linkowane? Może po prostu przyjąć, że każdy skrót będzie linkowany? Albo przyjąć stosowanie takiego opisu skrótu jak przykładowy poniżej: [[SVG]] ([[Język angielski|ang]]. Scalable Vector Graphics) bo nie wiem, jak rozwiązać umieszczenie w dymku jednocześnie informacji o docelowej stronie linku i rozwinięcia skrótu. xywek

USA jest znane ogółowi i nie jest POV Sprawdziłem, skrócone linki + formy typu [[Wrocław|Wrocławia]] na [[Wrocław]]ia + powtórzenia linków + bezsnsowne linkowanie do kilogramów czy metrów. ponownie jak wyżej - masz jakieś testy, czy po prostu lubisz mieć swoje zdanie? Baza jest w postaci kodu, polskie znaki są w postaci trójznaków, zaawansowana typografia tak samo, nawt prose cudzysłowy. Jakbyś zobaczył w pliku ascii jak to wszystko wygląda też byś ten tekst nazwał kodem. Liczyłem łącznie wszystkie błędy, także np. nadmiar nbsp, r. zamiast roku, w. zamiast wieku, kg. zamiast kilogramów, spacje po asteriskach w listach, i wiele wiele innych rzeczy możliwych do skrócenia, w tym także oszablonownie welu powtarzających się form. (800MB) to wielkość jakiegoś nieskompresowanego dumpa a nie rzeczywistej bazy. Za to sporo miejsca zajmują strony dyskusji! Wniosek - mniej gadać po próżnicy ;-> Tak, dump z artykułów. Z dyskusjami byłoby znacznie więcej. Skompresowane achiwum ma 160 MB, ale baza działająca na serwerze ma na pewno więcej niż jej dump. Beno

Jimbo tradycyjnych W tradycyjnym czystym pliku ASCII widać tylko tekst, a tu widać więcej kodu - zarówno znaki formatuuące jak i unikode. A co do skrótów, to nie chodzi tutaj o miejsce, tylko bardziej jeszcze o czytelność. Zresztą abrewiacje wymyślono już wieki temu, i to nie tylko dla oszczędności. Podobnie jak ligatury. A wszystko to właśnie dla czytelności składu. Problem miejsca jest i był drugorzędny (choć nie bez znaczenia). Beno

Dnia czwartek, 28 września 2006 11:41, Gemma napisał: Pierwszy przykład z linkiem do Wrocławia i powtórzenia linków to błędy edytorskie a nie kwestia "poprawnego" wyboru czy troski o serwery. Co do linkowania jednostek uważam, że nie zawsze, ale jednak dość często ich linkowanie ma sens. Właśnie obejrzałem plik bazy. Da się czytać :) bez MySQL. Wewnątrz zwyczajny nieskompresowany wikitekst, poza znaczkami z ogonkami. Polskie znaki są w bazie zapisane w UTF-8 (dwa bajty na znak). Tak mam w mojej prywatnej wiki na silniku 1.66. W dumpie bazy znaczki z ogonkami rzeczywiście są zapisane 3 bajtami. Ale dump to przecież nie jest to, co jest zapisane w bazie! Sugerujesz, że wszystkie znaki typograficzne, również te z zestawu podstawowego ANSI, jak np.: wspomniany prosty cudzysłów: " są zamieniane w coś innego, na przykład w jakieś UTF czy html entities? Mam u siebie 1.66, Wikipedia działa już na 1.8a, ale strzelam w ciemno, że kropka jest kropką a cudzysłów cudzysłowem, podobnie jak inne znaki z ASCII. Boty do roboty? Poprawienie tych błędów nie zmniejszy bazy, tylko ją zwiększy - wzrośnie historia. Teksty w bazie nie są skompresowane bo to oczywiście zabiłoby wydajność serwera. Na wielkość bazy danych decydujący wpływ ma historia edycji, czyli sam mechanizm wiki. Moja baza w stosunku do dumpa to relacja 10:1. Tak, zdziwiłem się tym. Pytanie: czy jest to zależność liniowa. Pliki bazy, z tego co widzę, są nudne - mnóstwo zer. O bazie Wikipedii nie wypowiem się z oczywistych przyczyn - nie widziałem jej pliku. Może ktoś ma inną dużą bazę MySQL i mógłby porównać plik(i) /var/lib/mysql/ibdata* z dumpem zawartej w nich bazy? Wnioski mam takie: żeby odchudzić serwery należałoby przede wszystkim pozbyć się lub odłożyć gdzieś "na półkę" historię edycji oraz ;) pisać krótkie artykuły najlepiej ich później nie modyfikując. Wpływ linków lub wielokrotnych enterów na wielkość bazy jest znikomy. pzdr LukMak

zwiększy - wzrośnie historia. Nie we wszystkich zadaniach dla takiego bota panuje jednomyślność Wikipedystów, ale przydałby się systemowy bot na serwerze robiący niektóre rzeczy przy zapisywaniu każdej edycji: - kasowanie wszystkich (nawet wielokrotnych) spacji i tabulatorów na końcu linijki, czyli tak napawdę na końcu akapitu. - redukowanie pustych wierszy do max. dwóch - poprawki typu "== Linki Zewnetrzne ==" na "==Linki zewnętrzne==" itd. Beno

From: "makar" &lt;makaraj(a)tlen.pl&gt; G> - poprawki typu "== Linki Zewnetrzne ==" na "==Linki zewnętrzne==" Czy mi się śniło czy kiedyś było zalecenie aby tą pierwszą formę stosować? A jaki byłby sens? Przecież to nieortograficznie (z dwu powodów zresztą). Beno

Zalecenie musi zawsze być czymś uzasadnione. Tu brak dwóch spacji da dwa bajty mniej na serwerze i 1 milisekundę szybciej pracy. Argument przestaje być śmieszny po przeliczeniu na skalę globalną. Zalecenia dla przeciwnej wersji znaleźć nie potrafię. Beno

| -----Original Message----- | From: ... makar | Sent: Tuesday, October 03, 2006 11:30 AM / | Jasne, mnie się o spacje rozdzielające rozchodziło. Teraz już wiem :-)) , ale mógłbyś od razu .... Pzdr., janusz 'Ency' Dorożyński

Dnia wtorek, 3 października 2006 11:35, Gemma napisał: Beno dalej prowadzisz tą nonsensowną krucjatę? Daj spokój. Teza: Spacji po/przed "==" być nie powinno. Znaki "==" służą do sformatowania tekstu tytułów, nie wiem jak to się nazywa w języku zecerów czy innych łamaczy. To co między znakami "==" jest tytułem. Czy jakiś tytuł zaczyna się lub kończy spacją? Nie. Zatem spacji między "==" a tekstem być nie powinno. pzdr LukMak

Witam 2006-10-13 PB: P> [ było o tym, czy w nagłówkach robić ==tak==, czy == tak == ] P> ... po P> naciśnięciu "+" w celu wpisania nowego punktu dyskusji, oprogramowanie P> automatycznie marnuje te dwa bajty, bo nagłówki robi == tak ==. Czyli żem se tego niewyśnił :-) P> Co P> więcej, dodaje jeszcze jeden bajt, bo robi linijkę odstępu pod nagłówkiem. Jeśli o ten bajt idzie to ja dodaję go zawsze. Tekst jest bardziej czytelny w edycji. makar -- pozdrawiam Andrzej Makarczuk

Witam 2006-10-13 Gemma: G> To źle robisz, bo większym problemem jest szczupłość miejsca w okienku G> edycyjnym, Dla Ciebie. Dla mnie większym problemem jest zorientowanie się gdzie mam się wpisywać. Puste linie dzielą zauważalnie tekst do edycji. Inne wymyślne gwiazdki, hasze itp sa znacznie mniej zauważalne IMHO. G> ... Czysta ergonomia. No właśnie. Otwieram do poprawy art. Załóżmy, że poprawki są do zrobienia w kilku sekcjach czyli otwieram cały artykuł. I teraz przewijając w okienku edycji bez skrupulatnego wczytywania się w ciągłą szpaltę tekstu znaleźć miejsc do poprawki nie mogę. A jak sekcje mam rozdielone pustumi liniami to spoko luzik :-) Czytelność kodu, puste linie, komentarze itp to przecież zalecenie edycyjne. Tak mnie w kazdym razie uczono... BTW Rozmiar okienka edycji można sobie zmieniać ;-) makar -- pozdrawiam Andrzej Makarczuk

Gemma wrote: [...] W preferencjach, ale to ograniczone zmiany są. Stu linijek nie dostaniesz, ale o ileś tam udaje się to wydłużyć. Rozszerzyć mi się nie udało. Bansp

| -----Original Message----- | From: ... PB | Sent: Friday, October 13, 2006 3:42 PM / | W preferencjach, ale to ograniczone zmiany są. Stu linijek | nie dostaniesz, ale o ileś tam udaje się to wydłużyć. Ja dostałem i 50, i 100 i 200, więcej nie próbowałem, zresztą wiecej niż fizyczny ekran nie ma specjalnie sensu. | Rozszerzyć mi się nie udało. To znaczy w ogóle nie reaguje na ten parametr. Ja przy domyślnej wielkości 80 kolumn miałem 130, wprowadenie wartości 40 nic nie zmieniło. Używam W'XPSP2/FF1.5.0.7 Pzdr., Janusz 'Ency' Dorożyński