A jaki jest sens linkowania każdej daty i każdego roku, praktykowane w artykułach dowolnej treści? To jest jakieś zalecenie Wiki?
Wydaje mi się że jest takie zalecenie, choć linkowanie absolutnie każdej daty jest IMHO przesadą. W zdrowym wymiarze przydaje się chociażby do różnych zestawień (tego samego dnia co Wanted urodzili się: ...)
Linkowanie lat IMO zwiększa przejrzystość artykułów, ale dat dziennych to z reguły przesada, jeśli nie oznaczają czegoś istotnego.
I podobna kwestia z linkowaniem słowa "angielski" (oraz jego skrótu "ang.") często spotykane przy podawaniu angielskiego odpowiednika omawianego terminu, np.:
pamięć (ang. memory)
Co wnosi ułatwianie tym linkiem przejście do strony "Język angielski"?
Nadmiarowość, skrót jest oczywisty.
Skrót według mnie niekoniecznie jest oczywisty - nie piszemy encyklopedii tylko dla inteligentów. Nie byłoby z tym problemu, bo wszystkie prowadziłyby do redirectów ("ang", "ros.", itp), a nie do artykułów lingwistycznych, gdyby się co chwila nie ujawniał kolejny ambitny właściel bota, upierający się za punkt honoru zamieniać je na "język angielski"...
Pibwl Pozdrowienia,
Michal Derela
On 9/27/06, PIBWL <> wrote:
Skrót według mnie niekoniecznie jest oczywisty - nie piszemy encyklopedii tylko dla inteligentów. Nie byłoby z tym problemu, bo wszystkie prowadziłyby do redirectów ("ang", "ros.", itp), a nie do artykułów lingwistycznych, gdyby się co chwila nie ujawniał kolejny ambitny właściel bota, upierający się za punkt honoru zamieniać je na "język angielski"...
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ć.
On Wed, 27 Sep 2006, Michal Rosa wrote:
On 9/27/06, PIBWL <> wrote:
Skrót według mnie niekoniecznie jest oczywisty - nie piszemy encyklopedii tylko dla inteligentów. Nie byłoby z tym problemu, bo wszystkie prowadziłyby do redirectów ("ang", "ros.", itp), a nie do artykułów lingwistycznych, gdyby się co chwila nie ujawniał kolejny ambitny właściel bota, upierający się za punkt honoru zamieniać je na "język angielski"...
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...
zgodzę się, że akurat tego typu redirecty powstały przez lenistwo i że linkowanie do disambigów nie służy wygodzie czytelnika... ale nie ma moim zdaniem (poza jakimś niekoniecznie racjonalnym, wewnętrznym przymusem ujednolicania wszystkiego) rozsądnych argumentów za wymuszaniem linków do artykułów, a nie do redirectów...
Linkowanie do stron przekierowujących wygląda brzydko i nieprofesjonalnie dlatego to także dla mnie jest "punktem honoru" aby takie śmieci wyczyścić.
Ehh... możesz mi powiedzieć, w którym momencie linkowanie do stron przekierowujących wygląda brzydko i nieprofesjonalnie (bo chyba nie chodzi Ci o pół zdania "przekierowano z ...", bo to wygląda jak najbardziej normalnie i raczej nikomu nie wadzi)?
Ja wiem, że Taw swego czasu zrobił swoje i przetarł szlaki dla naśladowców, ale czasem naprawdę linkowanie do redirectów się przydaje (niekoniecznie w wypadku podanego przykładu) i poprawianie tych linków botem nie jest nikomu ani potrzebne, a wręcz może być szkodliwe (np. w przypadku, gdy redirect przekierowuje na hasło bardziej obszerne - do późniejszego doprecyzowania, i w innych podobnych sytuacjach)
Oczywiście, zdarzają się sytuacje, że takie linki do redirectów to faktycznie niczemu nie służace śmieci, ale nie jest tak zawsze i moim zdaniem, forsowanie za wszelką cenę takiego "punktu honoru" jest działaniem na szkodę wikipedii...
pozdrawiam, blueshade.
On 9/27/06, Przemyslaw 'BlueShade' Idzkiewicz <> wrote:
Oczywiście, zdarzają się sytuacje, że takie linki do redirectów to faktycznie niczemu nie służace śmieci, ale nie jest tak zawsze i moim zdaniem, forsowanie za wszelką cenę takiego "punktu honoru" jest działaniem na szkodę wikipedii...
W jaki sposób wpływa to negatywnie na Wikipedię?
On Wed, 27 Sep 2006, Michal Rosa wrote:
On 9/27/06, Przemyslaw 'BlueShade' Idzkiewicz <> wrote:
Oczywiście, zdarzają się sytuacje, że takie linki do redirectów to faktycznie niczemu nie służace śmieci, ale nie jest tak zawsze i moim zdaniem, forsowanie za wszelką cenę takiego "punktu honoru" jest działaniem na szkodę wikipedii...
W jaki sposób wpływa to negatywnie na Wikipedię?
nie wiem, czy mi się chce przytaczać po raz kolejny argumenty, które już na liście padały - wątek dotyczył Tawbota - można sobie znaleźć w archiwum...
w skrócie - istnieją redirecty (lub istniały przed interwencją Tawa), które służą temu, żeby umożliwić komuś przeczytanie związanej z danym zagadnieniem treści mimo, że nie istnieje hasło na dokładnie ten temat - czyli np. z [[Athlon XP]] na [[Athlon]]... Link kieruje na [[Athlon XP]], ale dopóki nie ma artykułu na temat [[Athlon XP]], w miejscu tym znajduje się redirect... W momencie, gdy zbierze się wystarczająco dużo informacji na ten temat, artykuł jest dzielony i redirect zamieniany na pełny artykuł... i tyle...
przypadek wydumany, ale pokazuje istotę sprawy ... i to niekoniecznie jest odosobnione zjawisko...
i nie podoba mi się stosowanie w tym przypadku retoryki typu "wygląda nieprofesjonalnie i brzydko", bo to nieprawda... i poprawianie takiego stanu rzeczy to tylko dokładanie pracy - i sobie i innym...
regards, blue.
On 9/27/06, Przemyslaw 'BlueShade' Idzkiewicz <> wrote:
Oczywiście, zdarzają się sytuacje, że takie linki do redirectów to faktycznie niczemu nie służace śmieci, ale nie jest tak zawsze i moim zdaniem, forsowanie za wszelką cenę takiego "punktu honoru" jest działaniem na szkodę wikipedii...
W jaki sposób wpływa to negatywnie na Wikipedię?
nie wiem, czy mi się chce przytaczać po raz kolejny argumenty, które już na liście padały - wątek dotyczył Tawbota - można sobie znaleźć w archiwum...
w skrócie - istnieją redirecty (lub istniały przed interwencją Tawa), które służą temu, żeby umożliwić komuś przeczytanie związanej z danym zagadnieniem treści mimo, że nie istnieje hasło na dokładnie ten temat - czyli np. z [[Athlon XP]] na [[Athlon]]... Link kieruje na [[Athlon XP]], ale dopóki nie ma artykułu na temat [[Athlon XP]], w miejscu tym znajduje się redirect... W momencie, gdy zbierze się wystarczająco dużo informacji na ten temat, artykuł jest dzielony i redirect zamieniany na pełny artykuł... i tyle...
przypadek wydumany, ale pokazuje istotę sprawy ... i to niekoniecznie jest odosobnione zjawisko...
Bardzo wydumany i nie pokazuje wogóle problemu bo nie o tym pisałem - pisałem o linkowaniu do oczywistych przekierowań w rodzaju [[ang]] czy [[niem]].
i nie podoba mi się stosowanie w tym przypadku retoryki typu "wygląda nieprofesjonalnie i brzydko", bo to nieprawda... i poprawianie takiego stanu rzeczy to tylko dokładanie pracy - i sobie i innym...
Ależ oczywiście, że to jest prawda - to jest nieeleganckie, brzydkie, pokazuje, że ktoś przez lenistwo (nie chciało się wstukać kilku znaków więcej) linkuje do strony prezkierowującej świetnie wiedząc o tym, że to jest strona przekierowujące, a nie właściwe hasło.
I nie podoba mi się stosowanie w tym przypadku retoryki "to tylko dokładanie pracy - i sobie i innym..." - jeżeli to sam chcę robić to właśnie mój wybór, a nie widzę jak poprawienie [[ang.]] na [[język angielski|ang.]] dokłada pracy innej osobie.
On Wed, 27 Sep 2006, Michal Rosa wrote:
On 9/27/06, Przemyslaw 'BlueShade' Idzkiewicz <> wrote:
Oczywiście, zdarzają się sytuacje, że takie linki do redirectów to faktycznie niczemu nie służace śmieci, ale nie jest tak zawsze i moim zdaniem, forsowanie za wszelką cenę takiego "punktu honoru" jest działaniem na szkodę wikipedii...
W jaki sposób wpływa to negatywnie na Wikipedię?
nie wiem, czy mi się chce przytaczać po raz kolejny argumenty, które już na liście padały - wątek dotyczył Tawbota - można sobie znaleźć w archiwum...
w skrócie - istnieją redirecty (lub istniały przed interwencją Tawa), które służą temu, żeby umożliwić komuś przeczytanie związanej z danym zagadnieniem treści mimo, że nie istnieje hasło na dokładnie ten temat - czyli np. z [[Athlon XP]] na [[Athlon]]... Link kieruje na [[Athlon XP]], ale dopóki nie ma artykułu na temat [[Athlon XP]], w miejscu tym znajduje się redirect... W momencie, gdy zbierze się wystarczająco dużo informacji na ten temat, artykuł jest dzielony i redirect zamieniany na pełny artykuł... i tyle...
przypadek wydumany, ale pokazuje istotę sprawy ... i to niekoniecznie jest odosobnione zjawisko...
Bardzo wydumany i nie pokazuje wogóle problemu bo nie o tym pisałem - pisałem o linkowaniu do oczywistych przekierowań w rodzaju [[ang]] czy [[niem]].
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.
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, Gemma <> wrote:
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.
Profesjonalnie = dobrze, porządnie, nie na skróty.
Profesjonalnie = dobrze, porządnie, nie na skróty. Michal Rosa
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
Skrót według mnie niekoniecznie jest oczywisty - nie piszemy encyklopedii tylko dla inteligentów. Nie byłoby z tym problemu, bo wszystkie prowadziłyby do redirectów ("ang", "ros.", itp), a nie do artykułów lingwistycznych, gdyby się co chwila nie ujawniał kolejny ambitny właściel bota, upierający się za punkt honoru zamieniać je na "język angielski"... Pibwl - Michal Derela
Linki do oczywistych skrótów są zasadne, bo podstawowa część bazy ma już 800 MB.
Beno
-------- Treść oryginalnej wiadomości --------
Skrót według mnie niekoniecznie jest oczywisty - nie piszemy encyklopedii tylko dla inteligentów. Nie byłoby z tym problemu, bo wszystkie prowadziłyby do redirectów ("ang", "ros.", itp), a nie do artykułów lingwistycznych, gdyby się co chwila nie ujawniał kolejny ambitny właściel bota, upierający się za punkt honoru zamieniać je na "język angielski"... Pibwl - Michal Derela
Linki do oczywistych skrótów są zasadne, bo podstawowa część bazy ma już 800 MB.
Beno, wyjaśnij coś więcej, nie rozumiem tego argumentu.
Wracając do istoty linkowania skrótów nazw języków, uważam że zła jest obecna praktyka linkowanie do artykułów o języku - jest kierowaniem na manowce. Jeśli taki link ma wyjaśniać, co znaczy skrót ang., ros., hebr., łac., jap. i inne, to lepszym rozwiązaniem jest propozycja, by uzupełnić mechanizm Wiki o rozwijanie skrótu w dymku (pomysł był przedstawiony wcześniej w wątku). Byłoby to eleganckie wykorzystanie technologii encyklopedii elektronicznej.
Z drugiej strony, ponieważ założeniem Wikipedii jest utrzymanie artykułów na takim poziomie, aby były zrozumiałe dla osób z wykształceniem średnim, linkowanie skrótów najpopularniejszych języków wydaje mi się niecelowe. Linkowanie skrótów innych języków tak (ale tylko dlatego, że nie ma innego mechanizmu wyjaśniania skrótu i ze świadomością, że ten link prowadzi na manowce, bo w istocie chodzi tylko o informację, która jest w tytule).
xywek
Linki do oczywistych skrótów są zasadne, bo podstawowa część bazy ma już
800
Beno, wyjaśnij coś więcej, nie rozumiem tego argumentu. xywek
Porównaj długość [[Stany Zjednoczone]] i [[USA]] i weź pod uwagę, jak często są te linki stosowane. A takich przykładów jest wiele. Gdyby powszechnie stosować linki do skrótów (oczywiście tych znanych ogółowi), to baza zmniejszyłaby się odczuwalnie, bo o jakieś 2-3%. Może to i mało, ale gdyby jescze skrócić kilka innych rzeczy, jak rozbudowane podpisy, wielokrotne spacje, tabulatory na końcach wierszy, podwójne entery, uproszczenie składni html (np. center zamiast "center") itd., to w efekcie byłoby może i 10% mniej kodu.
Inna sprawa, że link w tym przykładzie i tak jest błędny, bo stanów zjednoczonych jest więcej, a tu chodziłoby o potworka aż 34-znakowego w postaci [[Stany Zjednoczone Ameyki Północnej]].
Na szczęściej wojny czy rzeczypospolite mamy numerowane zamiat liczebników.
Beno
Linki do oczywistych skrótów są zasadne, bo podstawowa część bazy ma już
800
Beno, wyjaśnij coś więcej, nie rozumiem tego argumentu. xywek
Porównaj długość [[Stany Zjednoczone]] i [[USA]] i weź pod uwagę, jak często są te linki stosowane. (...) 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
Dnia środa, 27 września 2006 22:51, Gemma napisał:
często są te linki stosowane. A takich przykładów jest wiele. Gdyby powszechnie stosować linki do skrótów (oczywiście tych znanych
"te znane ogółowi" = POV
ogółowi), to baza zmniejszyłaby się odczuwalnie, bo o jakieś 2-3%.
Przeprowadziłeś jakieś testy? Czy po prostu wziąłeś 2-3 z sufitu?
zamiast "center") itd., to w efekcie byłoby może i 10% mniej kodu.
Raz piszesz o bazie a raz o kodzie. Może się zdecyduj? I pytanie ponownie jak wyżej - masz jakieś testy, czy po prostu lubisz mieć swoje zdanie?
Rownie dobrze zamiast unikania tak dlugich linkow czy enterow mozna zaczac unikac polskich literek. Stosowany UTF-8 dusi serwer bazy naszymi rodzimymi znaczkami zdecydowanie bardziej od tych samych sentencji pisanych jedynie z zastosowaniem podstawowego zestawu ANSI. Mozna? Można! ...zartowalem ;)
Na wszystkie "bolączki" odnośnie wielkości bazy danych i obciążenia serwerów mam dwie odpowiedzi: 1) kompresja - tekst się pięknie kompresuje i praktycznie nie ma znaczenia, czy jest jeden enter na końcu linii, czy dwa, czy linkujemy do [[Stany Zjednoczone]] czy do [[USA]]. 2) "640K of memory should be enough for anybody." - powiedział pewien "architekt oprogramowania" i mylił się. Dzisiejsza miara wielkości danych nijak się ma do tego co będzie za kilka-kilkanaście lat. Stąd i dywagacje odnośnie wielkości bazy mogą być ekscytujące przez 5 minut.
Wydaje mi się że rzekoma wielkość bazy danych, którą czasem podajesz (800MB) to wielkość jakiegoś nieskompresowanego dumpa a nie rzeczywistej bazy. Za to sporo miejsca zajmują strony dyskusji! Wniosek - mniej gadać po próżnicy ;->
pzdr LukMak
"te znane ogółowi" = POV
USA jest znane ogółowi i nie jest POV
ogółowi), to baza zmniejszyłaby się odczuwalnie, bo o jakieś 2-3%.
Przeprowadziłeś jakieś testy? Czy po prostu wziąłeś 2-3 z sufitu?
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.
zamiast "center") itd., to w efekcie byłoby może i 10% mniej kodu.
Raz piszesz o bazie a raz o kodzie. Może się zdecyduj? I pytanie
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.
Wydaje mi się że rzekoma wielkość bazy danych, którą czasem podajesz
(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
| -----Original Message----- | From: ... Gemma | Sent: Thursday, September 28, 2006 11:42 AM
Czy aby Beno nie zacząłeś robić na siłę dobrze innym? W tym przypadku Jimbo i fundacji? Ja bym im zostawił problem, czy mają dość miejsca na dyskach. Ponadto jeszcze pamiętam dyskusję tutaj czy na plwiki na temat tradycyjnych encyklopedianych skrótów w rodzaju r., zob., wg - konkluzja była jednoznaczna: wyluzować, to nie drukowanie na biblijnym papierze, tu mamy medium elektroniczne, i piszemy wszystko rozwinięte.
A co do kodu, to jesteś zbyt radykalny. Jak tak patrzeć, to plik tekstowy też jest kodem.
Pzdr., Janusz 'Ency' Dorożyński
Czy aby Beno nie zacząłeś robić na siłę dobrze innym? W tym przypadku
Jimbo
i fundacji? Ja bym im zostawił problem, czy mają dość miejsca na dyskach. Ponadto jeszcze pamiętam dyskusję tutaj czy na plwiki na temat
tradycyjnych
encyklopedianych skrótów w rodzaju r., zob., wg - konkluzja była jednoznaczna: wyluzować, to nie drukowanie na biblijnym papierze, tu mamy medium elektroniczne, i piszemy wszystko rozwinięte. A co do kodu, to jesteś zbyt radykalny. Jak tak patrzeć, to plik tekstowy też jest kodem. Pzdr., Janusz 'Ency' Dorożyński
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
| -----Original Message----- | From: ... Gemma | Sent: Thursday, September 28, 2006 12:50 PM / | W tradycyjnym czystym pliku ASCII widać tylko tekst, a tu | widać więcej kodu - zarówno znaki formatuuące jak i unikode.
Czyli używasz zbyt zaawansowanych narzędzi. :-)) Jak obejrzysz plik ASCII edytorem heksadecymalnym, to co zobaczysz?
| A co do skrótów, to ... Problem miejsca jest i był | drugorzędny (choć nie bez znaczenia).
Tu mamy zbliżone poglądy co do zasady, z tym że aczkolwiek kwestia miejsca ma znaczenia, ale nie dla mnie. To nie moja broszka. A kogo, to już napisałem.
Pzdr., Janusz 'Ency' Dorożyński
Dnia czwartek, 28 września 2006 11:41, Gemma napisał:
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.
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.
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.
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.
Liczyłem łącznie wszystkie błędy, także np. nadmiar nbsp, r. zamiast roku, w. zamiast wieku, kg. zamiast kilogramów, spacje po asteriskach
Boty do roboty? Poprawienie tych błędów nie zmniejszy bazy, tylko ją zwiększy - wzrośnie historia.
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.
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
From: "LukMak" lukmak@vp.pl 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?
W dumpie są 4 znaki z podstawowego ASCII zapisane inaczej:
" > < s&
To znaczy, są tak zapisane w treści artów, bo w swojej podstawowej postaci służą do kodowania innych rzeczy. Dump jest w xml, więc pewnie dlatego.
Beno
From: "LukMak" lukmak@vp.pl Boty do roboty? Poprawienie tych błędów nie zmniejszy bazy, tylko ją
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
Witam
2006-09-28 Gemma:
G> - poprawki typu "== Linki Zewnetrzne ==" na "==Linki zewnętrzne=="
Czy mi się śniło czy kiedyś było zalecenie aby tą pierwszą formę stosować?
From: "makar" makaraj@tlen.pl 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
Witam
2006-10-03 Gemma:
- poprawki typu "== Linki Zewnetrzne ==" na "==Linki zewnętrzne=="
Czy mi się śniło czy kiedyś było zalecenie aby tą pierwszą formę stosować?
G> A jaki byłby sens? Przecież to nieortograficznie (z dwu powodów zresztą).
Jasne, mnie się o spacje rozdzielające rozchodziło.
----- Original Message ----- Jasne, mnie się o spacje rozdzielające rozchodziło. Andrzej Makarczuk
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
Dnia wtorek, 3 października 2006 11:35, Gemma napisał:
Zalecenie musi zawsze być czymś uzasadnione. Tu brak dwóch spacji da dwa bajty mniej na serwerze i 1 milisekundę szybciej pracy. Argument
Beno dalej prowadzisz tą nonsensowną krucjatę? Daj spokój.
przestaje być śmieszny po przeliczeniu na skalę globalną. Zalecenia dla przeciwnej wersji znaleźć nie potrafię.
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
| -----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
Witam
2006-10-03 Dorożyński Janusz:
DJ> | Jasne, mnie się o spacje rozdzielające rozchodziło.
DJ> Teraz już wiem :-)) , ale mógłbyś od razu ....
A bo wstępnie braku pliterek i anglicyzowania żemwogle nie zauważył.
Beno, ja wiem że dwie spacje więcej to dwa bajty więcej itp, itd. Ja tylko zapytowywuję czy onegdaj nie było zaleceniem edycyjnym wstawianie tych spacjuf. Bo mnie się po łbie pałęta cosik takiego, włącznie z argumentum ad parsowanum. Że niby mniej mocy obliczeniowej wymaga przetwarzanie takiego tekstu podzielonego spacjami. Tak pamiętam Wysoki Sądzie. I tego się będę trzymał :-)
makar wrote:
[ było o tym, czy w nagłówkach robić ==tak==, czy == tak == ]
Beno, ja wiem że dwie spacje więcej to dwa bajty więcej itp, itd. Ja tylko zapytowywuję czy onegdaj nie było zaleceniem edycyjnym wstawianie tych spacjuf. Bo mnie się po łbie pałęta cosik takiego, włącznie z argumentum ad parsowanum. Że niby mniej mocy obliczeniowej wymaga przetwarzanie takiego tekstu podzielonego spacjami. Tak pamiętam Wysoki Sądzie. I tego się będę trzymał :-)
Właśnie sprawdziłem (nawet mimo tego, że ktoś zaeksperymentował na żywo i okienka opisu edycji i nagłówka drastycznie się zmniejszyły), że po naciśnięciu "+" w celu wpisania nowego punktu dyskusji, oprogramowanie automatycznie marnuje te dwa bajty, bo nagłówki robi == tak ==. Co więcej, dodaje jeszcze jeden bajt, bo robi linijkę odstępu pod nagłówkiem.
Nie wiem, jak jest lepiej, i czy te odstępy bardzo szkodzą (ja tam je lubiaałem), ale oprogramowanie je wymusza, więc nie ma co się dziwić ludziom, którzy to potem powtarzają w hasłach.
Bansp
Witam
2006-10-13 PB:
P> [ było o tym, czy w nagłówkach robić ==tak==, czy == tak == ]
włącznie z argumentum ad parsowanum. Że niby mniej mocy obliczeniowej wymaga przetwarzanie takiego tekstu podzielonego spacjami.
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
Jeśli o ten bajt idzie to ja dodaję go zawsze. Tekst jest bardziej
czytelny w edycji.
makar
To źle robisz, bo większym problemem jest szczupłość miejsca w okienku edycyjnym, a Ty wymuszasz częstsze przewijanie. Mylisz warunki pracy z wyglądem końcowym. Idealnym rozwiązaniem jest jedna linia od góry i brak od dołu - to do odnajdywania miejsca w trakcie edycji wystarcza, a niewątpliwie więcej mozna pisać i widzieć na raz zamiast co chwila przewijać tekst by np. sprawdzić coś poniżej. Czysta ergonomia.
Największym takim kuriozum jest praktyka edycji na stronach dyskusji, gdzie czasami prawie połowa to puste linie. Obłęd. Po co to? Nie widać głosów poprzedników i nastepców.
Beno
Witam
2006-10-13 Gemma:
Jeśli o ten bajt idzie to ja dodaję go zawsze. Tekst jest bardziej czytelny w edycji.
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
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. Makar
Czy naprawdę jedna pusta linia od góry nie wystarczy? Po co druga od dołu? Przecież w tak małym okienku to jest naprawdę duże wyróżnienie.
Rozmiar okienka edycji można sobie zmieniać ;-)
A jak? Ja mam 25 linii a to maławo, stąd ten nadmiar pustych linii drażni.
Beno
Gemma wrote: [...]
Rozmiar okienka edycji można sobie zmieniać ;-)
A jak? Ja mam 25 linii a to maławo, stąd ten nadmiar pustych linii drażni.
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
Dnia Fri, 13 Oct 2006 15:42:00 +0200, PB banssp@gmail.com napisał:
Rozszerzyć mi się nie udało.
Preferencje → Edytowanie → [*] Obszar edycji o pełnej szerokości ?
| -----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
Problem polega na tym, że część osób ma możliwości sprzętowo-programowe umożliwiające wyswietlnie dużego obszaru strony www w przeglądarce. W szczególności chodzi o monitory z dużą rozdzielczością i wyświetlanie okna dłu giego w pionie. Ale są też tacy jak ja, gdzie jest do dyspozycji 1024 na 768. I co z takimi robić?
Tak więc postulat dbania o ludzi, którzy mogą mieć tylko małe okienko edycyjne jest zasadny. Ja mam 25 wierszy w oknie edycyjnym i koniec. Mogę, co prawda, jesze o zaledwie kilka wierszy wydłużyć to okno edycyjne kosztem ograniczenia pozostałych obszarów interfejsu, ale muszę to specjalnie robić, nie zawsze mi się chce a wielu innych może nawet tego nie potrafić.
Tak więc zasadne jest myślenie o dość dużej grupie użytkowników dysponujących 25 wierszami, i stąd proponuję dawać jedną linię przed nagłówkiem i zero linii po. W tak małym oknie jak 25 wierszy to rozwiązanie w zupełności wystarcza do rozpoznawania akapitów.
np.
tekst tekst tekst ______pusty ==Nagłówek== tekst tekst tekst ______pusty ==Nagłówek== tekst tekst tekst
Beno
| -----Original Message----- | From: ... Gemma | Sent: Tuesday, October 03, 2006 11:07 AM / | A jaki byłby sens? Przecież to nieortograficznie (z dwu | powodów zresztą).
Chyba nie zrozumiałeś. Makar pyta, abstrahując od poprawności danej formy, czy była kiedyś zalecana. Ja, też abstarhując, wręcz dopuszczam możliwość istnienia takiej sytuacji na naszej potocznopedii. Natomiast po co Makarowi takie info, to już tego nie wiem.
Pzdr., Janusz 'Ency' Dorożyński