Wikiprojekt:Infoboksy/standardy
Infoboksy Dyskusja | ||
Podstrona służąca do ustalania zaleceń dot. tworzenia infoboksów.
Część zaleceń została już opracowana i przegłosowana do ogólnego stosowania:
Sposób nazywania parametrów
edytujPodsumowanie: polskie znaki i spacje. Matma Rex aka matematyk 13:37, 27 lip 2008 (CEST)
Jak należy nazywać parametry - z/bez polskich znaków, spacje/znaki "_"/nic? Matma Rex aka matematyk 16:46, 20 kwi 2008 (CEST)
Mała tabelka, dokładnie wyjaśniająca:
polskie znaki: tak | polskie znaki: nie | |
---|---|---|
spacje: spacja | {{{data śmierci}}} | {{{data smierci}}} |
spacje: _ | {{{data_śmierci}}} | {{{data_smierci}}} |
spacje: brak | {{{dataśmierci}}} | {{{datasmierci}}} |
Matma Rex aka matematyk 17:08, 20 kwi 2008 (CEST)
- bez spacji mało czytelne, a czy ze spacją czy z podkreślnikiem, czy polskie literki czy nie - to mniej znaczące, bo i tak przekleja się z "opisu szablonu". No chyba, że założymy, że ktoś nieznający polskiego będzie chciał coś uzupełnić (np. stworzy herb swojego miasta i będzie chciał go wkleić wszędzie, gdzie widzi interwiki) - wtedy poprawna pisownia ułatwi mu życie (łatwiej sprawdzić w słowniku, chyba ?) - Beax 17:39, 20 kwi 2008 (CEST)
- IMO powinny być i pl znaki, i spacje zwykłe. Matma Rex aka matematyk 17:43, 20 kwi 2008 (CEST)
- Polskie znaki i spacje, chociaż kładka też mogłaby być. Yarl read.me 19:06, 20 kwi 2008 (CEST)
- IMO powinny być i pl znaki, i spacje zwykłe. Matma Rex aka matematyk 17:43, 20 kwi 2008 (CEST)
- Według mnie nazwy pola powinny składać się z nazw, które zawierają spacje i polskie litery. Dobrze by było przygotować także jakiś słowniczek, żeby pole "data urodzenia" zawsze sie tak nazywało, a nie jakieś konstrukcje typu "urodzony", "data_ur" itp. Beau (dyskusja) 11:20, 21 kwi 2008 (CEST)
- Jestem za polskimi znakami i spacjami, ale chyba wielu się przyzwyczaiło do podkreślników. No i jak Beau - standard nazw by się przydał. Część infoboksów jest rozbudowywana i w starych brak jest np. opcji dla grafiki - a nazywa się to różnie - grafika, obrazek, chyba też zdjęcie. Przykuta (dyskusja) 15:27, 21 kwi 2008 (CEST)
- Zdecydowanie spacje i polskie znaki, ale raczej bez zmian wstecznych (ze względu na liczne w zasadzie puste edycje). Kiedyś to była kwestia techniczna, a teraz w zasadzie nie ma to znaczenia (także ze względy na większe monitory). --Nux (dyskusja) 19:34, 21 kwi 2008 (CEST)
- Ale my tu mamy strandaryzację robić :) Zresztą, zmiany w każdym infoboxie, więc i w każdej stronie go używaj ącej, będą robione raz, po ustaleniu wszystkiego tutaj i ew. przy pojedynczych infoboxach. Tak sądzę. Matma Rex aka matematyk 19:47, 21 kwi 2008 (CEST)
- Standaryzacja nie musi oznaczać, że musisz zmienić wszystko co było. Poza tym jak to sobie wyobrażasz? Trzeba by było przecież zmienić jakieś 80% artykułów (połowa to wioski, meteoryty itp). Myślę, że po takie operacji mielibyśmy wizytę Briona ;). --Nux (dyskusja) 08:55, 23 kwi 2008 (CEST)
- Ale my tu mamy strandaryzację robić :) Zresztą, zmiany w każdym infoboxie, więc i w każdej stronie go używaj ącej, będą robione raz, po ustaleniu wszystkiego tutaj i ew. przy pojedynczych infoboxach. Tak sądzę. Matma Rex aka matematyk 19:47, 21 kwi 2008 (CEST)
- Do tej pory sugerowało się i poprawiało się na: polskie znaki zawsze, oraz podkreślniki. Nawet gdzieś kiedyś albo napisałem albo malarz_pl napisał aby używać pl znaków i podkreślników. Podkreślniki mają swoich przeciwników, ale to inna kwestia. Więc do co liter to nie ma dyskusji - polskie i tyle. Co do spacji to uważam że lepiej wygląda taki szablon jak jest z podkreślnikami - łatwiej znaleźć parametry i odróżnić je od ich treści. Trzeba też uzgodnić kwestię wypełniania infoboksu (po której stronie ma być pipe - czyli że po lewej, oraz czy znak równa ma być wyrównywany do lini czy nie - ja wolę bez wyrównania. Ładnie to wygląda tylko jak szablon jest pusty). A_Bach - ΣΦ 00:34, 22 kwi 2008 (CEST)
- Popieram polskie znaki i spacje. Podkreślenia nie są problemem jeśli kopiuje się pusty szablon, ale często wywołania szablonów uzupełniam o parametry i wtedy wstawianie podkreśleń jest przykre. Co do reszty, to pełna zgoda: pipe z lewej i bez wyrównania :) Nova (dyskusja) 10:22, 22 kwi 2008 (CEST)
- Polskie znaki i spacje BuahahaxD 15:34, 30 lip 2008 (CEST)
Standardowe nazwy częstych parametrów
edytujData urodzenia, śmierci itp
edytujPodsumowanie: parametry data urodzenia, data śmierci. Yarl ✉ 10:21, 26 sie 2008 (CEST)
UWAGA! To są nazwy z polskimi znakami i podkreślnikiem, co może się zmienić - patrz powyżej
- Data urodzenia - {{{data urodzenia}}}, {{{data urodzin}}}, {{{urodzony}}}, inne?
- {{{data urodzenia}}}. Matma Rex aka matematyk 15:51, 21 kwi 2008 (CEST)
- ale i wpisywane jako 1 listopada 1697, a nie 1.11.1697 - 1697.11.01 - 1.XI.1697 czy jeszcze inaczej... - Beax 02:01, 22 kwi 2008 (CEST)
- Data śmierci - {{{data śmierci}}}, {{{zmarły}}}, inne?
- {{{data śmierci}}}. Matma Rex aka matematyk 15:51, 21 kwi 2008 (CEST)
Grafiki z opisem
edytujPodsumowanie: patrz ustalenia w sekcji #Wstawianie grafiki. Yarl ✉ 10:21, 26 sie 2008 (CEST)
- Grafiki: (nazwa grafiki, opis grafiki, szerokość grafiki), (grafika {=Grafika:Nazwa}, opis grafiki, szerokość grafiki), (grafika {=[[Plik:Nazwa|opis|szerokość]]}), inne?
- zestaw(nazwa grafiki, opis grafiki, szerokość grafiki) z szerokością opcjonalną (podobnie jak w Pomoc:Jak utworzyć nowy infoboks/przykład) ze względu na uniwersalność późniejszych zmian --Nux (dyskusja) 19:34, 21 kwi 2008 (CEST)
- A ja proponowłbym krótkie nazwy: grafika, rozmiar/szerokość, opis/podpis. Jeśli będą koło siebie w wywołaniu, nie będzie problemów, co to takiego. Matma Rex aka matematyk 19:45, 21 kwi 2008 (CEST)
- grafika, szerokość, opis grafiki - proste jednoznaczne parametry. A_Bach - ΣΦ 00:34, 22 kwi 2008 (CEST)
- Hmm. Stosowane są też parametry "obrazek" i "opis obrazka". Nie upieram się przy nich, ale czy zdjęcie to grafika? Nova (dyskusja) 10:22, 22 kwi 2008 (CEST)
- IMO grafika to każdy obrazek, rysunek, zdjęcie, itd., o ile jest w postaci cyfrowej. O obrazie albo zwykłym zdjęciu raczej trudno powiedzieć "grafika". Matma Rex aka matematyk 13:01, 22 kwi 2008 (CEST)
- W końcu przestrzeń chyba nie bez powodu nazywa się "grafika". Co do nazw - "grafika" mi się nie podoba, bo nie jest jednoznaczne, czy trzeba tam wpisać samą nazwę, nazwę z podaniem przestrzeni, czy jeszcze coś innego. Stąd jak chce się wypełnić coś dawniej wstawionego, to trzeba zaglądać do opisu infoboksu. A można by tego uniknąć stosując bardziej jednoznaczne nazwy parametrów. Poza tym parametrów nie wpisuje się z palca, tylko się przekleja więc ich długość nie ma w praktyce znaczenia (także ze względów dodatkowej objętości, bo +10B nie ma znaczenia przy 1-2 infoboksach na cały artykuł). --Nux (dyskusja) 08:55, 23 kwi 2008 (CEST)
- Będzie jednoznaczne, jak już to ustandaryzujemy ;) A aktualnie to, co trzeba tam wstawić, łatwo wywnioskować z tego, czy są parametry opis i szerokość. Matma Rex aka matematyk 09:21, 23 kwi 2008 (CEST)
- Chodziło mi o to, żeby było jednoznaczne bez zaglądania do "podręcznika" (standardu). To jest taka różnica jak między intuicyjnym interfejsem a vimem ;). --Nux (dyskusja) 17:23, 23 kwi 2008 (CEST)
- Będzie jednoznaczne, jak już to ustandaryzujemy ;) A aktualnie to, co trzeba tam wstawić, łatwo wywnioskować z tego, czy są parametry opis i szerokość. Matma Rex aka matematyk 09:21, 23 kwi 2008 (CEST)
- W końcu przestrzeń chyba nie bez powodu nazywa się "grafika". Co do nazw - "grafika" mi się nie podoba, bo nie jest jednoznaczne, czy trzeba tam wpisać samą nazwę, nazwę z podaniem przestrzeni, czy jeszcze coś innego. Stąd jak chce się wypełnić coś dawniej wstawionego, to trzeba zaglądać do opisu infoboksu. A można by tego uniknąć stosując bardziej jednoznaczne nazwy parametrów. Poza tym parametrów nie wpisuje się z palca, tylko się przekleja więc ich długość nie ma w praktyce znaczenia (także ze względów dodatkowej objętości, bo +10B nie ma znaczenia przy 1-2 infoboksach na cały artykuł). --Nux (dyskusja) 08:55, 23 kwi 2008 (CEST)
- IMO grafika to każdy obrazek, rysunek, zdjęcie, itd., o ile jest w postaci cyfrowej. O obrazie albo zwykłym zdjęciu raczej trudno powiedzieć "grafika". Matma Rex aka matematyk 13:01, 22 kwi 2008 (CEST)
- A ja proponowłbym krótkie nazwy: grafika, rozmiar/szerokość, opis/podpis. Jeśli będą koło siebie w wywołaniu, nie będzie problemów, co to takiego. Matma Rex aka matematyk 19:45, 21 kwi 2008 (CEST)
- zestaw(nazwa grafiki, opis grafiki, szerokość grafiki) z szerokością opcjonalną (podobnie jak w Pomoc:Jak utworzyć nowy infoboks/przykład) ze względu na uniwersalność późniejszych zmian --Nux (dyskusja) 19:34, 21 kwi 2008 (CEST)
więcej w sekcji → #Wstawianie grafiki
Commons i projekty siostrzane
edytujPodsumowanie: zmienne: wikisłownik, wikicytaty, wikinews, wikiźródła, wikibooks, wikiwersytet, wikispecies, commons. Yarl ✉ 22:17, 18 wrz 2008 (CEST)
- raz jest galeria_commons a kiedy indziej same commons - należałoby to ujednolicić (moim zdaniem do: galeria_commons) i dopisać do instrukcji, że można wpisać też kategorię, czyli galeria_commons=pliki oraz galeria_commons=category:pliki
- Dodatkowo chciałam zaznaczyć, że widok samego linku w infoboksie powinien mieć inny opis... bo to nie zawsze jest galeria grafik, czasem (częściej ?) jest to kategoria, a jeszcze kiedy indziej zbiór dźwięków (patrz: Hymn Brazylii i "galeria" commons). Nie wiem JAK to zrobić, żeby było jednocześnie ogólne i jednoznacznie czytelne dla kogoś kto zagląda na wiki pierwszy raz. Może ktoś z was coś wymyśli. - Beax 01:43, 22 kwi 2008 (CEST)
- Hmm, galeria commons jest częstsze, ale to też brak standardu, bo nie ma "news wikinews" czy "dzieło wikiźródła" itd. Ale osobiscie nie robi mi to różnicy, jeśli będzie jakiś standard, to będzie lepiej niż jego brak. Co do galerii i kategorii, to byłbym za tym, aby linkować do galerii, nie do kategorii. Jeśli nie ma galerii, heh - lepiej byłoby je tworzyć :) Do kategorii Commons wstawiajmy linki na stronach kategorii. To zresztą zadanie do wikipropjektu ilustrowanie z tym wstawianiem linków ;) Kiedyś jeszcze myślałem, aby była inna ikonka do galerii niż logo commons, bo ono wcale nie sugeruje galerii. Przykuta (dyskusja) 07:34, 22 kwi 2008 (CEST)
- Stosowanie nazwy parametru "commons" w infoboksach zostało chyba przeniesione z szablonów {{commons}}, {{wikinews}} itd. Dodawanie "galeria" wydaje mi się zbędne, szczególnie w kontekście tego co napisał Beax (odnośnie dźwięków). Natomiast popieram, że potrzebne jest lepsze uwypuklenie tego co pod linkiem się kryje, najczęściej nie jest oczywiste, że prowadzi np. do galerii. W {{Roślina infobox}} zdecydowaliśmy się na "Galeria zdjęć i grafik". W przypadku roślin nie mamy raczej problemu z audio, zastanawiam się więc, może nie ma sensu ustalanie jednego standardu dla wszystkich infoboksów, a dwie lub trzy wersje, w zależności od tego, co tam właściwie jest. Przy czym nie ma chyba znaczenia czy link prowadzi do kategorii czy artykułu, z rozróżnianiem tych przypadków dałabym spokój. Nova (dyskusja) 10:22, 22 kwi 2008 (CEST)
- Z tym też się zgadzam - przecież galeria w kategorii i w zwykłym artykule niewiele się od siebie różnią pod względem wyglądu (w zasadzie to w ogóle nie wiem, po co te galerie są tworzone). Matma Rex aka matematyk 10:33, 22 kwi 2008 (CEST)
- W odróżnieniu od kategorii, w galeriach jest opis pod zdjęciem, co ono przedstawia - nie trzeba wchodzić w stronę grafiki. Czasami galerie podzielone są też na sekcje, co lepiej porządkuje ich zawartość. Można tez lepiej wyeksponować niektóre grafiki - np. panoramiczne. Przykuta (dyskusja) 13:12, 22 kwi 2008 (CEST)
- Ja też jestem za samym "commons". Przy okazji jest problem z innymi parametrami dot. projektów siostrzanych: Yarl ✉ 10:29, 26 sie 2008 (CEST)
- quote/cytaty
- source/(źródła?)
- wikispecies/(?)
- słownik
- Z tym też się zgadzam - przecież galeria w kategorii i w zwykłym artykule niewiele się od siebie różnią pod względem wyglądu (w zasadzie to w ogóle nie wiem, po co te galerie są tworzone). Matma Rex aka matematyk 10:33, 22 kwi 2008 (CEST)
- Też popieram commons, co do pozostałych, to myślę, że powinniśmy używać polskich nazw jeśli tylko się przyjęły. Czyli tak jak jest na głównej - wikisłownik, wikicytaty, wikinews, wikiźródła, wikibooks, wikiwersytet, wikispecies i commons. Zostawiłbym we wszystkich przedrostek "wiki", żeby od razu było wiadomo, że chodzi o rodzimy projekt. --Nux (dyskusja) 22:28, 26 sie 2008 (CEST)
- OK, jeśli nie ma sprzeciwu to ustalone. Yarl ✉ 22:17, 18 wrz 2008 (CEST)
Koordynaty
edytujA co z koordynatami? Obecnie są:
Opcja 1
|
Opcja 2
|
Opcja 3
|
Yarl ✉ 13:27, 21 sie 2008 (CEST)
- Z koordynatami jest jeszcze jeden problem, część z nich wstawia koordynaty wewnątrz infoboksu, a część deleguje dalej do szablonu {{współrzędne}}. Osobiście jestem za tym drugim rozwiązaniem bo w ten sposób, całość jest spójna z artykułami które infoboksu nie mają a koordynaty można im wpisać, a do tego sam infoboks wizualnie jest ciut krótszy kosztem miejsca które i tak byłoby niewykorzystane. ABX - (O mnie dyskutuj) 13:31, 21 sie 2008 (CEST)
- Racja, umieszczanie koordynatów w infoboksie jest zbędne. Co do powyższego to uważam, iż opcja pierwsza jest najbardziej wygodna. Yarl ✉ 12:12, 22 sie 2008 (CEST)
- Hold the presses! ;) Z tymi parametrami jest nieco inaczej. W polskich miastach itp jest tylko jeden zestaw (N i E), bo tylko takie są potrzebne (W innych jest np. tylko N i W). Jeśli miałoby być coś zmieniane, to moim zdaniem tylko te infoboksy, które dotyczą np. państw leżących na różnych szerokościach/długościach. W takim wypadku moim zdaniem najlepsza jest opcja nr 2. Opcja nr 1 wprowadza zbędną funkcjonalnie nadmiarowość, a opcja nr 3 jest słaba pod względem użytkowym - nie wiem jak wy, ale ja jakoś nie jestem w stanie trwale zapmiąetać, czy długość to jest E/W, czy N/S. --Nux (dyskusja) 20:26, 22 sie 2008 (CEST)
- Hmm chodziło mi głównie o koordynaty w takich infoboksach jak wieżowiec, budynek, jaskinia, świątynia etc – w tych przypadkach potrzebny jest pełny zakres współrzędnych. Opcja 3 również wydaje się nietrafiona. Do opcji 2 mam stosunek obojętny, więc przychylam się do opcji 1, po prostu występuje najczęściej. Poza tym zbędne zmienne można spokojnie usunąć.
- Co do W polskich miastach itp jest tylko jeden zestaw (N i E), bo tylko takie są potrzebne (W innych jest np. tylko N i W) – rozumiem, że chodziło o infoboksy miast rozsiane w tej kategorii. Nie wiem, czy jest sens bawienia się w nich w koordynaty. Trzeba się kiedyś za nie wziąć i scalić do {{miasto zagranica infobox}} i podobnych. Yarl ✉ 13:05, 23 sie 2008 (CEST)
- Moim zdaniem koordynaty powinny zostać w infoboksach, a z tą różnorodnością infoboksów administracyjnych trzeba będzie coś zrobić, może jakiś infoboks-kombajn? Karol007dyskusja 15:30, 23 sie 2008 (CEST)
- Spójrz do szablonu {{Miasto zagranica infobox}} (o ile w między czasie go nikt nie zmieni), w infoboksie może być, tak jak tu, wygenerowane pole "położenie" a w narożniku standardowy link koordynat. W każdym razie ja jestem za tym żeby współrzędne w kodzie artykułu były tylko raz, oraz żeby artykuły bez infoboksów i z infoboksami, miały wyrenderowane współrzędne zawsze w tym samym miejscu ekranu/strony, tak żeby czytelnik nie szukał wzrokiem za każdym razem kiedy będzie chciał przejść do map. ABX - (O mnie dyskutuj) 15:17, 25 sie 2008 (CEST)
- Tylko, że póki te szablony nie są scalone, to z jednej strony nie trzeba wszystkiego wypełniać, a z drugiej masz możliwość wprowadzenia innej nazwy np. stanowiska burmistrza. Także jeśli już wprowadzać kombajn, to moim zdaniem raczej trzeba by pomyśleć o czymś, co można częściowo wypełnić i stworzyć wygodny szablon-przejściówkę. Mam na myśli podobny mechanizm jak z Uniwersalny szablon nawigacyjny i jego pochodnymi. --Nux (dyskusja) 01:58, 26 sie 2008 (CEST)
- ABX, masz rację, w kodzie artykułu koordynaty nie powinny się powtarzać. Karol007dyskusja 20:29, 26 sie 2008 (CEST)
- Spójrz do szablonu {{Miasto zagranica infobox}} (o ile w między czasie go nikt nie zmieni), w infoboksie może być, tak jak tu, wygenerowane pole "położenie" a w narożniku standardowy link koordynat. W każdym razie ja jestem za tym żeby współrzędne w kodzie artykułu były tylko raz, oraz żeby artykuły bez infoboksów i z infoboksami, miały wyrenderowane współrzędne zawsze w tym samym miejscu ekranu/strony, tak żeby czytelnik nie szukał wzrokiem za każdym razem kiedy będzie chciał przejść do map. ABX - (O mnie dyskutuj) 15:17, 25 sie 2008 (CEST)
- Moim zdaniem koordynaty powinny zostać w infoboksach, a z tą różnorodnością infoboksów administracyjnych trzeba będzie coś zrobić, może jakiś infoboks-kombajn? Karol007dyskusja 15:30, 23 sie 2008 (CEST)
- ja jestem za opcją 1. Przy czym najbardziej mnie denerwuje, jak muszę wpisywać współrzędne do infoboksu, a potem do "sznurków zewnętrznych" = {{Linki do map Polski}} - przy czym uważam, że miejsce na współrzędne jest w infoboksie. Linki do map też powinny być tam gdzie są, ale bombowo by było, gdyby umiały czytać współrzędne z infoboksu. Ale rozumiem, że się nie da i trudno. No chyba, że wrzucimy do infoboksu linki do map.... co do czego nie jestem przekonana.. - Beax 22:15, 30 wrz 2008 (CEST) P.S. mój nauczyciel geografii tłumaczył nam, że pojęcie szerokości i długości geograficznej wprowadzili Rzymianie, którzy generalnie podróżowali w basenie morza Śródziemnego. A Morze Śródziemne jest długie ze wschodu na zachód, natomiast szerokie od północy na południe. Dlatego szerokość geograficzną odczytujemy na równoleżnikach etc. Nie wiem czy to prawda z tymi Rzymianami, ale przynajmniej da się jakoś zapamiętać które-jest-które :-)))
A ja byłbym za tym, żeby koordynaty się jednak wyświetlały w infoboksie, w kodzie by się raz pojawiały, ale jeśli weźmiemy pod uwagę to, że infobox ma zawierać podstawowe informacje (i/lub szczegółowe) to koordynaty powinny być. Poza tym użytkownik ma wszystko w tabelce, którą zapewne będzie chciał sobie wydrukować i powiesić na ścianie. Niech zawsze link z kordów do mapy będzie nad tytułem a dodatkowo niepodlinkowane kordy w boksie. Karol007dyskusja 22:52, 1 paź 2008 (CEST)
Po namyśle stwierdzam, że najbardziej by mi pasowało połączenie opcji 1 z pozostałymi: parametry "stopniX", "stopniY" (+min/sek), gdzie X i Y to odpowiednie oznaczenia szerokości i długości. Nie ma niepotrzebnych pustych parametrów, a "stopniNS" wygląda jakoś dziwnie (subiektywna opinia, może mi się z tym NS kojarzy). Poza tym parametry "długość" i "szerokość" mogą mieć inne znaczenie jak w {{Jezioro infobox}}.
A w infoboksie bym tego jednak nie umieszczał, żeby za dużo miejsca nie zajmować, lepiej za to wyeksponować wyraźniej współrzędne w rogu. ToSter→¿? 23:02, 1 paź 2008 (CEST)
Dyskusja się przeciąga, a konsensu nie ma. Wypada więc zrobić minigłosowanie: wstawiamy tylko podpis, ew. dyskusja powyżej.
- sposób zapisu
- opcja 1: Yarl ✉ 20:49, 1 paź 2008 (CEST), Karol007dyskusja 22:52, 1 paź 2008 (CEST), BartekChom (dyskusja) 18:25, 11 paź 2008 (CEST) ABX - (O mnie dyskutuj)
- opcja 2: Nux (dyskusja) 23:42, 1 paź 2008 (CEST) (chyba, że obiekty z danej grupy artykułów są tylko w jednej ćwiartce)
- opcja 3:
Uwaga co do sposobu zapisu Nasz nowy szablon daje możliwość wpisania również wartości współrzędnych dziesiętnie (i np. wyświetlania kątowo). Zaleta: to tylko dwa parametry np. |szerokośćNS=
i |długośćWE=
. Proponuję dać te parametry opcjonalnie do wykorzystania w infoboksach pochodnych « Saper // @dyskusja » 10:56, 16 sty 2009 (CET)
- koordynaty wyświetlane w infoboksach
- zostać w infoboksach: Jedna rzecz, to gdzie wstawiać koordynaty w wikitekst. Koordynaty powinny być wstawione w tym miejscu, w którym powinny być wyświetlane - to tylko CSS-owy trick przenosi je na górę strony, ale np. w przeglądarce tekstowej tak się nie stanie i dlatego lepiej, żeby były wewnątrz infoboksu (a nie tak jak robi obecnie większość infoboksów przed infoboksem). W tym celu zarezerwowałbym oddzielny wiersz (bez podziału na kolumny), tak jak zrobiłem to w {{Katastrofa infobox}}. Druga rzecz, to gdzie wyświetlać: z jednej strony stałe miejsce to fajny pomysł, ale dla mnie jest to informacja "skrócona" jak każda inna i ja np. odruchowo szukam tego typu rzeczy właśnie w infoboksie, a nie na górze strony. Inna rzecz, że nieszczególnie lubię wyświetlanie i innych ikonek współrzędnych na górze artykułu, bo uważam, że strony wiki powinny mieć układ liniowy i pokazywać strukturę informacji, a nie rozrzucać je po stronie w mniej lub bardziej uporządkowany sposób. Z tego powodu korzystam ze skórki standard i tam na szczęście koordynaty są zawsze inline. Ewentualnie można dać w {{Koordynaty/testuj}} parametr
wyświetl=na górze
i wtedy dla monobooka współrzędne wyskoczą na górę - dobrze byłoby aby w nowym infoboksie wiersz ze współrzędnymi ukrywał się automatycznie. A przy okazji, na pewno nie powinny koordynaty się powtarzać. « Saper // @dyskusja » 10:56, 16 sty 2009 (CET) - na górze strony: Yarl ✉ 20:49, 1 paź 2008 (CEST), ToSter→¿? 23:02, 1 paź 2008 (CEST), BartekChom (dyskusja) 18:25, 11 paź 2008 (CEST) ABX - (O mnie dyskutuj)
- w niektórych:
- zostać w infoboksach: Jedna rzecz, to gdzie wstawiać koordynaty w wikitekst. Koordynaty powinny być wstawione w tym miejscu, w którym powinny być wyświetlane - to tylko CSS-owy trick przenosi je na górę strony, ale np. w przeglądarce tekstowej tak się nie stanie i dlatego lepiej, żeby były wewnątrz infoboksu (a nie tak jak robi obecnie większość infoboksów przed infoboksem). W tym celu zarezerwowałbym oddzielny wiersz (bez podziału na kolumny), tak jak zrobiłem to w {{Katastrofa infobox}}. Druga rzecz, to gdzie wyświetlać: z jednej strony stałe miejsce to fajny pomysł, ale dla mnie jest to informacja "skrócona" jak każda inna i ja np. odruchowo szukam tego typu rzeczy właśnie w infoboksie, a nie na górze strony. Inna rzecz, że nieszczególnie lubię wyświetlanie i innych ikonek współrzędnych na górze artykułu, bo uważam, że strony wiki powinny mieć układ liniowy i pokazywać strukturę informacji, a nie rozrzucać je po stronie w mniej lub bardziej uporządkowany sposób. Z tego powodu korzystam ze skórki standard i tam na szczęście koordynaty są zawsze inline. Ewentualnie można dać w {{Koordynaty/testuj}} parametr
Współrzędne geograficzne - w infobkosach, poza nimi, i w przyszłości
edytuj(Wątek został przeniesiony z Dyskusja Wikiprojektu:Infoboksy i tym razem potraktowany został jeszcze szerzej)
Współrzędne geograficzne a infoboksy to cel ruchomy.
Możnaby je samemu dopisywać w rozmaity sposób: np. dopisując w {{wojna infobox}} do wartości parametru miejsce
:
- Przykładowo, szablon:
{{coor dms|stopnie|minuty|sekundy|N lub S|stopnie|minuty|sekundy|E lub W|type:landmark_region:US_OK}}
. W {{coor dms}} sekundy są opcjonalne (wstawiamy wtedy:||
) aregion:
itype:
regulują skalę mapy i które serwisy do jej wyświetlania udostępni klikającemu toolserver, dozwolone wartości opisane są w dokumentacji szablonu {{współrzędne}}.
Alternatywnie, możnaby omijać (na razie) infoboksy i wstawiać współrzędne do definicji haseł, tuż po wytłuszczeniu, analogicznie do dat w biografiach.
Mamy też {{coor dm}} i {{coor d}}, jaki i {{współrzędne}}. Stosowanie tego ostatniego wyświetli wartości grubo poza tekstem (w nagłówku, na prawym marginesie, maczkiem). Stale zwiększajaca się część korzystania z Wikipedii to metody alternatywne np. oprogramowanie przetwarzające hasła bez wyświetlania tytułów i co za tym idzie, pomijające współrzędne wyświetlane tamże.
Pewne nasze starszawe infoboksy zawierają parametry (nie jeden paramter, parametry), inne parametr. Jak one wyświetlą te dane różni się znacznie.
W przyszłości podobno przeniesiemy wszechstronny szablon Coord z en wiki, co radykalnie zmieni wyświetlanie współrzędnych geograficznych w jeszcze nieustalony sposób. :)
W międzyczasie, jak należy wstawiać współrzędne do artykułów z infoboksami?
Jednego jestem pewien: należy je wstawiać częściej niż to robimy lub przewidują to infokobsy. --Mareklug dyskusja 03:37, 23 paź 2008 (CEST)
- To ja proponuję od razu przenieść ten wszechstronny szablon z en Wiki i dopiero wtedy się zastanawiać co dalej. Na dodatek, chciałbym skomplikować sytuację podając linka do dyskusji z wikiprojektu astronomia: Dyskusja Wikiprojektu:Astronomia#koordynaty astronomiczne. Karol007dyskusja 13:04, 23 paź 2008 (CEST)
- Szablon jest jako {{Koordynaty/testuj}}, po zakończeniu testów i prac w infoboksach ma zastąpić {{Współrzędne}} pod tą samą nazwą. Potrzebne jest przełożenie opisu z enwiki i ew. Pomoc:Współrzędne geograficzne. « Saper // @dyskusja » 10:56, 16 sty 2009 (CET)
- Jest gotowy osobny szablon o stałej liczbie parametrów z przeznaczeniem do infoboksów - {{Współrzędne geograficzne}}. Zapraszam do dyskusji. « Saper // @dyskusja » 01:04, 28 sty 2009 (CET)
- Teraz jest już tylko jeden szablon: {{Współrzędne}}, czyli {{Koordynaty/testuj}} rozpoznający dowolnie (albo prawie dowolnie :)) zadane współrzędne. Problem z integracją {{Współrzędne}} i {{Koordynaty/testuj}} opisałem w dyskusji tego pierwszego. --Botev (dyskusja) 01:12, 5 mar 2009 (CET)
- Teraz jest już tylko jeden szablon: {{współrzędne}}. ~malarz pl PISZ 14:49, 18 mar 2009 (CET)
- Jest gotowy osobny szablon o stałej liczbie parametrów z przeznaczeniem do infoboksów - {{Współrzędne geograficzne}}. Zapraszam do dyskusji. « Saper // @dyskusja » 01:04, 28 sty 2009 (CET)
- Szablon jest jako {{Koordynaty/testuj}}, po zakończeniu testów i prac w infoboksach ma zastąpić {{Współrzędne}} pod tą samą nazwą. Potrzebne jest przełożenie opisu z enwiki i ew. Pomoc:Współrzędne geograficzne. « Saper // @dyskusja » 10:56, 16 sty 2009 (CET)
Wielkość liter
edytujPodsumowanie: nazwy parametrów małymi literami z wyjątkiem nazw własnych. Matma Rex aka matematyk 13:37, 27 lip 2008 (CEST)
To chyba nie było jeszcze poruszone tutaj. W każdym razie stosowałem się do takiej ścieżki - pierwszy parametr typu nazwa, imię i nazwisko - z dużej litery (Nazwa, Imię i nazwisko, etc), wszystkie kolejne parametry z małej litery (www, opis grafiki, grafika, herb, etc). Zresztą sugeruję przyjżenie się parametrom infoboksów miast i wsi - ponieważ mają bardzo dużo wywołań raczej nie sugerowałbym ich zmian, a jeśli to w bardzo małym zakresie. Te szablony były dość dobrze dyskutowane. A_Bach - ΣΦ 00:34, 22 kwi 2008 (CEST)
- Jeśli już miałyby być jakieś zmiany w tej kwestii, to według mnie wszystkie parametry powinny być z małej litery, nie widzę uzasadnienia wstawiania wielkich liter - wymaga wciśnięcia "shift" - co jest dodatkową a zbędną czynnością przy uzupełnianiu infoboksów o kolejne parametry. Może trochę marudzę, ale w codziennej pracy takie drobne sprawy potrafią być uciążliwe. Nova (dyskusja) 10:22, 22 kwi 2008 (CEST)
- Zgadzam się, wszystko z małej litery, poza ew. nazwami własnymi. Matma Rex aka matematyk 10:27, 22 kwi 2008 (CEST)
- Tez popieram propozycje. SPIKE KSIĄŻKA SKARG I ZAŻALEŃ 14:37, 5 cze 2008 (CEST)
- Równiez jestem za stosowaniem małej litery w parametrach, poza oczywiście nazwami własnymi, imionami i nazwiskami itp. Karol007dyskusja 12:45, 12 cze 2008 (CEST)
Wstawianie grafiki
edytujPodsumowanie: cztery parametry: grafika (np. Przykład.jpg), rozmiar (np. 200px, z domyślnym ustawieniem), opis (opis grafiki), czwarty - link do grafiki (w formie [[:en:Image:Example.jpg|grafika]] lub [http://domena.pl/przykład.jpg grafika]), gdy nie można wstawić grafiki w zwykły sposób. Matma Rex aka matematyk 13:37, 27 lip 2008 (CEST)
[[Plik:Przyklad.jpg]]
, Grafika:Przyklad.jpg
czy samo Przyklad.jpg
? Matma Rex aka matematyk 16:46, 20 kwi 2008 (CEST)
- może być samo: grafika.jpg pod warunkiem, że będą dodatkowe parametry "szerokość" i "opis grafiki" - Beax 17:39, 20 kwi 2008 (CEST)
- Zgadzam się z przedmówcą. Matma Rex aka matematyk 17:43, 20 kwi 2008 (CEST)
- jw. Yarl read.me 19:06, 20 kwi 2008 (CEST)
- a co wtedy tysiącami grafik, które są linkami zewnętrznymi w artykułach muzycznych? ABX - (O mnie dyskutuj) 14:42, 21 kwi 2008 (CEST)
- A wtedy wstawiamy je do opisu - [1]. Matma Rex aka matematyk 15:47, 21 kwi 2008 (CEST)
- a co wtedy tysiącami grafik, które są linkami zewnętrznymi w artykułach muzycznych? ABX - (O mnie dyskutuj) 14:42, 21 kwi 2008 (CEST)
- Nad tym bym się jeszcze zastanawiał, bo tworzenie 4 parametrów opisujących grafikę (nazwa, podpis, szerokość, wysokość) komplikuje trochę sprawę uzupełniania takiego infoboksu, natomiast wstawianie grafiki tradycyjnym sposobem pozwala na więcej możliwości (mogę umieścić np. dwa zdjęcia jeśli istniałaby taka potrzeba). Beau (dyskusja) 11:20, 21 kwi 2008 (CEST)
- Trzech - wysokości się nie da ustawić. Matma Rex aka matematyk 15:47, 21 kwi 2008 (CEST)
- Zalecenia nie koniecznie muszą odnosić się do wszystkich infoboksów, wiadomo, że {{singel infobox}} czy {{Album muzyczny infobox}} jest de facto zmuszony do linków zewnętrznych. Yarl read.me 15:08, 21 kwi 2008 (CEST)
- przykład.jpg + standard 250px - dla niektórych może i większy. Operowanie wielkością można byłoby zostawić (bazowo byłoby jednak 250 lub więcej dla danego typu), ale dla artykułów danego typu szerokość infoboksu powinna być stała, bo inaczej w jednym będzie on szerszy, w innym węższy, a optycznie dla danej kategorii powinien być on jak najbardziej podobny, czyli standaryzowany. No i jeszcze co - gdy nie ma grafiki - na de wiki widziałem tzw. grafiki zastępcze - np. czarna sylwetka psa, jeśli brak obrazka. To oczywiście dotyczyć może tylko infoboksów, gdzie grafiki można dać - nie do albumów muzycznych. Przykuta (dyskusja) 15:34, 21 kwi 2008 (CEST)
- Właśnie, co do wielkości: najlepiej bazowo dawać np. 200px, ale z możliwością zmiany. Matma Rex aka matematyk 15:47, 21 kwi 2008 (CEST)
- No, ok, rzeczywiście - jeśli infoboks ma mieć 250, to grafika 200 Przykuta (dyskusja) 16:06, 21 kwi 2008 (CEST)
- Ja bym proponował 220, kiedy jest opis zdjęcia tworzy się mniej więcej równy odstęp od boków jak i dołu (przykład Jack White). Yarl read.me 16:13, 21 kwi 2008 (CEST)
- No, ok, rzeczywiście - jeśli infoboks ma mieć 250, to grafika 200 Przykuta (dyskusja) 16:06, 21 kwi 2008 (CEST)
- Właśnie, co do wielkości: najlepiej bazowo dawać np. 200px, ale z możliwością zmiany. Matma Rex aka matematyk 15:47, 21 kwi 2008 (CEST)
Nie wszędzie rozmiar musi być ustawiany, czasem lepiej go ustawić na stałe. Jak dla mnie tylko przykład.jpg, bez [[Plik:- Do tej pory tak robiłem. A_Bach - ΣΦ 00:34, 22 kwi 2008 (CEST)
- niektóre fotki są naprawdę tak kiepskie, że trzeba im zmniejszyć rozmiar (patrz: Gustaw Holoubek) i uważam, że powinno być to w osobnych parametrach:
|Grafika = <!--np. fotografia.jpg --> |Szerokość_grafiki = <!--jeśli nie wypełnisz standardowo będzie 220px--> |Podpis_grafiki =
Parametr typu |Grafika = obrazek.jpg|150px jest bezużyteczny dla części wikipedystów, którzy o tej możliwości po prostu nie wiedzą (a o to chodzi, żeby było to zrozumiałe również dla "nowych"). A że długie się robi... no cóż. - Beax 01:13, 22 kwi 2008 (CEST)
A ja preferowałbym stałe wielkości dla grafik, np. w infoboxach które robiłem zastosowałem kilka możliwości wstawiania grafik przy możliwości wstawienia 3 sztuk, do wyboru jest nawet ich układ, a wszystko się dzieje automatycznie i wystarczy tylko odpowiedni parametr/parametry uzupełnić. Z instrukcji:
- gdy "grafika1" - obrazek 270px
- gdy "grafika2" - obrazek 130px
- gdy "grafika3" - obrazek 150px
- gdy "grafika1" i "grafika2" - 2 obrazki w układzie poziomym 130px
- gdy "grafika2" i "grafika3" - 2 obrazki w układzie pionowym 130px górny i 180px dolny
- gdy "grafika1", "grafika2" i "grafika3" - 3 obrazki, z czego 1 i 2 są po 130px a 3 ma 180px
Może w tym kierunku by poszedł, ponieważ dysponując różnymi grafikami, o różnych proporcjach szerokości i długości, można dopasowywać najlepsze rozwiązanie, a wszystko jest standaryzowane i kontrolowane globalnie w skali wszystkich artykułów z danym infoboksem. Karol007dyskusja 01:10, 24 kwi 2008 (CEST)
- To już mi się wydaje sztuką dla sztuki. Poza tym, infoboxy mają raczej 250px, nie 300px, jak ten chemiczny, z którego to wziąłeś. Matma Rex aka matematyk 14:09, 24 kwi 2008 (CEST)
- Jestem za tym, aby grafiki można było wstawiać manualnie, czyli
|grafika = [[Plik:Grafika.jpg|250px|coś]]
Każda grafika wymaga właściwego dopasowania, a taki sposób pozwala na najbardziej swobodne kontrolowanie grafiki i ułatwia pracę botom podmieniającym grafiki. Hołek ҉ 10:41, 27 kwi 2008 (CEST)
A może tak:
|Grafika | nazwa = fotografia.jpg | szerokość = 220px | podpis = Zdjęcie kogoś tam gdzieś
Ten niby parametr "Grafika" to tylko komentarz dla wypełniającego i można go zmienić na dowolny inny (np. "zdjęcie zawodnika"). Myślę, że bez zaglądania w opisu infoboksu nikt by się tutaj nie pomylił.
Jeśli w danym infoboksie mogłyby być dwie i więcej grafik, to można zrobić np. coś takiego (tu dla monet):
|Grafiki | awers-nazwa = fotografia.jpg | awers-szerokość = 220px | awers-podpis = awers monety | rewers-nazwa = fotografia.jpg | rewers-szerokość = 220px | rewers-podpis = rewers monety
tu przykład bardziej dowolny
|Grafiki | nazwa_1 = fotografia.jpg | szerokość_1 = 220px | podpis_1 = Zdjęcie kogoś tam gdzieś | nazwa_2 = fotografia.jpg | szerokość_2 = 220px | podpis_2 = Zdjęcie kogoś tam gdzieś ...
Co wy na to? --Nux (dyskusja) 17:10, 2 maj 2008 (CEST)
Ja bym jednak optował za dopuszczeniem linku zewnętrznego jako grafiki oraz linku wewnętrznego jeśli jest na innojęzycznej wiki. W przypadku filmów, płyt, singli, ale też i obrazów malarzy współczesnych link zewnętrzny lub link do fair use na en-wiki jest jedyną możliwością doilustrowania artykułu. Fajnie byłoby mieć taki szablon do grafiki, który wielokrotnie użyty dawałby wiele wersji grafiki, ale użyty raz dawałby jedną i niepotrzebny byłby podział na awersy i rewersy (a po dzisiejszej wycieczce po {{Obraz infobox}} wiem że czasem potrzebnych byłoby 3 i więcej grafik). Moim marzeniem jest coś na kształt:
{{Jakiś infobox| |grafika1={{Grafika|plik=Okładka płyty.jpg|szerokość=200px|podpis=Legalnie}} |grafika2={{Grafika|interwiki=:en:Copyrighted fair use.jpg|podpis=Fair use}} |grafika3={{Grafika|url=http://domena.w.pl/obrazek.jpg|podpis=Alternatywna okładka dla VIPów}} }}
Zajmuje to tyle samo zachodu co zwykłe wpisanie [[Plik:]], [[:en:Image:...]] i [http://...] ale jednak pozwala na posiadanie jakichś parametrów domyślnych typu szerokość. Osobną kwestią jednak jest jak szablon ten komunikowałby się z szablonem w którym został użyty i sklejał odpowiednią liczbę kolumn :-) ABX - (O mnie dyskutuj) 17:37, 2 maj 2008 (CEST)
- Niestety szablony nie komunikują się ze sobą - najpierw rozwijany ten w środku, a potem zewnętrzny. Można by natomiast zrobić dodatkowy parametr "url", a można też w sumie wykorzystać "podpis" dodając w nim normalnego linka. Pewnie tylko w większości szablonów trzeba by umożliwić wyświetlanie podpisu, gdy pozostałe parametry nie są ustawione, ale to już szczegół techniczny. --Nux (dyskusja) 11:53, 3 maj 2008 (CEST)
- I to będzie IMO najlepszy pomysł, zresztą sam kiedyś tak przerobiłem jakiś szablon. Matma Rex aka matematyk 13:38, 3 maj 2008 (CEST)
Wstawianie linków zewn.
edytujPodsumowanie: z http://, sam link, bez możliwości zmiany opisu. Matma Rex aka matematyk 13:37, 27 lip 2008 (CEST)
Z http:// czy bez? Matma Rex aka matematyk 16:46, 20 kwi 2008 (CEST)
- ja też jestem za http:// - Beax 17:39, 20 kwi 2008 (CEST)
- Zgadzam się z przedmówcą. Matma Rex aka matematyk 17:43, 20 kwi 2008 (CEST)
- jw. Yarl read.me 19:06, 20 kwi 2008 (CEST)
- Popieram pomysł pełnych adresów, niekiedy trzeba podać adres z https:// i wtedy jest problem. Beau (dyskusja) 11:20, 21 kwi 2008 (CEST)
- No, jeśli jest problem, to pełny - łatwiej zresztą z paska cały skopiować. Przykuta (dyskusja) 15:35, 21 kwi 2008 (CEST)
- Jestem za pełnym adresem Karol007dyskusja 18:41, 21 kwi 2008 (CEST)
- Tutaj problem nie jest http:// lecz opis linku a więc to co następuje po spacji a przed ]. A_Bach - ΣΦ 00:34, 22 kwi 2008 (CEST)
- Domyślny - "Strona domowa", "Strona klubu" (piłkarskiego np.), "Oficjalna strona" albo jeszcze inaczej, z możliwością opcjonalnej zmiany. Matma Rex aka matematyk 18:04, 2 maj 2008 (CEST)
- Tutaj problem nie jest http:// lecz opis linku a więc to co następuje po spacji a przed ]. A_Bach - ΣΦ 00:34, 22 kwi 2008 (CEST)
- Moim zdaniem najlepiej brzmi "Oficjalna strona ..." gminy, kabaretu, artysty, aktora, czyczegośtamjeszcze. Ale w przypadku gmin polski zachowałabym dwie możliwości: BIP + oficjalna strona, bo często jest tak, że ten BIP taki ubogi jest.... a wszystkie informacje są na innej stronie www. - Beax 17:42, 8 maj 2008 (CEST)
- To wlasnie nazywa sie subiektywna ocena - bo moiim zdaniem, wyglada to wlasnie najgorzej. Uwazam, ze w ogole wstawianie opisu do adresu strony glownej firmy w infoboksie, jest pozbawione sensu - biciem piany, gdyz jest pisaniem rzeczy oczywistych. --Matrek (dyskusja) 22:37, 16 paź 2008 (CEST)
Wielkość czcionki
edytujPodsumowanie: 90% - czcionka globalna i podnagłówki, 120% - dla nagłówka nadrzędnego. Matma Rex aka matematyk 13:37, 27 lip 2008 (CEST)
Jaki powinien być rozmiar globalnej (zwykły tekst, nie tytuły itp.) czcionki (zwykle używane jest 90-100%)? Jaki powinien być rozmiar czcionki w tytułach (zwykle 110-120%)? Matma Rex aka matematyk 19:51, 20 kwi 2008 (CEST)
- 90% i 120%. Matma Rex aka matematyk 20:29, 20 kwi 2008 (CEST)
- jw. Yarl read.me 15:08, 21 kwi 2008 (CEST)
- To co pisałem poniżej przy szerokości, wszystko jest dobrze poza jednym, w infoboxach chemicznych jest 85% globalnie a nagłówki mają 140%. wszystko po to by zmniejszyć długość i szerokość infoboxu. Karol007dyskusja 20:29, 21 kwi 2008 (CEST)
- 90% to trochę za mało. Dbajcie o wzrok innych :) sugeruję minimum 92, bądź 94% - niewielka róznica ale jest :) i 120% - chyba nawet ja zacząłem pierwszy tak ustawiać właśnie. 94 i 120 :) A_Bach - ΣΦ 00:34, 22 kwi 2008 (CEST)
- Mimo wszystko obstawiałbym za 90%, różnica w pojemności jest wtedy znacząca, o cym pisał Karol. Yarl read.me 16:32, 22 kwi 2008 (CEST)
- 90% - Ci ze słabym wzrokiem niech używają Opery albo FF i używają powiększania znaków, albo mniejszej rozdzielczości --Nux (dyskusja) 07:12, 28 kwi 2008 (CEST)
- Mimo wszystko obstawiałbym za 90%, różnica w pojemności jest wtedy znacząca, o cym pisał Karol. Yarl read.me 16:32, 22 kwi 2008 (CEST)
- 90% to trochę za mało. Dbajcie o wzrok innych :) sugeruję minimum 92, bądź 94% - niewielka róznica ale jest :) i 120% - chyba nawet ja zacząłem pierwszy tak ustawiać właśnie. 94 i 120 :) A_Bach - ΣΦ 00:34, 22 kwi 2008 (CEST)
- A co z czcionką nagłówka/tytułu infoboxu? 120% to troche za mało, ja bym dał 140% a resztę nagłówków zostawił na 90%. Karol007dyskusja 10:03, 3 maj 2008 (CEST)
- IMO 120 odróżnia się wyraźnie od normalnej czcionki, a zarazem nie jest zbyt duże w srosunku do reszty. Czyli jest w sam raz. Matma Rex aka matematyk 10:35, 3 maj 2008 (CEST)
- A tytuł infoboxu, czyli pierwszy nagłówek, też na 120% czy większy? Karol007dyskusja 23:31, 3 maj 2008 (CEST)
- Znaczy, pierwszy, nadrzędny, główny nagłówek 120%, reszta (tj. w {{Związek chemiczny infobox}} "Ogólne informacje", "Identyfikacja") normalnie + tło, ew. z pogrubieniem. Matma Rex aka matematyk 23:57, 3 maj 2008 (CEST)
- A tytuł infoboxu, czyli pierwszy nagłówek, też na 120% czy większy? Karol007dyskusja 23:31, 3 maj 2008 (CEST)
- IMO 120 odróżnia się wyraźnie od normalnej czcionki, a zarazem nie jest zbyt duże w srosunku do reszty. Czyli jest w sam raz. Matma Rex aka matematyk 10:35, 3 maj 2008 (CEST)
- Ze sprawą wielkości czcionki związana jest interlinia. Przykładowo Szablon:Samolot infobox ma koszmarnie zmniejszone odstępy między wersami. Zapewne chodziło o to by był krótszy ale efekt wizualny jest mocno odpychający. Delimata (dyskusja) 14:46, 7 maj 2008 (CEST)
- Tak jest i trzeba się tym zająć (oraz innymi z kategorii militarnych). Yarl read.me 17:55, 7 maj 2008 (CEST)
- Poprawione. Yarl read.me 18:49, 7 maj 2008 (CEST)
- Ktoś niestety anulował poprawienie. Przywróciłem wersję poprawioną, ale mam niedobre przeczucie, że będą wojny edycyjne. :( Delimata (dyskusja) 20:07, 3 cze 2008 (CEST)
Kursywa w nagłówku
edytujPodsumowanie: w żadnym infoboksie nie stosujemy kursywy w nagłówku, jedynie prostą czcionkę o ustalonych już rozmiarach. Karol007dyskusja 22:13, 18 wrz 2008 (CEST)
Ja przy okazji poruszę dodatkową sprawę, dotyczącą typografii - w nagłówku infoboksu nie może być kursywy (nawet, jeśli infobox dotyczy utworu literackiego, filmowego czy innego). Gytha (dyskusja) 09:56, 1 cze 2008 (CEST)
- Słuszna uwaga, ja się z nią zgadzam, można to też dopisać Karol007dyskusja 22:39, 3 cze 2008 (CEST)
- Dotyczy to też łacińskich nazw gatunków? BartekChom (dyskusja) 14:40, 20 sie 2008 (CEST)
- W nagłówkach raczej się nie spotkałem, a tak jak tu jest chyba dobrze: Girtyoceras Karol007dyskusja 15:32, 23 sie 2008 (CEST)
- Mam zapis kursywą w nagłówku: Platystomus albinus. Czy wygląda dużo brzydziej? Czy jest o wiele bardziej poprawny? W tej drugiej kwestii najlepiej zostawić decyzję biologom. BartekChom (dyskusja) 16:51, 9 wrz 2008 (CEST)
- Oczywiście nie wygląda brzydziej, chodzi tu tylko o jednolitość takich rzeczy w całym projekcie. Tytuł artykułu zawsze jest pisany normalnie, infoboks jako duży element graficzny wypełniony danymi, występujący po prawej stronie strony, też mógłby mieć prosta czcionkę. Natomiast treść artykułu już powinna zachowywać wszelkie przyjęte standardy, czy zwyczaje stosowane w danej dziedzinie. Karol007dyskusja 20:56, 11 wrz 2008 (CEST)
- Niech będzie. W sumie też tak pomyślałem. Jak komuś się chce, to chyba można wpisać podsumowanie. BartekChom (dyskusja) 20:12, 12 wrz 2008 (CEST)
- Oczywiście nie wygląda brzydziej, chodzi tu tylko o jednolitość takich rzeczy w całym projekcie. Tytuł artykułu zawsze jest pisany normalnie, infoboks jako duży element graficzny wypełniony danymi, występujący po prawej stronie strony, też mógłby mieć prosta czcionkę. Natomiast treść artykułu już powinna zachowywać wszelkie przyjęte standardy, czy zwyczaje stosowane w danej dziedzinie. Karol007dyskusja 20:56, 11 wrz 2008 (CEST)
- Mam zapis kursywą w nagłówku: Platystomus albinus. Czy wygląda dużo brzydziej? Czy jest o wiele bardziej poprawny? W tej drugiej kwestii najlepiej zostawić decyzję biologom. BartekChom (dyskusja) 16:51, 9 wrz 2008 (CEST)
- W nagłówkach raczej się nie spotkałem, a tak jak tu jest chyba dobrze: Girtyoceras Karol007dyskusja 15:32, 23 sie 2008 (CEST)
- Dziękuję wszystkim za udział rozmowie Karol007dyskusja 22:13, 18 wrz 2008 (CEST)
Szerokość infoboksu
edytujPodsumowanie: 250px lub 300px, gdy przy 250 się nie mieści. Matma Rex aka matematyk 13:37, 27 lip 2008 (CEST)
Szerokość infoboxu (zwykle ok. 250px)? Matma Rex aka matematyk 19:51, 20 kwi 2008 (CEST)
- 250px - czytelne na dużych monitorach, znośne na małych. Matma Rex aka matematyk 20:29, 20 kwi 2008 (CEST)
- 250 - dobrze się wtedy w tej rozdzielczości grafiki pod infoboksem układają. Przykuta (dyskusja) 15:36, 21 kwi 2008 (CEST)
- 250 to dobra wielkość ale problemem są infoboxy chemiczne, wszystkie w tym momencie mają 290px i jest to optymalna wielkość dla nich, ponieważ jest wiele wpisów których dzięki temu nie trzeba dzielić na dwie linie. Karol007dyskusja 20:19, 21 kwi 2008 (CEST)
- Stałe 250px - zdażają się art. z dwoma szablonami - z jednym infoboksem i szablonem informującym, bądź dwoma infoboksami. Stała szerokość wtedy jest wymagana. A_Bach - ΣΦ 00:34, 22 kwi 2008 (CEST)
- Właśnie dlatego wszystkie chemiczne mają taką samą szerokość, bo może się tam zdążyć, że będą razem, ale to jest tylko moja uwaga. Nie spotkałem dotąd infoboxu który wymagałby takiej szerokości co wspomniany powyżej, więc wygląda na to, że jest to tylko jeden wyjątek w 4 tabelkach:( Poza tym grafiki tam, przy tej szerokości wyglądają w każdym układzie dobrze i co najważniejsze są w miarę czytelne, np. wykorzystując opisy pod grafikami jak np. glukoza. Karol007dyskusja 03:40, 22 kwi 2008 (CEST)
- Z tą stałością to i tak trzeba uważać, bo {{piłkarz infobox}} ledwo się mieści przy 300px. Yarl read.me 16:35, 22 kwi 2008 (CEST)
- Ale w takich przypadkach mamy też sekcję z nowymi propozycjami - opcjonalne ukrywanie części infoboksu. ABX - (O mnie dyskutuj) 16:51, 22 kwi 2008 (CEST)
- Wykorzystywanie pikseli jako miary to ZUO. Zdecydowanie lepiej używać firetów (em). Pozwala to na dopasowanie wielkości infoboksa do wielkości tekstów, co ma niebagatelne znaczenie dla osób zmieniających rozmiar tekstu (np. przez problemy ze wzrokiem). Hołek ҉ 10:44, 27 kwi 2008 (CEST)
- Wg mnie to kolejny mit jak ten z targetem (że niby nie można go używać w nowoczesnych stronach). Obrazki w boksach są w pikselach, to i cały boks musi być w pikselach. --Nux (dyskusja) 07:16, 28 kwi 2008 (CEST)
- To nie mit. Masz większą rozdzielczość - możesz chcieć, aby więcej było widać (patrz: długie wzory chemiczne). Obrazki nie skalują się łatwo i stosuje się miniaturki o określonej wielkości - dlatego uważam, że zdecydowanie lepiej stosować infoboksy o elastycznej szerokości. Opracowywanie standardów infoboksów na nowo pozwala na przemyślenie przy okazji, jak powinna zachowywać się treść infoboksów gdy jest mało lub bardzo dużo miejsca (np. jak zawijać powinny się wiersze i nagłówki infoboksów). « Saper // @dyskusja » 02:15, 12 cze 2008 (CEST)
- Zmiana jednostki na em nie rozwiąże tego o czym piszesz, więc podtrzymuje moje zdanie o tym micie ;). Jednak przy założeniu, że infoboks miałby jakiś jednolity układ, to można zrobić prosty skrypt, który będzie dynamicznie lub statycznie zmieniał wymiary boksa lub po prostu w swoim CSS-ie mógłbyś ustawić sobie dowolną szerokość. Ten dynamiczny mógłby wręcz rozciągać infoboks na całą szerokość. Robiłem bardzo podobny skrypt, więc mogę przyjąć zamówienia na funkcjonalność ;). --Nux (dyskusja) 22:03, 12 cze 2008 (CEST)
- To nie mit. Masz większą rozdzielczość - możesz chcieć, aby więcej było widać (patrz: długie wzory chemiczne). Obrazki nie skalują się łatwo i stosuje się miniaturki o określonej wielkości - dlatego uważam, że zdecydowanie lepiej stosować infoboksy o elastycznej szerokości. Opracowywanie standardów infoboksów na nowo pozwala na przemyślenie przy okazji, jak powinna zachowywać się treść infoboksów gdy jest mało lub bardzo dużo miejsca (np. jak zawijać powinny się wiersze i nagłówki infoboksów). « Saper // @dyskusja » 02:15, 12 cze 2008 (CEST)
- Wg mnie to kolejny mit jak ten z targetem (że niby nie można go używać w nowoczesnych stronach). Obrazki w boksach są w pikselach, to i cały boks musi być w pikselach. --Nux (dyskusja) 07:16, 28 kwi 2008 (CEST)
- Nie znam sie na tym czy lepiej jest stosować px czy %, ale może zwiększyłby szerokość z 250px na trochę większą? Byłoby to kompromisowym rozwiązaniem, skoro niektóre infoboksy wykorzystują ponad 300px. Może 280px? Karol007dyskusja 12:20, 28 kwi 2008 (CEST)
- I wtedy zwolennicy obnu szerokości będą niezadowoleni, szablony na 300 - ściśnięte, a na 250 - rozciągnięte. Matma Rex aka matematyk 15:38, 28 kwi 2008 (CEST)
Box okrętowy ma 300 i moim zdaniem jest to wartość dobra. To zależy od tego co ma być w infoboxie. Jeżeli jest aktor to zazwyczaj wpisy są kótkie - w przypadku okrętów nazwy stoczni czy ilość uzbrojenia motrafi być długim wyrażeniem. PMG (dyskusja) 14:35, 28 kwi 2008 (CEST)
- Skoro zależy, to może jednak używać dwóch różnych szerokości - 250 i 300, zależnie od tego, co znajdzie się w szablonie? Albo użyć komórek przesuwanych (#Propozycje nowych rozwiązań, końcówka sekcji)? Matma Rex aka matematyk 15:38, 28 kwi 2008 (CEST)
- Przede wszystkim te 250 px (o ile mnie pamięć nie myli) było kiedyś wałkowane w kawiarence. Niestety ciągle jeszcze nie możemy zapominać o 800x600. Przy takiej rozdzielczości szerokość pola artykułu (w domyślnej skórce), to ok. 580px, a infoboks moim zdaniem powinien być węższy niż połowa pola artykułu, czyli raczej 250px. To za jakieś dwa lata nie będzię miało znaczenia, więc byłbym za tym, żeby wrzucić to po prostu w CSS-a. --Nux (dyskusja) 22:58, 28 kwi 2008 (CEST)
Wg mnie można używać dwóch standaryzowanych szerokości, bo jest dużo różnych infoboxów o różnej ilości treści i wtedy nie byłoby problemu. Wrzucenie do CSS-a byłoby super rozwiązaniem, ale wtedy pewnie jedną szerokość najlepiej wrzucić, czy jakimś parametrem ustawiać jedną z dwóch szerokości. Jakby co to ja jestem za CSS. Karol007dyskusja 14:09, 29 kwi 2008 (CEST)
Nazewnictwo
edytujPodsumowanie: obiekt "właściciel" infobox, np. "postać Harry Potter infobox" (nie "postać z serii Harry Potter infobox"), "wieś Francja infobox" (nie "wieś Francji infobox" lub "francuska wieś infobox"). Matma Rex aka matematyk 13:37, 27 lip 2008 (CEST)
Jaki powinien być szablon nazwy infoboxów? Co do odmiany samego "infobox", raczej nie ma problemu: http://poradnia.pwn.pl/lista.php?id=698 Matma Rex aka matematyk 20:19, 20 kwi 2008 (CEST)
- obiekt "właściciel" infobox, np. "postać Harry Potter infobox" (nie "postać z serii Harry Potter infobox"), "wieś Francja infobox" (nie "wieś Francji infobox" lub "francuska wieś infobox"). Matma Rex aka matematyk 20:29, 20 kwi 2008 (CEST)
- nie mam na ten temat jeszcze zdania, ale np. {{ITA gmina infobox}} - rozpoczęcie od 3-literkowego skrótu państwa w podziałach administracyjnych bardzo mi odpowiada, choć teraz widzę, że to nie zupełnie konsekwentne jest ... bo to jednak "włoska gmina infobox" - ale nie będę się upierać, pod warunkiem że te wielkie literki FRA, ITA, RUS etc zostaną (niezależnie w którym miejscu nazwy) - Beax 01:20, 22 kwi 2008 (CEST)
Zapisywanie wywołań
edytujpierwotna dyskusja → ciąg dalszy
Generalnie używane są cztery sposoby: spacje wyrównujące, brak spacji dookoła "=" i po jednej spacji po każdej stronie "=" (niektóre stare wywołania są z "|" na końcu, te jednak są już rzadko używane i nieczytelne):
{{Wikipedia:Infoboksy/przykład 1 | nazwa = Artykuł | nazwa_grafiki = Przyklad.jpg }}
{{Wikipedia:Infoboksy/przykład 2 |nazwa=Artykuł |nazwa_grafiki=Przyklad.jpg }}
{{Wikipedia:Infoboksy/przykład 3 |nazwa = Artykuł |nazwa_grafiki = Przyklad.jpg }}
{{Wikipedia:Infoboksy/przykład 4 |nazwa = Artykuł |nazwa_grafiki = Przyklad.jpg }}
Jak powinno się zapisywać wywołania? Matma Rex aka matematyk 20:19, 20 kwi 2008 (CEST)
- Sposób 3.: spacje dookoła "=". Matma Rex aka matematyk 20:29, 20 kwi 2008 (CEST)
- o nie, pierwszy jest najlepszy. Bo jak wpisuję to mam w słupku "=" i nie muszę ganiać wzrokiem + od razu widać które są wypełnione pozycję, a które nie. - Beax 20:39, 20 kwi 2008 (CEST)
- Ale wtedy są problemy, bo, jak to powiedziała Nova: "Chodzi o to, żeby nie trzeba było potem podczas edycji za dużo kombinować, żeby ten wygląd utrzymać, ludziom się nie chce i wychodzi nieciekawie". Ten problem występuje zwłaszcza w wypadku szablonów {{cytuj x}} albo infoboxów z bardzo długim wywołaniem, w wypadku których nie zawsze kopiuje się całe wywołanie (sam kiedyś botowałem {{Roślina infobox}}, usuwając puste parametry). Matma Rex aka matematyk 22:12, 20 kwi 2008 (CEST)
- BTW, przymierzam się do napisania "porządkowacza infoboksów" w JavaScript - będzie też ładnie pokazywał parametry i pozwalał na zmianę/wypełnienie. Matma Rex aka matematyk 22:13, 20 kwi 2008 (CEST)
- Dorzuciłem jeszcze jedne przykład, uważam, że taki jest lepszy :). Co do skryptu porządkowania infoboksów, to myślałem nad jeszcze innym narzędziem. Gdyby ustandaryzować sposób ich dokumentacji, to można zrobić taki skrypt, który z takiego opisu generowałby formularz z krótkimi opisami oraz pozwalał na podgląd infoboksu (akurat ten co podałem jest specyficzny, bo nie może samodzielnie występować, ale większość infoboksów takich nie jest). Na pewno ułatwiłoby to niektórym życie (zwłaszcza jeśli zrobione byłoby to dobrze), na dodatek mam też narzędzie, które tłumaczy wywołania niektórych infoboksów (np. animanga, okręt) z en-wiki na pl-wiki. Beau (dyskusja) 11:20, 21 kwi 2008 (CEST)
- o nie, pierwszy jest najlepszy. Bo jak wpisuję to mam w słupku "=" i nie muszę ganiać wzrokiem + od razu widać które są wypełnione pozycję, a które nie. - Beax 20:39, 20 kwi 2008 (CEST)
- IMHO najlepszy sposób wywołania prezentuje przykład 4. We wszystkich stworzonych przeze mnie infoboxach zastosowałem właśnie ten sposób (z drobną różnicą), ale wszystkie chętnie bym do tego dostosował. Zapis jest przejrzysty, do tej pory nie zawodził, nie było żadnych problemów z edytującymi. Karol007dyskusja 19:00, 21 kwi 2008 (CEST)
- Trzeci - najprostrzy, najłatwiejszy, najmniej z nim roboty i problemów. A_Bach - ΣΦ 00:34, 22 kwi 2008 (CEST)
- oczywiście, że 4 jest najlepsza, ale rozumiem argumenty Matematyka. Wydaje mi się, że jeśli wprowadzimy "ładny zapis" z wyrównaniem znaku "=", to powinniśmy wprowadzić jednak "kładki" jak to ujął imć Yarl, żeby nie było tak, że wikipedysta wprowadzając nowy parametr (którego wcześniej nie było w infoboksie wstawionym w arcie) nie zrobił tak:
{{Wikipedia:Infoboksy/przykład bez sensu | nazwa = Artykuł |nazwa grafiki = Przyklad.jpg }}
Tu pytanie do fachowców, czy program w ogóle zrozumie taki rozstrzelony spacjami w środku parametr ? - Beax 01:31, 22 kwi 2008 (CEST)
- Wszystkie wielokrotne spacje pomiędzy znakiem | a początkiem nazwy parametru, oraz ostatnim znakiem parametru i znakiem = (jako znak parametru rozumiem tzw. nie biały znak) są zwyczajnie ignorowane. I dalej nawet, wielokrotna spacja po znaku równa się również jest ignorowana. Dopóki nie rozpocznie się treść parametru - wtedy jest rozumiana przez parser. Dla przykładu nie można wypełnić parametru spacją - ponieważ parser potraktuje go jako pusty. A_Bach - ΣΦ 01:35, 22 kwi 2008 (CEST)
- Ale chodzi o to, czy parser zrozumie takie rozstrzelone "nazwa grafiki". Zresztą, jednak jest jakaś różnica w interpretowaniu przez parser parametru pustego, a w ogóle nie podanego - {{infobox wiersz dodaj|{{{1}}}}} dobrze to pokazuje. Matma Rex aka matematyk 10:21, 22 kwi 2008 (CEST)
- Parser nie pomija spacji między wyrazami - tylko te na początku i na końcu. --Nux (dyskusja) 07:01, 28 kwi 2008 (CEST)
- Ale chodzi o to, czy parser zrozumie takie rozstrzelone "nazwa grafiki". Zresztą, jednak jest jakaś różnica w interpretowaniu przez parser parametru pustego, a w ogóle nie podanego - {{infobox wiersz dodaj|{{{1}}}}} dobrze to pokazuje. Matma Rex aka matematyk 10:21, 22 kwi 2008 (CEST)
- Wszystkie wielokrotne spacje pomiędzy znakiem | a początkiem nazwy parametru, oraz ostatnim znakiem parametru i znakiem = (jako znak parametru rozumiem tzw. nie biały znak) są zwyczajnie ignorowane. I dalej nawet, wielokrotna spacja po znaku równa się również jest ignorowana. Dopóki nie rozpocznie się treść parametru - wtedy jest rozumiana przez parser. Dla przykładu nie można wypełnić parametru spacją - ponieważ parser potraktuje go jako pusty. A_Bach - ΣΦ 01:35, 22 kwi 2008 (CEST)
- Trzecie wywołanie uważam za najlepsze, także ze względu na prostotę utrzymania kodu, przy późniejszych edycjach infoboksów. Nova (dyskusja) 10:34, 22 kwi 2008 (CEST)
- W sumie to też się na 3 zastanawiałem (i nadal się zastanawiam) ale przeglądnąłem artykuły i znalazłem zmienione wywołanie w amoniaku (może był używany jakiś program do edycji i dlatego spacje znikły) oraz np. woda. W przykładem 4, może się czasem zdarzyć właśnie takie wyczyszczenie spacji, co pierwszy raz obserwuje w infoboxach chemicznych. W przykładzie 3 problem może sie pojawić z czytelnością zapisu przy dłuższych wywołaniach, a wtedy kod nie wygląda zachęcająco. Po ponownym przemyśleniu, choć nie wiem czy dobrze robię, ale cały czas jestem za wywołaniem prezentowanym w przykładzie 4. Karol007dyskusja 02:35, 28 kwi 2008 (CEST)
TrójkaJedynka była stosowana od dawna i moim zdaniem się sprawdza, bo jest czytelniejsza dla wypełniającego. Aczkolwiek czasem mi się nie chciało (tudzież nie miałem czasu) wyrównywać znaków równości jak dodawałem jeden czy dwa parametry. No, ale ten sam problem jest w31 i 4. Możnaby ew. zrobić coś podobnego jak w31, tylko grupować wyrównania wg parametrów (np. tak samo wyrównywać parametry dotyczące grafiki, a pozostałe inaczej). --Nux (dyskusja) 07:01, 28 kwi 2008 (CEST) [3 → 1] w godzinach porannych mylą mi się numerki :) --Nux (dyskusja) 21:53, 8 maj 2008 (CEST)
- OK, na razie trochę niechętnie ale zgadzam się na przykład 3. PS.W razie jakichkolwiek zmian, infoboxami chemicznymi (i innymi w naukach przyrodniczych) sam się zajmę:-) Karol007dyskusja 12:02, 28 kwi 2008 (CEST)
- to może małe głosowanko ? przeważają opcje 3 i 4, więc nie ma co rozważać innych możliwości (to czy z podkreśleniem czy bez - nie ma teraz znaczenia):
opcja 1
|
opcja 3
|
opcja 4
|
d1 Yarl read.me 21:10, 8 maj 2008 (CEST) głównie ze względu na boty
- A co to za różnica dla botów? --Nux (dyskusja) 21:53, 8 maj 2008 (CEST)
Przy wrzucaniu nowych haseł może i nie ma problemu, ale przy poprawianiu zmiennych trzeba kombinować ze spacjami żeby się nie rozłaziło. Poza tym przy jednej długiej nazwie znaki "=" lądują w połowie okna edycji. Yarl read.me 22:42, 8 maj 2008 (CEST)
- Jak już znajdziesz infobox w artykule, to wystarczy znaleźć np. pierwszy znak równości w drugim wierszu infoboksa. Poza tym jestem zdania, że to boty mają się męczyć dla użytkowników, a nie odwrotnie ;P. Chociaż nie powiem, że nie rozumiem wzbrania się - sam męczyłem się ostatnio ze skryptem do formatowania boksa.
- Natomiast jeśli nazwy parametrów będą długie, to i tak będą chyba, że je skrócimy. Tam gdzie muszą być długie można by moim zdaniem grupować parametry lub (żeby ułatwić automatyczne przetwarzanie) zrobić jakiś sztywny limit (np. że od początku linii do znaku równości może być max 20 znaków). --Nux (dyskusja) 01:13, 9 maj 2008 (CEST)
d2 ABX - (O mnie dyskutuj) (opcja 4 częściowo gryzie się z funkcjonalnością WP:SK która (imo słusznie) kasuje puste przestrzenie)
- WP:SK nie kasuje podwójnych spacji, więc nikt nikogo nie gryzie. Nawet dobrze, że WP:SK nie kasuje spacji, bo od razu widać zdania przeklejone z filmwebu :-))) - Beax 19:15, 9 maj 2008 (CEST)
- Kasuje po skonfigurowaniu, poszukaj "wielokrotne spacje" w MediaWiki:Gadget-wp sk.js. ABX - (O mnie dyskutuj)
- Jeśli skrypt robi coś źle, to IMHO nie ma dla niego żadnego usprawiedliwienia ;). Tu natomiast jest to po prostu niewłaściwe wykorzystanie skryptu. Od dawna obowiązywał standard, że spacji używa się w szablonach do wyrównywani znaków równości. Spacji używa się ponadto np. w kodach źródłowych. --Nux (dyskusja) 02:22, 10 maj 2008 (CEST)
- Kasuje po skonfigurowaniu, poszukaj "wielokrotne spacje" w MediaWiki:Gadget-wp sk.js. ABX - (O mnie dyskutuj)
Zapisywanie wywołań - podejście 2
edytujPodsumowanie: wersja hybrydowa, czyli spacje wokół pipe'a oraz wokół znaków "=", rezygnujemy z wyrównania parametrów. Karol007dyskusja 22:21, 18 wrz 2008 (CEST)
Otwieram ponownie dyskusję. Obecnie w WP:SK dodawane są spacje na początku wiersza parametrów. Jestem w stanie też zrobić dodawanie spacji wg prawie dowolnego schematu. Myślę, że bez większych problemów boty też mogłyby wrzucić sobie taki algorytm. Także problem techniczny z głowy. Teraz pytanie - w której wersji łatwiej Wam odczytać i zmienić wartości parametrów:
- wersja ze spacjami
parametry do lewej
{{Jakiś infobox | nazwa jakaś = Nazwa czegoś | stopniN = 52 | minutN = 13 | sekundN = 56.28 | stopniE = 21 | minutE = 00 | sekundE = 30.36 | wysokość = 78-115 | rok = 2007 }} |
parametry do prawej
{{Jakiś infobox | nazwa jakaś = Nazwa czegoś | stopniN = 52 | minutN = 13 | sekundN = 56.28 | stopniE = 21 | minutE = 00 | sekundE = 30.36 | wysokość = 78-115 | rok = 2007 }} |
- wersja bez spacji
{{Jakiś infobox |stopniN = 52 |minutN = 13 |sekundN = 56.28 |stopniE = 21 |minutE = 00 |sekundE = 30.36 |wysokość = 78-115 |rok = 2007 }}
Dodam tylko, że moim zdaniem dzięki spacjom po lewej od "|" łatwiej jest zobaczyć gdzie kończy się infoboks - zajrzyjcie w kod i sami oceńcie. Moim zdaniem po naszej dyskusji powinno rozpocząć się właściwe głosowanie, bo to jest zmiana, która będzie miał znaczący wpływ na wszystkich Wikipedystów(-ki). --Nux (dyskusja) 00:12, 23 sie 2008 (CEST)
- IMO najlepsza byłaby hybryda pierwszej twojej propozycji i wersji bez spacji, tj.
{{Jakiś infobox | rok = 2007 }}
- Łączy czytelność i to, że nie trzeba się bawić w wyrównywanie spacji. BTW, taką właśnie wersję zaimplementowaliśmy z ABX-em w wypełniaczu infoboksów, choć to oczywiście można bezproblemowo zmienić. Matma Rex aka matematyk 09:34, 23 sie 2008 (CEST)
- Jak najbardziej za. Yarl ✉ 12:51, 23 sie 2008 (CEST)
- Ja się cały czas waham, czytelność np. czegoś takiego Akrylonitryl lub Alkohol furfurylowy spadnie, ale w razie czego nie będę robił problemów, nie jestem konserwatystą w tej kwestii. Karol007dyskusja 15:39, 23 sie 2008 (CEST)
- Ale to już kwestia ogólnie długości tego infoboksu chemicznego. Ze spacjami, jak teraz, też jest on dla mnie nieczytelny bo niektóre wiersze przy tej długości się zawijają i rozbijają "rysunek" - pytanie czy {{związek chemiczny}} nie powinien być jakimś infoboxem nadrzędnym dla dokładniejszych infoboksów typu "tlenek infobox, kwas infobox" bo widzę że sporo parametrów jest nieużywanych - tak czy inaczej tu ewidentnie potrzebne jest wydzielenie go z kodu w ramach rozwoju okna edycji do WYSIWYGu, w bieżacym stanie ja osobiście jestem za wersją Matmy, bez spacji wokół znaku równości, ze spacjami wokół separatora parametrów. ABX - (O mnie dyskutuj) 10:55, 25 sie 2008 (CEST)
- Ja się cały czas waham, czytelność np. czegoś takiego Akrylonitryl lub Alkohol furfurylowy spadnie, ale w razie czego nie będę robił problemów, nie jestem konserwatystą w tej kwestii. Karol007dyskusja 15:39, 23 sie 2008 (CEST)
Skoro mamy jakąś tam wersję kompromisową, to może wprowadzić te zmiany jak najszybciej do WP:SK? bo na razie dodaje tylko spacje przez "|" jeszcze trzeba dac po, oraz usuwanie zbędnych spacji przed "=" i dodawanie lub usuwanie spacji z drugiej strony "=" (tak żeby było otoczone tylko przez jedną spację. Karol007dyskusja 00:59, 28 sie 2008 (CEST)
Przydałoby się też przerzucanie pipe'a z prawej strony infoboksu do lewej. Czasami można jeszcze znaleźć takie archaizmy. Yarl ✉ 10:39, 28 sie 2008 (CEST)Nieważne, już jest. Yarl ✉ 11:48, 28 sie 2008 (CEST)- Czasami nazwa infoboksu zapisana jest z małej litery (Athabaska (jezioro)). Można było też to poprawiać. Yarl ✉ 11:48, 28 sie 2008 (CEST)
- Mnie się wydaje jednak, że dodawanie spacji przed pipem jest zbędne i pogarsza organizacje wywołania, natomiast dodanie po poprawia czytelność (pipe nie skleja się z nazwą pola, podobnie znak równości). Beau (dyskusja) 12:21, 28 sie 2008 (CEST)
- Zdefiniuj "organizację wywołania" ;-) mnie ta spacja pozwala łatwiej wyłapać wzrokiem kończący "}}" ABX - (O mnie dyskutuj) 12:39, 28 sie 2008 (CEST)
- Mnie się wydaje jednak, że dodawanie spacji przed pipem jest zbędne i pogarsza organizacje wywołania, natomiast dodanie po poprawia czytelność (pipe nie skleja się z nazwą pola, podobnie znak równości). Beau (dyskusja) 12:21, 28 sie 2008 (CEST)
- Mnie się też podoba wersja z pauzami wokół pipe'a. Wersja bez wyrównywania znaków "=" jest wg mnie lepsza - w przeciwnym razie mogą być kłopoty przy dodawaniu nowych parametrów do infoboksa albo czymś podobnym. ToSter→¿? 16:18, 28 sie 2008 (CEST)
- Zero problemów - WP:SK może dodać spacje za Ciebie. Są natomiast inne problemy i to przy wszystkich rozważanych opcjach - a) W części infoboksów parametry podawane są w jednym wierszu m.in. dlatego, że dotyczą tego samego (np. grafiki omawiane powyżej i podobnie w propozycji dot. koordynatów), ale jest też inna kwestia... b) Co z komentarzami, które występują w niektórych wywołanich infoboksów? Usuwać, przenosić, dodawać jako sztuczny parametr w tym samym wierszu?... --Nux (dyskusja) 03:13, 29 sie 2008 (CEST)
- Co do "kompromisu" - w naszej sondzie było praktycznie 50/50 - to nie jest konsensus. Poza tym ciągle nie widzę realnego powodu, dla którego mielibyśmy rezygnować z wyrównywania znaków równości. Rezygnować, bo przypominam, że to jest właśnie bieżący zwyczaj - wyrównywanie znaków równości. Technicznie dodanie spacji to żaden problem. Natomiast większość przeciwników spacji jako powód podaje jedynie problemy techniczne, których de facto nie ma. Poprawcie mnie jeśli się mylę, ale jedynym argumentem poza technicznym była długość wiersza przy długich nazwach parametrów. --Nux (dyskusja) 03:13, 29 sie 2008 (CEST)
- W tym miejscu muszę przyznać rację przedmówcy. A może sprawdzić jaka jest tendencja na innych wiki i niech ten "głos" zadecyduje? Karol007dyskusja 23:51, 29 sie 2008 (CEST)
- Chyba lepiej byłoby zrobić głosowanie - po tygodniu mamy koniec dyskusji. Jak nie będzie konsensu, zostawiamy po staremu. Yarl ✉ 10:13, 30 sie 2008 (CEST)
- Jestem za, ale zdefiniuj "po staremu". Matma Rex aka matematyk 12:25, 30 sie 2008 (CEST)
- "Po staremu", czyli zasadniczo od dawien dawna wyrównujemy znaki równości. Gorzej z kwestią pipe'a - od ponad dwóch lat jest on z lewej i chociaż nikt wówczas nie protestował, to jednak wcześniej pipe'y były po prawej. No, ale tu jak rozumiem wszyscy się zgadzamy, że mają być jednak po lewej.
- Przy tej okazji mam dobrą wiadomość - właśnie sprawdziłem, że można wrzucić komentarz w parametr i nie ma to znaczenia dla funkcji parsera (dalej jest on traktowany jak pusty), co oznacza, że jeden ze wspomnianych przez mnie problemów można uznać za rozwiązany. Pozostaje problem wielu parametrów w jednym wierszu. Jestem w stanie zrobić tak, żeby zostawały, ale pytanie czy tego chcemy, czy nie. --Nux (dyskusja) 14:34, 30 sie 2008 (CEST)
- Mnie się dodatkowe spacje po prostu nie podobają :) kiedy jest jeden parametr "rok", a drugi "blablablablablablablabla", to to nie wygląda za dobrze, poza tym zawsze zwiększa to rozmiar strony o parę bajtów. Ale jeśli już wyrównywać parametry, to do lewej. Koordynaty powinny być w jednej linii (stopnie, minuty, sekundy). A WP:SK jednak używa raczej mniejszość.
- Skoro dyskusja chyli się ku końcowi, można by chyba zacząć wprowadzać zmiany w życie. Jest wiele infoboksów, w których panuje wielki bałagan z nazwami parametrów - tu spacje, tu podkreślenia, tu brak, tu duża, tu mała litera (np. {{Góra infobox}}, {{Piłkarz infobox}}. Boty pewnie się trochę powinny napracować. Przy okazji - w wielu wywołaniach infoboksu góry (weźmy sobie np. Zadni Gerlach) są totalnie pomieszane kolejności paramtrów. Na podstawie "uczłowieczania infoboksów" napisałem i dodałem do wp:sk sobie skrypt (może nie jest to mistrzostwo programowania w JS, ale działa :)), który te parametry sortuje - można to jakoś uogólnić na inne infoboksy i/lub dodać do wp:sk albo przelecieć botem. ToSter→¿? 21:46, 30 sie 2008 (CEST)
- Ale trzeba do tego tworzyć osobne bazy danych. Można jednak zaimplementować takie coś też w wypełniaczu infoboksów, który ma być także edytorem, ale edycja nie całkiem działa (choć już prawie). Z kolei bazy z kolejnością i nazwami parametrów są tu: user:Matma Rex/infoboksy.js, można je wciągać przez importScript('user:Matma Rex/infoboksy.js'). A jeśli ktoś przerobi to na C (moduł do AWB) lub Pythona (pywikipedia), będzie można botować. Matma Rex aka matematyk 10:15, 31 sie 2008 (CEST)
- Moim zdaniem to słabe rozwiązanie dla WP:SK, bo to by było za duże i za często trzeba by aktualizować, ale przy botach to może nie ma aż takiego znaczenia. --Nux (dyskusja) 11:16, 1 wrz 2008 (CEST) PS: Matma Rex zajrzyj do Nux/wp_sk.js - jest tam regexp łapiący dowolny szablon, a w środku jest escapowanie znaków pipe w wewnętrznych szablonach i linkach - potem wystarczy tylko splitnąć po pipe'ie i masz wszystkie parametry.
- Ale trzeba do tego tworzyć osobne bazy danych. Można jednak zaimplementować takie coś też w wypełniaczu infoboksów, który ma być także edytorem, ale edycja nie całkiem działa (choć już prawie). Z kolei bazy z kolejnością i nazwami parametrów są tu: user:Matma Rex/infoboksy.js, można je wciągać przez importScript('user:Matma Rex/infoboksy.js'). A jeśli ktoś przerobi to na C (moduł do AWB) lub Pythona (pywikipedia), będzie można botować. Matma Rex aka matematyk 10:15, 31 sie 2008 (CEST)
- Jestem za, ale zdefiniuj "po staremu". Matma Rex aka matematyk 12:25, 30 sie 2008 (CEST)
- Chyba lepiej byłoby zrobić głosowanie - po tygodniu mamy koniec dyskusji. Jak nie będzie konsensu, zostawiamy po staremu. Yarl ✉ 10:13, 30 sie 2008 (CEST)
- zdecydowanie wersja z "po jednej spacji wokół pipe". Tak, wiem że to rzecz gustu, ale dla mnie kod wyrównany do prawej jest nieczytelny. W oknie edycji i w artykułach wszystko jest wyrównywane do lewej, ewentualnie wyjustowane, nigdy do prawej, ten kod, odstaje od wszystkiego innego na stronach Wikipedii. ABX - (O mnie dyskutuj) 11:27, 1 wrz 2008 (CEST)
- Nux, zaraz sprawdzę regexpa i postaram się użyć, dzięki. Matma Rex aka matematyk 12:14, 1 wrz 2008 (CEST)
- "Wersja ze spacjami" jakoś mnie drażni. Za dużo niepotrzebnych spacji. Zdecydowanie najlepsza "hybryda". BartekChom (dyskusja) 16:45, 9 wrz 2008 (CEST)
- Zgodnie z ustaleniami, oraz wprowadzonymi już zmianami w infoboksach będzie wersja hybrydowa Karol007dyskusja 22:21, 18 wrz 2008 (CEST)
Wiele parametrów w jednej linii
edytujPodsumowanie: współrzędne pogrupowane, inne w bardzo uzasadnionych przypadkach ToSter→¿? 23:54, 28 wrz 2008 (CEST)
Chciałbym zaproponować mini sondę odnośnie wielu parametrów w jednej linii - przykład poniżej. --Nux (dyskusja) 11:16, 1 wrz 2008 (CEST)
każdy w osobnym wierszu
{{Jakiś infobox | nazwa jakaś = Nazwa czegoś | stopniN = 52 | minutN = 13 | sekundN = 56.28 | stopniE = 21 | minutE = 00 | sekundE = 30.36 | wysokość = 78-115 | rok = 2007 }} |
parametry mogą być pogrupowane
{{Jakiś infobox | nazwa jakaś = Nazwa czegoś | stopniN = 52 | minutN = 13 | sekundN = 56.28 | stopniE = 21 | minutE = 00 | sekundE = 30.36 | wysokość = 78-115 | rok = 2007 }} |
- Jestem za grupowaniem jeśli parametry były pogrupowane (+ ew. te które ustalimy, że zawsze są grupowane - koordynaty? parametry grafiki?) --Nux (dyskusja) 11:16, 1 wrz 2008 (CEST)
- Ja jestem zdecydowanie za:
{{Jakiś infobox | nazwa jakaś = Nazwa czegoś | stopniN = 52 | minutN = 13 | sekundN = 56.28 | stopniE = 21 | minutE = 00 | sekundE = 30.36 | wysokość = 78-115 | rok = 2007 }}
ale nie miałem niestety okazji wypowiedzieć się co do spacji wcześniej. ABX - (O mnie dyskutuj) 11:25, 1 wrz 2008 (CEST)
- Ja jestem za grupowanie tylko i wyłącznie koordów geograficznych, ew. innych ściśle połączonych rzeczy, na pewno nie parametrów grafiki. Matma Rex aka matematyk 12:14, 1 wrz 2008 (CEST)
- Jak wyżej, chociaż zmienne grafik mogły być częściowo grupowane, np. grafika= a w następnej linii opis= i szerokość=. Yarl ✉ 12:23, 1 wrz 2008 (CEST)
- Zgadzam się z ABX-em. ToSter→¿? 12:56, 1 wrz 2008 (CEST)
- Ja jestem przeciwko grupowaniu. Znacznie wygodniej się uzupełnia gdy każdy parametr jest w osobnej linii. ‹ Dobromiła | odpowiedź › 14:12, 11 wrz 2008 (CEST)
- Ja za grupowaniem. Krótkie ściśle powiązane parametry takie jak współrzędne albo kody ISO w {{język infobox}} powinny być razem, żeby nie zajmować miejsca. BartekChom (dyskusja) 15:43, 19 wrz 2008 (CEST)
Wstawianie linków wewnętrznych
edytujPodsumowanie: jeśli nie ma to dodatkowej funkcji (np. dodanie do kategorii z odpowiednim rokiem), nie tworzymy linków automatycznie w infoboksach. Matma Rex aka matematyk 13:37, 27 lip 2008 (CEST)
Istnieje chyba kilka infoboxów, które "automatycznie" tworzą linki wewnętrzne z parametrów. Np. Szablon:USA hrabstwo infobox i pole stan. Aby wywołać "Nowy Jork", należy wpisać "Nowy Jork" w polu stan_short i "Nowy Jork (stan)" w polu stan. ("Nowy Jork" linkuje po prostu do miasta). Wydaje mi się, że takich praktyk należałoby odradzać. Prościej chyba jest użyć linków wewnętrznych (i.e. [[Nowy Jork (stan)|Nowy Jork]] w polu stan. Z kolei w innych infoboxach (np. Szablon:Uczelnia infobox, linki są wstawiane automatycznie (np. rektor czy lokalizacja). Stopniowo będzie to prowadziło do problemów, bo jeżeli rektorem jest ktoś o popularnym imieniu nazwisku, to albo link będzie prowadził do strony ujednoznaczniającej, albo będzie wyświetlał "Jan Kowalski (rektor)". Przykład: w haśle Uniwersytet Cambridge mamy lokalizacja: "Cambridge (miasto w Anglii) (Wielka Brytania)", wygląda trochę nienaturalnie moim zdaniem i nie ma jak poprawić. Reasumując, uważam, że tworzenie linków wewnętrznych jest na tyle łatwe i każdy wikipedysta musi to znać, że tworzenie ich na poziomie infoboxu nic nie ułatwia i nie powinno mieć miejsca (wyjątek - linki tworzone bez użycia parametrów). Co sądzicie? duch Qblika seansik? 15:52, 21 kwi 2008 (CEST)
- Owszem, znacznie lepiej normalne linki. BTW, można chyba obejść to ograniczenie, o którym mówisz, przez użycie {{!}}. Matma Rex aka matematyk 15:56, 21 kwi 2008 (CEST)
- W albumach i singlach pola z rokiem są wypełniane liczbą i automatycznie konwertowane do linka [[:Kategoria:XXXX w muzyce]] - byłbym za tym żeby tę cechę utrzymać ponieważ powoduje też ona automatycznie dodanie kategorii Albumy/Single wydane w roku XXXX do całego artykułu. To pozwala na szybkie porządkowanie kategorii z setkami i tysiącami albumów i singli (w tej chwili trwa czyszczenie pod tym względem). ABX - (O mnie dyskutuj) 16:31, 21 kwi 2008 (CEST)
- Popieram ABX-a. W tego typu przypadkach, gdzie jest dodatkowa funkcjonalność, trzeba zrobić wyjątek. duch Qblika seansik? 16:35, 21 kwi 2008 (CEST)
- Bardzo fajna sztuczka z tym {{!}}. Nie wiedziałem o tym. Ale i tak uważam, że zwykłe linkowanie jest prostsze. duch Qblika seansik? 16:41, 21 kwi 2008 (CEST)
- ABX: jak najbardziej. Poza tym, przecież tam nigdy nie będzie trzeba wstawiać do linków niczego po "|".
Qblik: też tak uważam. To może służyć jako rozwiązanie tymczasowe (chociaż podobno prowizorka zawsze trzyma się najlepiej). Matma Rex aka matematyk 16:50, 21 kwi 2008 (CEST)
- ABX: jak najbardziej. Poza tym, przecież tam nigdy nie będzie trzeba wstawiać do linków niczego po "|".
- Jeszcze jedno do tej dyskusji - w przypadku automatycznego robienia odnośników nie da się wstawić żadnego przypisu w to pole. Czyli ani odnośnika do źródła ani żadnych uwag. Imho to zbyt duża strata funkcjonalności, zatem uważam, że nie powinno się tak robić. ‹ Dobromiła | odpowiedź › 14:17, 11 wrz 2008 (CEST)
- Infobox w domyśle powinien zawierać bazodanowe ujęcie treści artykułu. Każda informacja w formie uproszczonej która do niego trafia powinna być również w samym artykule, z tego też względu jeśli jest potrzeba dodania przypisu to może a nawet powinien on trafić do właściwego zapisu w tekście. ABX - (O mnie dyskutuj) 14:24, 11 wrz 2008 (CEST)
Kod
edytujPodsumowanie: Używamy szablonów infoboksów; kolory komórek obecne, kolory nagłówków dowolne (z umiarem). Yarl ✉ 13:09, 21 sie 2008 (CEST)
Kolejna rzecz do omówienia. nawiązuję tu do infoboksu książki - czyli dwie sprawy. Kolory komórek - tutaj sugeruję dokładnie tak jak jest w {{infobox wiersz dodaj}}. Druga sprawa to kod, czyli czy ułatwiać sprawę i używać szablonów specjalnych czy może WP:FP tylko. Problem ten najlepiej jest widoczny we wspomnianym infoboksie Holka. A_Bach - ΣΦ 10:02, 22 kwi 2008 (CEST)
- {{Infobox wiersz dodaj}} i pochodne to bardzo fajna sprawa, nie trzeba kombinować z FP i wstawianiem znaków "|", aby zrobić komórkę tabeli. Matma Rex aka matematyk 10:22, 22 kwi 2008 (CEST)
- Osobiście wolę FP, ponieważ mam większą kontrolę nad zachowaniem infoboksu. Hołek ҉ 10:46, 27 kwi 2008 (CEST)
- FP przydają się właśnie wtedy, gdy coś się chce wstawić w specyficzny sposób, a {{Infobox wiersz dodaj}} w pozostałych wypadkach. Jest też lepszy, bo łatwiejszy do zrozumienia dla nowych - też jest niekiedy skompikowany, ale mniej. Zresztą, wspomniany {{Książka infobox}} wygląda w zasadzie tak, jakby subst:ować w nim {{Infobox wiersz dodaj}} i zamienić niektóre komórki na nagłówkowe. Matma Rex aka matematyk 11:31, 27 kwi 2008 (CEST)
- Co do kolorów komórek, w ogóle kolorów. Ja jestem przeciwnikiem robienia z Wikipedii tzw. choinki. Uważam, że w kolorach infoboksów powinniśmy ograniczyć się do białego i szarego (kolorów pasujących do powagi encyklopedii), tak jak chociażby w Przedsiębiorstwo infobox. Wiktoryn <odpowiedź> 03:48, 28 kwi 2008 (CEST)
- Ale to jest z kolei bardzo "bure". Proponuję raczej jakiś delikatny beżowy dla komórek. A dla nagłówków (głównego i pobocznych) mogą być różne kolory (byleby nie jaskrawe) w zależności od typu - patrz {{wojna infobox}}. Matma Rex aka matematyk 11:07, 28 kwi 2008 (CEST)
- Sprzeciw :) jestem za tym żeby każda dziedzina posiadała swój kolor (idealnie byłoby by był to kolor zbliżony do koloru stron portalu/wikiprojektu zajmującego się tą dziedziną). Choince mówmy nie wtedy kiedy mamy 6 kolorów na ramkę wypukłą, ramkę wklęsłą, margines, tło etykiet, tło opisów oraz ikonki do commons, flagi itp. Ale jednolity styl w 2000 zespołów muzycznych to imo dobra rzecz. Jest naprawdę dużo kolorów które nie czynią choinki a wciąż są kolorem ;) ABX - (O mnie dyskutuj) 11:11, 28 kwi 2008 (CEST)
- Ja jestem za obecnymi kolorami dla komórek (odcienie szarości), a w nagłówkach w obrębie jednej dziedziny należy bezwzględnie zachować jednolitość kolorów i powinny być to kolory wyłącznie pastelowe lub inne delikatne, nie rażące oczu odcienie. To jest encyklopedia więc pstrokaciźnie mówię STOP, ale delikatne kolorki infoboxu ożywią trochę artykuł. Karol007dyskusja 12:09, 28 kwi 2008 (CEST)
- Raczej wyważone, pastelowe kolory - tak, ale odcienie szarości, to IMHO przesada --Nux (dyskusja) 22:58, 28 kwi 2008 (CEST)
- Ja jestem za obecnymi kolorami dla komórek (odcienie szarości), a w nagłówkach w obrębie jednej dziedziny należy bezwzględnie zachować jednolitość kolorów i powinny być to kolory wyłącznie pastelowe lub inne delikatne, nie rażące oczu odcienie. To jest encyklopedia więc pstrokaciźnie mówię STOP, ale delikatne kolorki infoboxu ożywią trochę artykuł. Karol007dyskusja 12:09, 28 kwi 2008 (CEST)
Interlinia
edytujPodsumowanie: Nie definiujemy interlinii, zostawiamy wartość domyślną (line-height:150%). Yarl ✉ 12:31, 21 sie 2008 (CEST)
Skoro Yarl mnie zaprosil (po "popsuciu" ;P w miare ustandaryzowanego infoboxu militarnego) to pytam na zasadzie przykladu: Mamy takie sobie militarne infoboxy, nie wszystkie jeszcze ujednolicone, ale czy teraz ten samolotowy nie wydaje sie nieco za duzy? Rozmawialismy o tym w Wikiprojekt:Militaria i generalnie wyszlo na to o ile dobrze pamietam (bo dlatego tak robilem) ze line-height jest dobra jako 100%. Oczywiscie nie upieram sie przy ale to jak teraz wyglada "samolotowy" jest koszmarem. Czyz nie? Uprzedzam ze nie przeczytalem calego watku narazie wiec nie wiem czy sie nie powtarzam z kims innym, zrobie do jutro wnikliwie. Pozdrawiam, SPIKE NIE DYSKUTUJ 05:45, 4 cze 2008 (CEST) A za to naglowki sa teraz "nadziubdziane" boldem bez letter-spacingu w poziomie ze ciezko sie czyta :P
- Mnie bardziej niż wielkość całego infoboksu razi stykanie się kolejnych wierszy tekstu. Ja rozumiem, że można chcieć zmniejszać interlinię, ale są pewne granice estetyki. Mam nadzieję, że wyjdzie z tego jakiś kompromis. Poza tym jestem zwolennikiem standardyzacji wszystkich infoboksów a nie tylko w obrębie militarnych tak więc dobrze byłoby by wnioski z wewnątrzmilitariowych dyskusji krótko i węzłowato tutaj przedstawić. Może ktoś coś z tego zaczerpnie, może ktoś coś fajnego wam podpowie. :) Delimata (dyskusja) 08:20, 4 cze 2008 (CEST)
- IMO rozmiary tekstu najlepsze są w {{Pocisk rakietowy infobox}}. W samolotowym jest mała czcionka i wielka interlinia, w "czołgowym" lub tym od broni palnej jest rzeczywiśćie "nadziubdziane". A jak są za długie, to może coś by z infoboxu wywalić albo scalić kilka wierszy w jeden (np. z wymiarami tak można chyba zrobić)? Matma Rex aka matematyk 09:44, 4 cze 2008 (CEST)
- Zgadzam się. Pociski rakietowe są ok. Można manewrować rozmiarem czcionek i ewentualnie marginesami wewnętrznymi komórek. Poza tym pamiętajmy, że dość często nie wszystkie dane są wypełnione i wtedy infobox jest znacznie krótszy. Delimata (dyskusja) 10:00, 4 cze 2008 (CEST)
- Wlasnie rozmiarem czcionek to bym nie manewrowal (tu akurat konsultowalismy sie z Julo ktory sie na tym zna, eksperymentowalismy z roznymi przegladarkami, sprawdzalem na wydruku itp.) - 93% powinna byc najmniejsza. Nie rozumiem co "margines wewnetrzny" ma do wysokosci infoboxu. Co do "scalania" i kombinowania merytorycznego - hm... to juz chyba wykracza poza pomysl "ujednolicania" i takie sugestie moga skonczyc sie Iwojimą choc czesc z nas (m.in. ja) zgadzam sie z tym ze na detale w infoboxie nie ma miejsca - np. w ramach wlasnych kompetencji razem z Nemo przerobilismy {{Czołg infobox}} na {{Czołg infobox v2}}. Ale ruszanie "czyichs" infoboxow od strony merytorycznej uzasadniajac to wada wzroku ;) spotka sie chyba wszedzie z silnym oporem. Troche "nadziubdziane" robi sie faktycznie gdy komorka ma wiecej niz jeden wiersz, jesli pozostaja "jednowierszowe to chyba nie jest "za ciasno"? Czy wg Was tez? SPIKE NIE DYSKUTUJ 14:07, 4 cze 2008 (CEST)
- Gdy są "jednowierszowe" to właściwie nie ma mowy o żadnej interlinii. Wtedy z natury rzeczy jest ok. Delimata (dyskusja) 15:21, 4 cze 2008 (CEST)
- Co do wypowiedzi Spike'a: rozmiar czcionki był dyskutowany, patrz wyżej. A co do długości to nie widzę problemu w długim infoboksie. W końcu chyba lepiej, żeby zostawić miejsce pomiędzy komórkami, niż "zgniatać" tekst w celu zmieszczenia się w jednym ekranie? Yarl read.me 15:43, 4 cze 2008 (CEST)
- Hm. Mam wrazenie ze bedzie fight ze wszystkimi, z jednego prostego powodu: Tu 3-4 ludzi chce ustalic to co robi 30-40 innych w konsultacji z 300-400 innymi (dane zmyslone, ekstrapolowane na przykladzie WP:Militaria). Rownie dobrze moglbym zarzuty Delimaty odeprzec: "a mnie sie podoba tak jak ja robie, nie podoba mi sie rozciagniety infobox z drobniutka czcionka bo wyglada jak mak na obrusie". Wszystko kwestia gustu, sugerowanie ze "Ci ktorym czcionka jest za mala niech uzywaja O lub FF i powiekszaja" tylko podkresla subiektywny charakter takich argumentow. 93% zostalo osiagniete droga konsensusu na projekcie, chociaz ja bylem za 90% wlasnie, i podobnie w navboxach ;). Moze line-height na 100% to faktycznie za malo ale standardowo jest o wiele za duzo, moim zdaniem najlepiej byloby poeksperymentowac i zmniejszyc wysokosc komorek a line-height zostawic w spokoju ale jeszcze tego nie obejrzalem technicznie, tak zeby odleglosc miedzy komorkami np byla taka jak w zwyklym tekscie. A wracajac do przedmowcy - "Gdy są "jednowierszowe" to właściwie nie ma mowy o żadnej interlinii. Wtedy z natury rzeczy jest ok." - nie prawda, pozostawienie line-height w spokoju wlasnie rozciaga infobox wtedy tez. Yarlowi proponuje pogrzebac w {{Okręt infobox}}, {{Okręt rozszerzony infobox}} i {{Typ okrętu infobox}} a potem czekac na salwy z USS "PMG" ;) SPIKE KSIĄŻKA SKARG I ZAŻALEŃ 09:52, 5 cze 2008 (CEST)
- Jeśli w infoboxie znajdują się podstawowe informacje a jego długość jest większa niż innych to nie powinno się go ruszać, bo to spowoduje zubożenie informacji. Długie infoboxy można skracać poprzez zwijanie wierszy jako nowe rozwiązanie techniczne, które gdzieś powyżej było podane:) Karol007dyskusja 09:56, 5 cze 2008 (CEST)
- Mam wrazenie ze bedzie fight ze wszystkimi, z jednego prostego powodu: Tu 3-4 ludzi chce ustalic to co robi 30-40 innych w konsultacji z 300-400 innymi (...). No właśnie po to jest wikiprojekt, aby nie forsować w kilku standardów rzutujących na wszystkie szablony. Jest informacja w obserwowanych, była informacja na TO, więc o co chodzi? Przecież nie będziemy szukać rozmówców na siłę. Yarl read.me 11:34, 5 cze 2008 (CEST)
- Wiekszosc wikipedystow ma znacznie ciekawsze zajecia niz czytac jakies przydlugawe i do niczego zwykle nie prowadzace dyskusje o jakichs standardach infoboxow. Sam zajrzalem tu wylacznie zachecony przez Spika, ale jak ustalic standardy? Dla mnie na przyklad wazniejsza od dlugosci infoboksu sprawa jest jego kompletnosc w zakresie podstawowych informacji czy nie razenie w oczy kolorem jak Typy okretow. Dla kogos innego nie wazne jest to, zeby dany i-box podawal podstawowe informacje, wazne zas jest to zeby nie skladal sie z wiecej niz 3 wierszy - jak ustalic standard? --Matrek (dyskusja) 23:29, 9 cze 2008 (CEST)
- Interlinia z definicji i nawet z samej nazwy jest to coś pomiędzy liniami tekstu.
- No ;) Jesli linie sa w osobnych komorkach to miedzy nimi tez typograficznie jest interlinia, tylko "htmlowo" nie.
- Nie bez powodu standardowa (domyślna) interlinia jest taka jaka jest. W typografii jest miejsce na swobodę, ale wypracowane od wieków (sic!) standardy składu tekstów nie wzięły się znikąd tylko z ergonomii czytania. Nie tworzysz tekstu tylko po to by był i zajmował tyle a tyle miejsca tylko po to by dobrze się go czytało. Gdy jedna linia zlewa się z drugą czyta się źle. Ponadto pamiętaj, że oko, a właściwie mózg jest przyzwyczajone (za sprawą setek innych tekstów widzianych codziennie) do odstępów standardowych. Delimata (dyskusja) 15:32, 5 cze 2008 (CEST) (Ps. nie widzę nic złego w tym, że o infoboksach dyskutuje więcej osób niż je tworzy. Przecież liczy się końcowy odbiorca czyli szeroka masa ludzi która będzie to czytać. Delimata (dyskusja) 15:40, 5 cze 2008 (CEST))
- Ale te odstepy ktore proponowaliscie nie byly wlasnie "standardowymi wypracowanymi interliniami" - bo nie dosc ze kazda linia miala swoja wlasnie ta "standardowa i wypracowana interlinie (czy raczej wysokosc)" to jeszcze byly odstepy "miedzykomorkowe" co wlasnie psulo ta "standardowa i wypracowana". Wiekszosc parametrow w infoboxach jest jednowierszowa, wiec jeszcze raz powtorze - wysokosc linii moze sobie byc standardowa ale niech zniknie ta przepasc "miedzykomorkowa" a raczej "wewnatrzkomorkowaalepodinadliniowa". SPIKE KSIĄŻKA SKARG I ZAŻALEŃ 16:28, 5 cze 2008 (CEST) (Ps. Ja tez w tym zlego nic nie widze i nigdzie tak nie twierdzilem.)
- No jeśli tak to interpretujesz to ok, ale zwróć uwagę, że zmieniałeś jakby nie to o czym teraz mówisz, bo ruszałeś to co wpływa na zwykłą interlinię, która właśnie powinna być jak najmniej zmieniana. Niestety w infoboksie samolotowym jest wiele parametrów których opisy nie mieszą się w jednej linijce i to właśnie nadziubdzianie w nich razi w oczy. Poza tym w pewnym sensie jednak interlinia międzykomórkowa ("wewnatrzkomorkowaalepodinadliniowa") odrobinę (nie za dużo) większa od zwykłej powinna być, właśnie po to by czytelnik dostrzegł, że jest to inna komórka tabeli. Ogólnie jednak widzę, że powoli zbliżamy się do pewnego kompromisu. :) Delimata (dyskusja) 17:56, 5 cze 2008 (CEST)
- Ale te odstepy ktore proponowaliscie nie byly wlasnie "standardowymi wypracowanymi interliniami" - bo nie dosc ze kazda linia miala swoja wlasnie ta "standardowa i wypracowana interlinie (czy raczej wysokosc)" to jeszcze byly odstepy "miedzykomorkowe" co wlasnie psulo ta "standardowa i wypracowana". Wiekszosc parametrow w infoboxach jest jednowierszowa, wiec jeszcze raz powtorze - wysokosc linii moze sobie byc standardowa ale niech zniknie ta przepasc "miedzykomorkowa" a raczej "wewnatrzkomorkowaalepodinadliniowa". SPIKE KSIĄŻKA SKARG I ZAŻALEŃ 16:28, 5 cze 2008 (CEST) (Ps. Ja tez w tym zlego nic nie widze i nigdzie tak nie twierdzilem.)
- Ja tylko uprawiam czarnowidztwo, sam jestem za standaryzacja i jakimis odgornymi zaleceniami jak widze czesc infoboxow ;). Nakapowalem juz Militariom w dyskusji wiec albo beda marudzic teraz albo wcale, co mi pasuje bo nadyskutowalem sie w projekcie strasznie a niektorzy i tak sie upieraja zeby "nie zmieniac starego" i dlatego czesc infoboxow jest "nieustandaryzowana" tam. SPIKE KSIĄŻKA SKARG I ZAŻALEŃ 14:35, 5 cze 2008 (CEST)
- Spike, ja sobie nie zycze zmian "moich" i-boxow, zwalszcza pogrubiania mi linii, zmiany kolorow na jakies krzykliwe, itd :p --Matrek (dyskusja) 23:36, 9 cze 2008 (CEST)
- Btw. Moze tak line-height:120% byscie sie zgodzili ;) Na {{Samolot infobox}} zaproponowalem (skoro na nim mieszamy), w naglowku zostaje 150% (czyli norma). Zajrzyjcie tam. SPIKE KSIĄŻKA SKARG I ZAŻALEŃ 14:44, 5 cze 2008 (CEST)
- Jak dla mnie jest to akceptowalne. Delimata (dyskusja) 15:35, 5 cze 2008 (CEST)
- Przejdzie, ale w drodze wyjątku. Oprócz utrudnienia czytania nie widzę dużych różnic w długości. Yarl read.me 19:52, 5 cze 2008 (CEST)
- Byloby mniej utrudnione gdyby czcionka byla wieksza, nie interlinie wieksze. Ja widze ze tu naprawde chodzi o zwykle gusta. JESZCZE RAZ POWTORZE: "zniknijcie" odstep "srodkomorkowy"| to nie bedzie potrzeby manipulowania wysokoscia wersu. SPIKE KSIĄŻKA SKARG I ZAŻALEŃ 02:52, 6 cze 2008 (CEST) Ps. A jak nie widzisz roznic w dlugosci (ok 20%) to masz duzy problem :P SPIKE KSIĄŻKA SKARG I ZAŻALEŃ 03:00, 6 cze 2008 (CEST)
- Uspokój się i czytaj ze zrozumieniem. Kluczowe jest słowo "dużych". Nie ma różnic na tyle dużych które uzasadniałyby pogorszenie czytelności infoboksu. Delimata (dyskusja) 07:06, 6 cze 2008 (CEST)
- Byloby mniej utrudnione gdyby czcionka byla wieksza, nie interlinie wieksze. Ja widze ze tu naprawde chodzi o zwykle gusta. JESZCZE RAZ POWTORZE: "zniknijcie" odstep "srodkomorkowy"| to nie bedzie potrzeby manipulowania wysokoscia wersu. SPIKE KSIĄŻKA SKARG I ZAŻALEŃ 02:52, 6 cze 2008 (CEST) Ps. A jak nie widzisz roznic w dlugosci (ok 20%) to masz duzy problem :P SPIKE KSIĄŻKA SKARG I ZAŻALEŃ 03:00, 6 cze 2008 (CEST)
- Przyklad (nie wnikajac w detale CSSa bo pisze "na szybko"):
- IMO rozmiary tekstu najlepsze są w {{Pocisk rakietowy infobox}}. W samolotowym jest mała czcionka i wielka interlinia, w "czołgowym" lub tym od broni palnej jest rzeczywiśćie "nadziubdziane". A jak są za długie, to może coś by z infoboxu wywalić albo scalić kilka wierszy w jeden (np. z wymiarami tak można chyba zrobić)? Matma Rex aka matematyk 09:44, 4 cze 2008 (CEST)
Czy chcielibscie
i czy wam sie podoba
tekst napisany w ten sposob?
Bo tak wyglada teraz
mniejwiecej zawartosc infoboxu
jaka proponujecie.
A ja chcialbym zeby wygladala tak (mniejwiecej):
Czy chcielibscie
i czy wam sie podoba
tekst napisany w ten sposob?
Bo tak wyglada teraz
mniejwiecej zawartosc infoboxu
jaka proponujecie.
Bo albo ja mam sokole oczy i niechec do tla za to chec na informacje (na 4 przegladarkach) albo... SPIKE KSIĄŻKA SKARG I ZAŻALEŃ 02:59, 6 cze 2008 (CEST)
- Jeszcze raz powtórzę, że wszystko zależy czy mówimy o jednej komórce, gdzie rzeczywiście interlinia powinna być normalna czy o różnych komórkach które powinny być graficznie wyodrębnione. Delimata (dyskusja) 07:03, 6 cze 2008 (CEST) A tak poza tym to co jest obecnie jest niezłym kompromisem. Po co więc próbujesz go atakować? Delimata (dyskusja) 07:18, 6 cze 2008 (CEST)
- Spoko, narazie. 91.123.210.43 (dyskusja) 07:11, 6 cze 2008 (CEST)
ŹŻŹŻ! To mój przykład. Czy na pewno o takie coś chodzi?
- Ja uważam nie w ogóle nie jest potrzebna dyskusja nad interlinią. Czy taka interlinia ja tu jest zła? Karol007dyskusja 23:11, 8 cze 2008 (CEST)
- No właśnie. W końcu każdy może sobie zdefiniować własną interlinię w monobooku. EOT. Yarl ✉ 12:31, 21 sie 2008 (CEST)
- Ja uważam nie w ogóle nie jest potrzebna dyskusja nad interlinią. Czy taka interlinia ja tu jest zła? Karol007dyskusja 23:11, 8 cze 2008 (CEST)
Wygląd komórki projektów siostrzanych
edytujkopia z Dyskusja Wikiprojektu:Botanika#Po raz któryś commons
Rozbudowujemy infoboxy, dodajemy mapy, a zdjęcia wyrzucamy do commons. Tylko, że napis odwołujący się do commons napisany jest tak małymi literkami i tak niewyróżniającym sie od tabeli kolorem, że tylko bywalcy o nim wiedzą. Dla przeciętnego użytkownika jest bardzo trudno odróżnialny od tabeli, zlewa się z systematyką, szczególnie, gdy przywrócona została wersja Galeria zdjęć i grafik w Wikimedia Commons. Poprzednia wersja była lepsza, jeśli jednak musi być to Wikimedia Commons, to trzeba jakoś powiększyć czcionkę lub dać silniejszy kolor napisu, by link do commons nie zlewał się z systematyką w tabeli. Selso (dyskusja) 19:52, 18 paź 2008 (CEST)
W całej tej mądrej fachowców rozmowie nad szczegółami technicznymi zapomnieliście tylko o tym, że link do commons nie służy tylko wikipedystom. Przeciętny użytkownik z reguły nie znajduje go w rozbudowanym infoboxie, gdzie zlewa się on z tabelą, pisany jest drobną czcionką i tego samego koloru. Rozbudowane infoboxy zajmują miejsca dla grafiki, ta jest wyrzucana do commons – a to tak jakby jej nie było. Link do commons ma się rzucać w oczy! I jeszcze coś: ty wiesz co to znaczy Wikimedia Commons, bo tworzysz wikipedię, ale dla innych to pusty, nic nie znaczący frazes. Zredukowaniem do niemal nierozpoznawalnej postaci linku do commons zniweczyliście pracę wszystkich autorów grafiki – teraz zdjęć na commons tak jakby nie było. Zobaczcie, jak wyraźny jest link do commons na en:wiki Hieracium aurantiacum (no i nie jest na dokładkę utopiony w infoboksie !) Selso (dyskusja) 08:24, 19 paź 2008 (CEST)
- Zwróć uwagę, że dyskutowaliśmy tutaj przede wszystkim o nazwie parametru w infoboksie, a nie o tym jak to będzie prezentowane odbiorcy. Osoba edytująca artykuł i tak musi wiedzieć co to jest Commons, żeby móc wstawić linka. --Nux (dyskusja) 09:25, 19 paź 2008 (CEST)
- a ty znowu o osobie edytującej artykuł. Wikipedia istnieje przecież nie tylko dla wikipedystów, ale znacznie liczniejszej rzeszy ludzi poszukujących wiadomości, którzy wcale nie muszą wiedzieć co to jest WikmediaCommons, natomist link do commons musi być wyraźny, by mogli znaleźć zdjęcia. Jak na razie zepsuliście go. Selso (dyskusja) 12:42, 19 paź 2008 (CEST)
- Ale przecież kompletnie nikt tu nie twierdzi, że trzeba te linki chować. Rozmowa jest o nazwie parametru, a jeśli wygląd jest poruszany, to tylko zgodnie z Twoim punktem widzenia. Sam poprawiałem wygląd tego pola w paru infoboksach i ze wszech miar popieram, że trzeba to uwypuklić (chyba zdarzyło się też jakieś cofanie moich zmian). Ale Twoje pretensje są tutaj zupełnie nie na temat, a pisanie "zniweczyliście", "zepsuliście" to bezpodstawne zarzuty. Jeśli ktoś coś zniszczył, to pretensje trzeba kierować do niego, a nie do całej grupy ludzi, która usiłuje poprawić zupełnie inne rzeczy... ToSter→¿? 12:54, 19 paź 2008 (CEST)
- a ty znowu o osobie edytującej artykuł. Wikipedia istnieje przecież nie tylko dla wikipedystów, ale znacznie liczniejszej rzeszy ludzi poszukujących wiadomości, którzy wcale nie muszą wiedzieć co to jest WikmediaCommons, natomist link do commons musi być wyraźny, by mogli znaleźć zdjęcia. Jak na razie zepsuliście go. Selso (dyskusja) 12:42, 19 paź 2008 (CEST)
- Czy w takim razie zmiany wprowadzone w tym infoboxie Szablon:Roślina infobox są zgodnie z waszymi ustaleniami ? Bo przeciw nim protestuję; czcionka jest zbyt mała, a link do commons zbędny - ktoś z artykułów szukający zdjęć nie chce przecież trafić na stronę główną commons - takie wyprowadzenie w pole go tylko zniechęci. A jak otworzy galerię zdjęć (bo o to mu przecież chodzi) to i tak znajdzie się na commons i może otworzyć stronę główną commons. Link z Wikipedii powinien prowadzić wyłącznie do galerii zdjęć. Selso (dyskusja) 13:09, 19 paź 2008 (CEST)
- nie bardzo rozumiem dlaczego mamy wybitnie wyróżniać linki do commons, a nie np datę urodzenia czy linki do oficjalnej strony ? To tylko kwestia Twojego gustu i Twoich potrzeb. W infoboksie wszystkie informacje są na równi ważne. Poza tym nie zawsze link powinien prowadzić do galerii, bo - jak zostało to wcześniej zauważone - często kategorie zawierają znacznie więcej elementów. Ten wikiprojekt ma na celu ujednolicenie wszystkich infoboksów, bo niektóre są od sasa do lasa, jakbyśmy tworzyli kilka kolorowych blogasków a nie jedną spójną Wikipedię. - Beax 17:03, 19 paź 2008 (CEST)
- W żadnym wypadku wszystkie informacje w infoboxie nie są jednakowo ważne! Wszystkie informacje zawarte w infoboksie z reguły są zawarte również w tekście artykułu, infobox je tylko dubluje. Wszystkie z wyjątkiem linku do commons. To, czy link prowadzi do galerii, czy kategorii to sprawa czysto techniczna wikipedystów, zwykłego poszukiwacza informacji nic nie obchodząca. Błędne jest również tworzenie podwójnego linku: do galerii multimediów i do strony Wikipedii z artykułem o commons; to po prostu wyprowadzenie kogoś w pole - zamiast da galerii multimediów został skierowany do artykułu o commons (podwójne linki nie są przecież czymś codziennym w Internecie). Selso (dyskusja) 21:22, 19 paź 2008 (CEST)
- no i żeby jeszcze strony oficjalne, czyli komercyjne i konkurencyjne dla Wikipedii uważać za równie ważne, jak naszą siostrzaną WikimediaCommons, na której bazuje praktycznie cała grafika Wikipedii.... Selso (dyskusja) 21:53, 19 paź 2008 (CEST)
Link do tej strony wisi w ogłoszeniach już parę miesięcy, większość dyskusji cząstkowych jest zakończona jakimiś ustaleniami, a teraz czytam, że czcionka jest za mała. Skoro informacje w boksie dublują te z artykułu to po co większa czcionka? Poza tym takie dublowanie nie jest powszechne, np. na próżno szukać związku chemicznego, gdzie w tekście będzie podany numer RTECS, który jest w infoboksie:) Co do linku do Commons, i jego wyższości nad pozostałymi informacjami, to oczywiste wydaje mi się to że takowej wyższości nie ma, w ogóle nie można patrzeć tymi kategoriami, bo w odpowiednio licznej populacji generalnej wszystkie informacje będą wykorzystywane niemal z tą samą częstością. Zatem jeśli mówimy tutaj, że trzeba link bardziej wyeksponować, to jest jeden głos któremu najwyraźniej te linki są najbardziej potrzebne. Jeśli tak by było, to zaraz pojawiłyby się kolejne głosy, że trzeba wyeksponować gromadę, królestwo, rodzaj itd. Po n głosach doszlibyśmy do wniosku, że eksponujemy wszystko, a wtedy nie byłoby sensu, bo żadna informacja, by się nie wyróżniała i wtedy można by obniżyć stopień ekspozycji, osiągając tym samym ten sam efekt, czyli efekt wyjściowy. Karol007dyskusja 00:14, 20 paź 2008 (CEST)
- Do wielu artykułów istnieje bardzo bogata grafika na commons, dla której brak miejsca na stronie. Niestety, niektórzy usuwają na commons nawet tę istniejącą, z notatką, że tam jest miejsce dla grafiki. Link do commons jest jednak tak niepozorny, że wiedzą o nim wikipedyści, umyka uwagi jednak przeciętnemu użytkownikowi, gdyż jest utopiony w tabeli i małą czcionką.
Przynajmniej tak było do wczoraj - po moich ptotestach czcionka w infoboxie Szablon:Roślina infobox została przywrócona do tej samej wielkości, co pozostałe wiersze i tak już może być (przedtem była zmniejszona, a więc bynajmniej nie miała takiej samej wartośći, jak pozostałe wiersze). Ponieważ jednak niektórzy niedoceniają znaczenia grafiki uważam, że lepiej jest oddzielić linku do commons od infoboxu. W wielu przypadkach to co robicie to samowolka i narzucanie innym swojego zdania. Tak np. na wikiprojekcie:Botanika mamy ustalony infobox dużo większą liczba uczestników, niż bierze udział w tej tutaj standaryzacji - wy to zmieniacie, bo wydaje wam się, że macie patent na nieomylność i wszystko wiecie lepiej jak ma być. Selso (dyskusja) 08:00, 20 paź 2008 (CEST)
Ponadto link do galerii grafiki nie powinien być podwójny, jak obecnie - ktoś klikając na ten link chce przecież trafić do galerii grafiki, jeśli jednak kliknie z prawej strony, zostanie wyprowadzony w pole, trafi na artykuł o commons, co go tylko zniechęci. Podwójne linki nie są czyś standardowym w internecie.
- Ehh... Proszę wybacz, ale nie jesteś chyba na bieżąco, ta dyskusja była wielokrotnie ogłaszana na tablicy ogłoszeń, listach, no i cały czas wisi w ogłoszeniach lokalnych, zatem jeśli jest tutaj nas garstka, to widocznie dlatego, że reszcie podoba się ta standaryzacja lub jest to im obojętne skoro się tutaj nie wypowiadają. A teraz proszę o powrót do merytorycznej dyskusji, a nie podgrzewanie atmosfery bezpodstawnymi oskarżeniami. Tym samym kończę niemerytoryczną część tej dyskusji. Karol007dyskusja 15:09, 20 paź 2008 (CEST)
{{{Nazwa zwyczajowa}}} | |
Systematyka | |
Domena | |
---|---|
Królestwo | |
Systematyka w Wikispecies | |
Galeria zdjęć w Wikimedia Commons |
Pomysł z unikaniem podwójnych łącz i niepomniejszaniem czcionki wydaje mi się rozsądny. Sam często się mylę. (To samo dotyczy opisu grafiki: "Plik Wikispecies-logo.svg [ edytuj opis ] umieszczony jest w Wikimedia Commons, repozytorium wolnych zasobów projektów Fundacji Wikimedia. Wyjaśnienie podanej poniżej licencji znajdziesz na stronie Opisy licencji grafiki. ") Proponuję taki schemat dla infoboksów biologicznych: BartekChom (dyskusja) 20:57, 21 paź 2008 (CEST)
Inne kwestie
edytujPropozycje nowych rozwiązań
edytuj- Przydałoby się stwożyć domyślne ukrywanie parametrów infoboxu, tak jak to jest w en wiki tutaj: en:Template:GNF Protein box (en:Reelin - w praktyce), dodatkowo do tego może dałoby się zrobić ukrywanie wybranych parametrów w obrębie jednego nagłówka? To pozwoliłoby skrócić długie infoboxy, pokazując na pierwszy rzut informacje niezbędne a w po rozwinięciu informacje dodatkowe. Najlepiej by było, gdyby to zrobić w postaci uniwersalnego szablonu działającego podobnie jak Szablon:Infobox nagłówek dodaj (gdzie podawane warunki (parametry) byłyby ukrywane a nie podane byłyby widoczne zawsze) i Szablon:Infobox nagłówek dodaj. Można tez rozszerzyć ich funkcjonowanie. Karol007dyskusja 20:46, 21 kwi 2008 (CEST)
- Pokombinuję. Powinno się dać to zrobić na aktualnych skryptach wykorzystywanych przez {{uniwersalny szablon nawigacyjny}}. Matma Rex aka matematyk 21:24, 21 kwi 2008 (CEST)
- Wikipedysta:Matma Rex/brudnopis2#inf ukrywany - technicznie da się zrobić. Matma Rex aka matematyk 17:19, 22 kwi 2008 (CEST)
- Też w tym grzebałem i nie udało mi się usunąć marginesów z boków, góry i dołu. Pośrednim rozwiązaniem są ujemne marginesy, ale nie da się ich zastosować w dwie strony. Szukałem też w MediaWiki:Common.css i MediaWiki:Monobook.css i nie ma tam nic takiego, czego nie można byłoby zdefiniować z poziomu infoboksu. Może divy i tabelki są ze sobą niekompatybilne? Yarl read.me 18:36, 22 kwi 2008 (CEST)
- Dobra, mam: jest to związane z
cellpadding="4
, ale nie mam pomysłu jak to obejść. Yarl read.me 19:03, 22 kwi 2008 (CEST)- Zmienić globalne html:cellpadding w tabeli na lokalne css:padding w komórkach wierszy. ABX - (O mnie dyskutuj) 19:53, 22 kwi 2008 (CEST)
- Wikipedysta:Matma Rex/brudnopis2#inf ukrywany - technicznie da się zrobić. Matma Rex aka matematyk 17:19, 22 kwi 2008 (CEST)
Wywaliłem cellpadding i wyczaiłem lepszy sposób: collapsible tables. Wymaga wstawienia 3 divów mniej - samo dobro. Można też domyślnie ukryć wiersz. Matma Rex aka matematyk 22:07, 22 kwi 2008 (CEST)
- Myślę, że dobrze by było stworzyć jakąś domyślną klasę CSS dla boksów tak, żeby wystarczyło tylko ją wpisać, żeby mieć domyślne ustawienia (szerokość, czcionka, kolory itp), które wypracujemy. --Nux (dyskusja) 07:23, 28 kwi 2008 (CEST)
- Nie znam się na tym, mam tylko ogólne wiadomości na ten temat, ale wydaje mi się, że będzie to dobre rozwiązanie. Karol007dyskusja 12:13, 28 kwi 2008 (CEST)
- W tej chwili mamy określona minimalną szerokość infoboxu, ale nie ma maksymalnej. W rezultacie przy długich wpisach infobox rozpycha artykuł. Da się to zablokować, tak żeby ustalona szerokość była jedyna możliwą? Przykład. Przy okazji to dodatkowy argument do niewielkiego zwiększenia szerokości infoboxu. Karol007dyskusja 12:41, 28 kwi 2008 (CEST)
- Może zrobiłby szablon, który zamiast dwóch kolumn wstawiałby jedną, w niektórych przypadkach nie jest potrzeba kolumna z nazwą parametru lub można ją zastąpić nagłówkiem. Na en wiki tak jest zrobione ale nie szablonem en:Aspirin i chciałbym to u nas zrobić, a robiąc porządek w kodzie za pomocą AWB to w jednej edycji ręcznie bym wszystkie długie, wielolinijkowe parametry dostosowywał, chyba że da się automatyczne łamanie linii zrobić?. Karol007dyskusja 12:41, 28 kwi 2008 (CEST)
- Można zrobić komórki "przesuwane", zachowanie podobne jak w {{szablon nawigacyjny - przesuwany}} - nie powinno to być trudne. Matma Rex aka matematyk 15:36, 28 kwi 2008 (CEST)
- Ta-daaa! Tam, gdzie szerokość może być za mała, w komórkach znajduje się dodatkowy div z
style="overflow:auto"
. Matma Rex aka matematyk 16:13, 28 kwi 2008 (CEST)- W FF3 nie działa przez ten "white-space:nowrap". Nie widzę zresztą powodu, żeby wymuszać brak zawijania w każdym wypadku. Moim zdaniem jednak lepiej wygląda jeśli jest zawinięte niż jeśli miałby być taki scroll. --Nux (dyskusja) 22:58, 28 kwi 2008 (CEST)
- Pomysł dobry ale marny:-) Na razie widzę tylko jedno zastosowanie tego, do SMILES w infoboxie chemicznym, tam to się naprawdę przyda, bo kopiując kod do czytników tego kodu, wkleja się wyłącznie pierwsza linia, zatem przy kodach długich na 4-5 linijki, każdą trzeba kopiować osobno. Jednocześnie nie ma potrzeby aby całość kodu była widoczna w każdej chwili. Można się ewentualnie zastanowić czy nazwy systematyczne też by można w to włożyć, ale zapytam w projekcie jakby to widzieli:-) Karol007dyskusja 16:29, 29 kwi 2008 (CEST)
- W FF3 nie działa przez ten "white-space:nowrap". Nie widzę zresztą powodu, żeby wymuszać brak zawijania w każdym wypadku. Moim zdaniem jednak lepiej wygląda jeśli jest zawinięte niż jeśli miałby być taki scroll. --Nux (dyskusja) 22:58, 28 kwi 2008 (CEST)
- Ta-daaa! Tam, gdzie szerokość może być za mała, w komórkach znajduje się dodatkowy div z
- Można zrobić komórki "przesuwane", zachowanie podobne jak w {{szablon nawigacyjny - przesuwany}} - nie powinno to być trudne. Matma Rex aka matematyk 15:36, 28 kwi 2008 (CEST)
{{Infobox wiersz}} i {{Infobox nagłówek}}
edytujCzy szablon {{Infobox wiersz}} nie powinien wstawiać komórki nagłówkowej i zwykłej (a nie dwie zwykłe)? Czy {{Infobox nagłówek}} nie powinien wstawiać nagłówkowej (zamiast zwykłej)? BO moim zdaniem powinny. Matma Rex aka matematyk 11:34, 27 kwi 2008 (CEST)
- A moim zdaniem nie. Szablony te są używane wewnątrz infoboksów, do wierszy zawierających parametry. Ponieważ są one używane przez {{Infobox wiersz dodaj}} i {{Infobox nagłówek dodaj}}. Nie są używane do nagłówków. A_Bach - ΣΦ 21:45, 27 kwi 2008 (CEST)
- Dodatkowe tłumaczenie - infobox wiersz dodaj wstawia dwie komórki, z czego jedną ciemniejszą. Gdyby była dodatkowo pogrubiona - było by to podwójne wyróżnienie. A to jest niewskazane. A_Bach - ΣΦ 10:07, 28 kwi 2008 (CEST)
- Ale w np. {{Książka infobox}} w każdym wierszu pierwsza komórka jest nagłówkowa, i IMO tak powinno właśnie być - w kocu to są nagłówki. Może jakiś dodatkowy, opcjonalny parametr? Matma Rex aka matematyk 11:03, 28 kwi 2008 (CEST)
- Moim zdaniem takie pogrubienie w infoboksie to zuo i powinno być usuwane. Pogrubione powinny być nagłówek górny i środkowe (jeśli są). Yarl read.me 14:34, 28 kwi 2008 (CEST)
- Ale przecież jedno drugiemu nie przeszkadza - mogą być komórki nagłówekowe, co strukturalnie będzie poprawne, a jednocześnie odbpowiednia klasa może wymusić, żeby były odpowiednio wyrównane i bez pogrubienia. --Nux (dyskusja) 22:58, 28 kwi 2008 (CEST)
- Właśnie o tym myślałem. Matma Rex aka matematyk 12:20, 29 kwi 2008 (CEST)
- O ile z {{Infobox nagłówek}} nie ma sprawy, o tyle dodawanie klasy do każdego {{Infobox wiersz}} trochę mija się z celem. Przecież nie po to standaryzujemy, żeby rozwlekać kod. Yarl read.me 16:03, 29 kwi 2008 (CEST)
- Właśnie o tym myślałem. Matma Rex aka matematyk 12:20, 29 kwi 2008 (CEST)
- Ale przecież jedno drugiemu nie przeszkadza - mogą być komórki nagłówekowe, co strukturalnie będzie poprawne, a jednocześnie odbpowiednia klasa może wymusić, żeby były odpowiednio wyrównane i bez pogrubienia. --Nux (dyskusja) 22:58, 28 kwi 2008 (CEST)
- Moim zdaniem takie pogrubienie w infoboksie to zuo i powinno być usuwane. Pogrubione powinny być nagłówek górny i środkowe (jeśli są). Yarl read.me 14:34, 28 kwi 2008 (CEST)
- Ale w np. {{Książka infobox}} w każdym wierszu pierwsza komórka jest nagłówkowa, i IMO tak powinno właśnie być - w kocu to są nagłówki. Może jakiś dodatkowy, opcjonalny parametr? Matma Rex aka matematyk 11:03, 28 kwi 2008 (CEST)
- Dodatkowe tłumaczenie - infobox wiersz dodaj wstawia dwie komórki, z czego jedną ciemniejszą. Gdyby była dodatkowo pogrubiona - było by to podwójne wyróżnienie. A to jest niewskazane. A_Bach - ΣΦ 10:07, 28 kwi 2008 (CEST)
- Infobox wiersz w tej chwili umożliwia ustawienie maksymalnej szerokości lewej kolumny. trzeba coś wymyslić żeby można było to naczej rozwiazać a nie w ten sposób jak tutaj. Karol007dyskusja 17:32, 8 maj 2008 (CEST)
Problem techniczny
edytujPrzy okazji głosowań nad medalem dla pewnego odkryłem problem techniczny. W Firefoksie 3 jeżeli umieścimy zdjęcie z lewej strony i z prawej, tak że to z prawej przesunie infoboks, to to z lewej też pojawi się dopiero po infoboksie i do tego będzie zahaczać o tekst, tak jak tu. Czy to błąd w Firefoksie, czy kod naprawdę każe robić przeglądarce takie coś? Pod IE nie ma problemów. BartekChom (dyskusja) 22:12, 19 wrz 2008 (CEST)
- Przeanalizowałem sprawę. Problem pojawia się przy klasach floatleft i floatright: [2]. Na razie znalazłem je tylko na http://pl.wiki.x.io/skins-1.5/monobook/main.css . To chyba zadanie dla deweloperów. BartekChom (dyskusja) 15:01, 19 paź 2008 (CEST)
Ogólny design
edytujZakładam jeszcze tą jedną sekcję rozpoczynając pytaniem jaki ogólny design zastosujemy (jeśli gdzieś powyżej było o tym wspomniane to z automatu ten wątek się kończy, z moimi przeprosinami. Do tej pory znalazłem kilka możliwości (wyłączając przypadki, w których są drobne różnice):
- {{Związek chemiczny infobox}}
- Ładny, często uzywany, bez cellspacingu
- {{Animanga infobox}}
- Ładny, często uzywany, z cellspacingiem
- Wygląd "na en.wiki"
- {{Szablon:Okręt infobox}}
- Brzydki, bez cellspacingu, paddingu, ciemne
- {{Polski oficer marynarki infobox}}
- Brzydki, gruby border
- {{Szablon:Fortyfikacje Infobox}}
- Brzydki, bez paddingu. Matma Rex aka matematyk 22:09, 31 sie 2008 (CEST)
jesli macie więcej różności to uzupełnijcie powyższą listę. Pozdrawiam Karol007dyskusja 16:47, 31 sie 2008 (CEST)
- IMO najlepszy #1 lub #2. Matma Rex aka matematyk 22:09, 31 sie 2008 (CEST)
- IMO też, i skłaniałbym się za #1 - wydaje się on być bardziej zakorzeniony w pl.wiki. Yarl ✉ 12:34, 1 wrz 2008 (CEST)
- #1 ABX - (O mnie dyskutuj) 12:44, 1 wrz 2008 (CEST)
- Ja również myślę o 1 lub 2. Drugi ma jednak jedną zaletę, której nie ma ten pierwszy, bardziej zresztą przeze mnie lubiany:-) żeby było ciekawiej (sorki za POV). Zobaczcie tutaj: woda, sekcje zwijane mają różnej szerokości kolumny, zachowują się niezależnie, bo są osobnymi tabelami. Psuje to trochę ogólny wygląd, ale poza tym nie mam nic. W drugim typie co prawda nie natrafiłem na podobny przypadek (tylko jedna, jednokolumnowa zwijana sekcja) ale być może to też tam występuje. Karol007dyskusja 00:51, 2 wrz 2008 (CEST)
- Wystarczy ustalić na sztywno szerokość komórek w pierwszym weirszu podtabeli chyba. Matma Rex aka matematyk 15:06, 2 wrz 2008 (CEST)
- No, nie wiem, bo tabela główna ma szerokość zmienną, zależną od najszerszego wpisu po lewej stronie i podtabela musiałaby się jakoś kontaktować z tabelą główną, żeby mogła się do niej wyrównać. Karol007dyskusja 20:46, 11 wrz 2008 (CEST)
- Wystarczy ustalić na sztywno szerokość komórek w pierwszym weirszu podtabeli chyba. Matma Rex aka matematyk 15:06, 2 wrz 2008 (CEST)
- Ja również myślę o 1 lub 2. Drugi ma jednak jedną zaletę, której nie ma ten pierwszy, bardziej zresztą przeze mnie lubiany:-) żeby było ciekawiej (sorki za POV). Zobaczcie tutaj: woda, sekcje zwijane mają różnej szerokości kolumny, zachowują się niezależnie, bo są osobnymi tabelami. Psuje to trochę ogólny wygląd, ale poza tym nie mam nic. W drugim typie co prawda nie natrafiłem na podobny przypadek (tylko jedna, jednokolumnowa zwijana sekcja) ale być może to też tam występuje. Karol007dyskusja 00:51, 2 wrz 2008 (CEST)
- #1 ABX - (O mnie dyskutuj) 12:44, 1 wrz 2008 (CEST)
- IMO też, i skłaniałbym się za #1 - wydaje się on być bardziej zakorzeniony w pl.wiki. Yarl ✉ 12:34, 1 wrz 2008 (CEST)
- Ocene, ktory jest ladny sobie darujmy, bo dla mnie ladny jest ten - ze znacznym ograniczeniem pol kolorowanych i zastapieniem ich liniami, a nie ten który podoba sie tobie --Matrek (dyskusja) 20:53, 19 wrz 2008 (CEST)
- Dla mnie najlepszy jest pierwszy, ale problem techniczny trzeba rozwiązać. Jak ktoś się na tym zna, to nie powinno być kłopotem przygotowanie skryptu, który po prostu ukrywa kilku wierszy na raz. Może trochę trudniej będzie tworzyć infoboksy, ale czytelnik nie będzie miał do czynienia z poprzesuwanymi granicami barw i szczelinami. BartekChom (dyskusja) 22:05, 19 wrz 2008 (CEST)
Wybór designu dla infoboksów w projekcie, zawsze będzie obarczony jakąś tam nieobiektywną oceną, ale trzeba na chwilę zapomnieć o przyzwyczajeniach i własnych uczuciach estetycznych i obrać jeden kierunek na jednej drodze. #1 jest najbardziej rozpowszechniona wśród infoboksów (choć to nie jest poważny argument, to jednak jakiś jest). Poza tym jest całkiem czytelna.
Jest jeszcze jedno rozwiązanie problemu z kolumnami. Niezależnie od zawartości prawej kolumny, ustawić na sztywno, w obu infoboksach maksymalną szerokość kolumny. Wtedy komunikacja między infoboksami nie będzie potrzebna. Zatem Matma Rex rację miał w połowie:) Czy ktoś biegły w sprawach technicznych mógłby to sprawdzić? Karol007dyskusja 23:24, 19 wrz 2008 (CEST)
"sekcje zwijane mają różnej szerokości kolumny, zachowują się niezależnie, bo są osobnymi tabelami" - chyba mam rozwiązanie tego problemu. Można zrobić tak, żeby znikały poszczególne wiersze, a nie cała tabelka. Aby przetestować, wystarczy dodać importScript('Wikipedysta:BartekChom/pokazUkryj.js') do swojego monobooka i sprawdzić działanie na przykładowej stronie: Wikipedysta:BartekChom/brudnopis6. Po dopracowaniu szczegółów powinno działać dokładnie jak stara metoda z wyjątkiem wspomnianego problemu. BartekChom (dyskusja) 21:26, 2 sty 2009 (CET)
Dane zmienne
edytujProponuje ustalenie jednolitych zasad dotyczacych danych zmiennych w czasie. Do tej pory bowiem, panuje w tym wzgledzie rozgardiasz. Przykladowo: Infobkos przedsiebiorstwo zawiera pola dotyczace zysku netto, czy tez prezesów, z drugiej strony - infoboks Okręt rozszerzony nie zawiera pola "port macierzysty", gdyz jak uslyszalem - ów "moze sie zmieniać". W obydwu przypadkach uslyszalem rozne odpowiedzi na pytanie o te pola. W przypadku infoboksu przedsiebirstwa odpowiedz brzmiala - "przeciez zawsze mozna zmienic informacje w i-boksie", w przypadku okretów zas, argumentachja byla przeciwna - "nie ma portu macierzystego, bo bazy macierzyste okretow moga sie zmienac". Tymczasem, prezesi i wynik finansowy zmieniaja sie, lub moga zmieniac sie kilka razy w roku, bazy macierzyste okretów zaś zmieniaja sie dobrze jesli raz w cyklu zycia jednostki, o ile w ogole. --Matrek (dyskusja) 13:21, 16 paź 2008 (CEST)
- Myślę, że każdy przypadek lepiej rozpatrywać osobno w wikiprojektach - można takie pola narzucić a nikt ich nie będzie odświeżał. Yarl ✉ 17:23, 16 paź 2008 (CEST)
- Osobiscie sadze ze nawet mozna dopuscic pola z danymi ktore moga zmienc sie w czasie, lecz nie taki ktore na pewno zmianiaja sie co kilka misiecy. W podanych przykladach, okret zmieni port macierzysty raz-dwa razy w ciagu swojej sluzby (20 - 30 lat), albo wcale, natomiast to ze wynik finansowy zmieni sie co najmniej raz na rok, jest pewne. Dane z taka czestotliwoscia sie zmieniajace, na peweno nie powinny zostac dopuszczone, bo uaktualnic je mozna w kilku przedsiebiorstwach, natomiast nie w setkach, tysiacach, czy ile ich tam mamy na pl:wiki. --Matrek (dyskusja) 22:33, 16 paź 2008 (CEST)
Podsumowanie wszystkich podsumowań
edytujDyskusja trwa od kwietnia, wszystko zostało właściwie przedyskutowane. Trzeba to wszystko teraz wprowadzić w życie - jak to robimy? ToSter→¿? 23:54, 28 wrz 2008 (CEST)
- Na początek proponuję przejść wszystkie infoboksy i pozmieniać w nich to, co nie wymaga zmian wywołania. Potem zaś ponownie jedziemy po kolei i zmieniamy wywołania, poprawiając botem. Możnaby zrobić jakąś podstronę w stylu Wikiprojekt:Infoboksy/uczłowieczanie instrukcji infoboksów dla koordynacji działań, żeby nie wyszło, że dwie osoby jednocześnie poprawiają dany infoboks. Matma Rex aka matematyk 15:03, 29 wrz 2008 (CEST)
- Nie robiłbym raczej wszystkiego tak na hurra. Część dyskusji została zamknięta mimo, że de facto nie osiągnięto konsensusu (czasem było bardzo blisko 50/50) i moim zdaniem w takich wypadkach powinno się odbyć szersze głosowanie. --Nux (dyskusja) 19:29, 29 wrz 2008 (CEST)
- To może zorganizujemy głosowanie dotyczące wszystkich kwestii? Chociaż z drugiej strony moglibyśmy wtedy wrócić do punktu wyjścia:) Co robimy? Karol007dyskusja 21:12, 29 wrz 2008 (CEST)
- Nie chodzi przecież o rozpoczęcie całej dyskusji od początku, w wielu kwestiach osiągnięto konsensus. Jednak jeśli wypowiada się 10 osób, z czego 6 jest za, a 4 przeciw, to trudno tu mówić o stabilnej decyzji i potem może się okazać, że będziemy znowu zmieniać w drugą stronę. --Nux (dyskusja) 09:20, 30 wrz 2008 (CEST)
- Nie, to IMO nie ma sensu, dyskusja o standardach infoboksów jest już ponad 5 miesięcy w obserwowanych, trzykrotnie (lub więcej) była anonsowana na tablicy ogłoszeń, były do niej linki podawane kiedy ktoś pytał o infoboksy - jeśli ktoś z aktywnych uczestników był zainteresowany to tu już trafił, każdy następny głos będzie głosem osoby, hmmm, artykułowanym na siłę. To po prostu trzeba zacząć wdrażać. A stosunek 6 za i 4 przeciw to stosunek zdaje się wystarczający do skasowania artykułu a my tu de facto rozmawiamy nie o kasowaniu a o zmianach kosmetycznych, więc dużo lżejszy kaliber. Reasumując byłbym za uznaniem i zamknięciem tej dyskusji. ABX - (O mnie dyskutuj) 11:06, 30 wrz 2008 (CEST)
- Przeciwnie, kaliber duzo ciezszy, bo rozmowa jest o szablonach do stosowania przez wszystkich. Tymczasem, osobiscie jestem zaiinteresowany infoboksami bo czesto z nimi pracuje, natomiast z tej dyskusji nie dowiedzialem sie praktycznie niczego. Oprocz wiedzy o istnieuniu ronzych pogladow. Nie mam czasu i nie chce mi sie czytac calej dyskusji, zwlaszcza polemik, z tego tez wzgledu nie uczestniczylem jej. Chcetnie natomiast dowiedzialbym sie nad czym mam ewentualnie glosowac, vo w takiej formie jak jest, to oprocz aktywnie uczestniczacych w tej dyskusji, nikt nie wie nad czym wlasciwie i konkretnie jest to glosowanie.--Matrek (dyskusja) 12:29, 30 wrz 2008 (CEST)
- No tak, ale jeśli kaliber jest cięższy to powinno się po 5 miesiącach roić od wypowiedzi ;) W zasadzie to nie ma w tej chwili głosowania :-) Chodzi o podsumowanie dyskusji - niepodsumowane są te sekce, które nie są na niebiesko - w jednej z nich jest jedynie minigłosowanie na temat czy ma być więcej spacji czy mniej i gdzie. ABX - (O mnie dyskutuj) 12:40, 30 wrz 2008 (CEST)
- Ale racją jest, że użytkownicy chętniej biorą udział w głosowaniach niż w dyskusjach. W dyskusji trzeba jakoś uzasadnić poglądy, powiedzieć coś nowego, w głosowaniu wystarczy wpisać #~~~~, "bo tak mi się podoba". Matma Rex aka matematyk 15:57, 30 wrz 2008 (CEST)
- Prosilbym jednak o nie lekcewazenie uzytkownikow, bo to ze nie kazdy ma ochote brac udzial w pyskowkach niekiedy, nie jest niczyja wina, a poza tym - z calym szacunkiem, nie kazdy ma czas i ochote produkowac sie, p to aby pozniej i tak decydowalo glosowanie w ktorym udzial biora ludzie ktorzy czesto-gesto nie maja merytorcznei pojecia o temacie.--Matrek (dyskusja) 18:17, 30 wrz 2008 (CEST)
- Ależ bynajmniej nie chodzi mi o lekceważenie, po prostu w miniony weekend wprowadziłem 40 aktywnych uczestników GDJ w stan prac nad infoboksami i generalnie (Yarl i Karol007 byli na sali) wydaje mi się że było ogólne przyzwolenie na standaryzację. 40 użytkowników to dość duży odsetek a w spotkaniu uczestniczyli Ci aktywniejsi edycyjnie. Stąd też sugestia by zmierzać ku końcowi. Jeśli jednak są zastrzeżenia to śmiało je artykułuj, nic na siłę :) Jeśli potrzebujesz się odnieść do którejś sekcji z powyższych, śmiało dopisuj uwagi. Mi tylko chodziło o to żeby za długo na nie nie czekać. Te ustalenia powinny były być zrobione już dawno temu. ABX - (O mnie dyskutuj) 20:17, 30 wrz 2008 (CEST)
- Prosilbym jednak o nie lekcewazenie uzytkownikow, bo to ze nie kazdy ma ochote brac udzial w pyskowkach niekiedy, nie jest niczyja wina, a poza tym - z calym szacunkiem, nie kazdy ma czas i ochote produkowac sie, p to aby pozniej i tak decydowalo glosowanie w ktorym udzial biora ludzie ktorzy czesto-gesto nie maja merytorcznei pojecia o temacie.--Matrek (dyskusja) 18:17, 30 wrz 2008 (CEST)
- Ale racją jest, że użytkownicy chętniej biorą udział w głosowaniach niż w dyskusjach. W dyskusji trzeba jakoś uzasadnić poglądy, powiedzieć coś nowego, w głosowaniu wystarczy wpisać #~~~~, "bo tak mi się podoba". Matma Rex aka matematyk 15:57, 30 wrz 2008 (CEST)
- No tak, ale jeśli kaliber jest cięższy to powinno się po 5 miesiącach roić od wypowiedzi ;) W zasadzie to nie ma w tej chwili głosowania :-) Chodzi o podsumowanie dyskusji - niepodsumowane są te sekce, które nie są na niebiesko - w jednej z nich jest jedynie minigłosowanie na temat czy ma być więcej spacji czy mniej i gdzie. ABX - (O mnie dyskutuj) 12:40, 30 wrz 2008 (CEST)
- Przeciwnie, kaliber duzo ciezszy, bo rozmowa jest o szablonach do stosowania przez wszystkich. Tymczasem, osobiscie jestem zaiinteresowany infoboksami bo czesto z nimi pracuje, natomiast z tej dyskusji nie dowiedzialem sie praktycznie niczego. Oprocz wiedzy o istnieuniu ronzych pogladow. Nie mam czasu i nie chce mi sie czytac calej dyskusji, zwlaszcza polemik, z tego tez wzgledu nie uczestniczylem jej. Chcetnie natomiast dowiedzialbym sie nad czym mam ewentualnie glosowac, vo w takiej formie jak jest, to oprocz aktywnie uczestniczacych w tej dyskusji, nikt nie wie nad czym wlasciwie i konkretnie jest to glosowanie.--Matrek (dyskusja) 12:29, 30 wrz 2008 (CEST)
- Nie, to IMO nie ma sensu, dyskusja o standardach infoboksów jest już ponad 5 miesięcy w obserwowanych, trzykrotnie (lub więcej) była anonsowana na tablicy ogłoszeń, były do niej linki podawane kiedy ktoś pytał o infoboksy - jeśli ktoś z aktywnych uczestników był zainteresowany to tu już trafił, każdy następny głos będzie głosem osoby, hmmm, artykułowanym na siłę. To po prostu trzeba zacząć wdrażać. A stosunek 6 za i 4 przeciw to stosunek zdaje się wystarczający do skasowania artykułu a my tu de facto rozmawiamy nie o kasowaniu a o zmianach kosmetycznych, więc dużo lżejszy kaliber. Reasumując byłbym za uznaniem i zamknięciem tej dyskusji. ABX - (O mnie dyskutuj) 11:06, 30 wrz 2008 (CEST)
- Nie chodzi przecież o rozpoczęcie całej dyskusji od początku, w wielu kwestiach osiągnięto konsensus. Jednak jeśli wypowiada się 10 osób, z czego 6 jest za, a 4 przeciw, to trudno tu mówić o stabilnej decyzji i potem może się okazać, że będziemy znowu zmieniać w drugą stronę. --Nux (dyskusja) 09:20, 30 wrz 2008 (CEST)
- To może zorganizujemy głosowanie dotyczące wszystkich kwestii? Chociaż z drugiej strony moglibyśmy wtedy wrócić do punktu wyjścia:) Co robimy? Karol007dyskusja 21:12, 29 wrz 2008 (CEST)
- Nie robiłbym raczej wszystkiego tak na hurra. Część dyskusji została zamknięta mimo, że de facto nie osiągnięto konsensusu (czasem było bardzo blisko 50/50) i moim zdaniem w takich wypadkach powinno się odbyć szersze głosowanie. --Nux (dyskusja) 19:29, 29 wrz 2008 (CEST)
- Po raz kolejny powtórzę - nie chodzi o to, żeby zrobić sobie głosowanie, bo głosowania są fajne. Tylko dlatego, że nie osiągnęliśmy konsensusu, a dyskusja się wyczerpała (wszystkie argumenty padły tudzież dyskutanci odpadli). Weźmy drastyczny przykład - koordynaty: opcja 2: Nux, ABX, opcja 1: Yarl, ToSter (jako podsumowujący, nie brał udziału w dyskusji). Podsumowanie: opcja1, a dyskusja w połowie i tak dotyczy innego tematu i nie wygląda wcale na zakończoną. Żeby nie było, że jestem stronniczy weźmy wstawianie grafik (tam akurat zgadzam się z opcją, która jest w podsumowaniu) - padło tam mnóstwo różnych propozycji i jakoś nie zauważyłem, skąd wyłoniła się ta ostatnia, bo nie pojawiły się praktycznie głosy za czymś konkretnym. --Nux (dyskusja) 19:34, 30 wrz 2008 (CEST)
- To ja powiem cos konkretnego nt grafik - nie powinny do infoboksu byc wstawiane opisy grafik - to grafika ilustruje przedmiot infoboksu. Opisy zas zaklocaja schemat i-boxu, a opisem grafiki jest caly infoboks. Nie rozwodze sie juz nad tym, iz najczesciej opisy grafik w i-boxach wygladaja w infoboksach po prostu brzydko --Matrek (dyskusja) 20:11, 30 wrz 2008 (CEST)
- Podpisy są potrzebne, w botanice, zoologii gdy artykuł opisuje całą rodzinę, a zdjęcie pokazuje przedstawiciela jednego tylko gatunku, to trzeba zdjęcie podpisać tym gatunkiem, w chemii, związek chemiczny może być na ilustracji w różnych stanach skupienia, jest wiele przypadków kiedy podpis być musi, można go po prostu nie używać, ale nie można zabronić jego istnieniu. ABX - (O mnie dyskutuj) 20:25, 30 wrz 2008 (CEST)
- Oj przepraszam, teraz jeszcze raz przeczytałem te koordynaty i stwierdzam, że więcej nie będę się bawił w podsumowanie, bo mi to nie wychodzi :) Jakoś mi się wydawało po prostu, że jest więcej głosów za 1, pewnie wpłynęło na to to, że tylko z nią się zetknąłem podczas edycji. To ja cofam to, co namieszałem w tej dziedzinie - sam leciutko się skłaniam ku 2. ToSter→¿? 20:01, 30 wrz 2008 (CEST)
- To ja powiem cos konkretnego nt grafik - nie powinny do infoboksu byc wstawiane opisy grafik - to grafika ilustruje przedmiot infoboksu. Opisy zas zaklocaja schemat i-boxu, a opisem grafiki jest caly infoboks. Nie rozwodze sie juz nad tym, iz najczesciej opisy grafik w i-boxach wygladaja w infoboksach po prostu brzydko --Matrek (dyskusja) 20:11, 30 wrz 2008 (CEST)
- hmmm... skoro mówimy o normalizacji to uważam, ze powinna powstać nowa-oddzielna-strona, która opisze wszystkie ustalenia na zasadzie "standardu" i mini instrukcji jednocześnie, tak żeby za pół roku nie tłumaczyć nowemu użytkownikowi, dlaczego jego nowo stworzony infoboks nie spełnia naszych wymogów. Ten wikiprojekt jest chyba najlepszym jaki widziałam, ale nic nie trwa wiecznie... Dlatego mówię o zachowaniu ustaleń w formie rozporządzenia :-) Co do konsensusu to jego brak chyba głównie rozbija się o te spacje ? Czyż nie tak ? Może w takim razie rzucić monetą, ustalić wynik i przyjąć zasadę ? - Beax 21:58, 30 wrz 2008 (CEST)
- Jeśli się nie mylę, to najbardziej wyrównane są spacje, grafiki i wiele parametrów w jednym wierszu, bo koordynaty jak widzę są już ponownie otworzone. W zasadzie jakby się czepiać, to nawet tam gdzie osiągnięto konsensus w ramach naszego projektu, to ktoś mógłby się potem przyczepić. Większość z nas jest obeznana w technikaliach wiki i możemy być nieobiektywni. Dotyczy to wszystkich łącznie ze mną, bo łatwiej mi będzie napisać skrypt do sprzątania infoboksów, jeśli wszystkie parametry będą w osobny wierszu. Problem w tym, że osoby nie-techniczne będą musiały się dostosować do naszych ustaleń jeśli zaczniemy botować w danym kierunku. Nie mówię, że powinniśmy robić głosowanie do każdej pierdółki, ale jeśli coś ustalamy na sztywno (ma być tak, a nie inaczej), to powinno to być wręcz zasada. Podoba mi się pomysł Beax, żeby zrobić podsumowanie z ustalonych kwestii. Potem wystarczyłoby zrobić jedno głosowanie, czy przyjąć całość jako zalecenie, czy jako zasadę. --Nux (dyskusja) 19:46, 1 paź 2008 (CEST)
- Pamiętam że coś podobnego zrobiono przy elementach sieci kolejowej. Najpierw zebranie tego na co wszyscy się zgadzają, póxniej głosowane. PMG (dyskusja) 15:44, 15 lis 2008 (CET)
- Zgadzam się, że to, co do czego jest zgoda, powinno być zatwierdzone w jednym głosowaniu. A w sprawach spornych najlepsze chyba będą osobne głosowania. Spróbuję je ogłosić, chyba że ktos bardziej doświadczony ma lepszy pomysł. BartekChom (dyskusja) 01:42, 13 gru 2008 (CET)
- Ogłosiłem głosowanie. Proponuję, żeby zaczęło się za tydzień i trwało dwa tygodnie. Jeśli ktoś chce coś poprawić, zapraszam. Wikipedia:Głosowania/Standardy infoboksu BartekChom (dyskusja) 18:07, 14 gru 2008 (CET)
- Zgadzam się, że to, co do czego jest zgoda, powinno być zatwierdzone w jednym głosowaniu. A w sprawach spornych najlepsze chyba będą osobne głosowania. Spróbuję je ogłosić, chyba że ktos bardziej doświadczony ma lepszy pomysł. BartekChom (dyskusja) 01:42, 13 gru 2008 (CET)
- Pamiętam że coś podobnego zrobiono przy elementach sieci kolejowej. Najpierw zebranie tego na co wszyscy się zgadzają, póxniej głosowane. PMG (dyskusja) 15:44, 15 lis 2008 (CET)
- Jeśli się nie mylę, to najbardziej wyrównane są spacje, grafiki i wiele parametrów w jednym wierszu, bo koordynaty jak widzę są już ponownie otworzone. W zasadzie jakby się czepiać, to nawet tam gdzie osiągnięto konsensus w ramach naszego projektu, to ktoś mógłby się potem przyczepić. Większość z nas jest obeznana w technikaliach wiki i możemy być nieobiektywni. Dotyczy to wszystkich łącznie ze mną, bo łatwiej mi będzie napisać skrypt do sprzątania infoboksów, jeśli wszystkie parametry będą w osobny wierszu. Problem w tym, że osoby nie-techniczne będą musiały się dostosować do naszych ustaleń jeśli zaczniemy botować w danym kierunku. Nie mówię, że powinniśmy robić głosowanie do każdej pierdółki, ale jeśli coś ustalamy na sztywno (ma być tak, a nie inaczej), to powinno to być wręcz zasada. Podoba mi się pomysł Beax, żeby zrobić podsumowanie z ustalonych kwestii. Potem wystarczyłoby zrobić jedno głosowanie, czy przyjąć całość jako zalecenie, czy jako zasadę. --Nux (dyskusja) 19:46, 1 paź 2008 (CEST)
Głosowanie
edytujWitam
Na podstawie głosowań m. in. o utworach muzycznych chciałym aby głosowanie nie było oddawane w jednym pakiecie (punkt pierwszy) tylko rozbite na pojedyncze podpunkty. Chcę w ten sposób uniknąć tego by jeden punkt uniemożliwił przyjęcie całościowych ustaleń. Bo wystarczy że komuś nie będzie się podobało rozbicie parametrów grafiki na 4 części i zdobędzie troche poparcia i pozostałe 12 podpunktów poleci.
Najchętniej zrobiłbym pogrupowanie że głosuję za 1, za 2 a na końcu "za wprowadzeniem wszystkiego". Będzie ewentualnie trochę zamieszania, ale to chyba lepsze niż ubicie zaleceń bo nie chciało nam się rozbić tego.
Poza tym nie widzę teraz specjalnej różnicy w trzecim głównym punkcie poza pogrubieniem nazw parametrów.
Ale cała reszta mi się podoba bo w końcu to raczej przepchniemy (w jedną albo w drugą ale zawsze jakieś zalecenia będą). PMG (dyskusja) 22:37, 16 gru 2008 (CET)
- Co do różnicy w stylu, chyba główną są białe ramki w drugim wariancie. A ryzyko, że projekt upadnie z powodu jednego podpunktu, faktycznie jest, wiec popieram wniosek. BartekChom (dyskusja) 21:33, 17 gru 2008 (CET)
- Wszystko osobno, to trochę chyba za dużo, ale grafiki można by było wyrzucić do innej grupy, bo były prawie 50/50. --Nux (dyskusja) 01:56, 18 gru 2008 (CET)
- Wiesz - z sieciami zrobiono tak i jakoś dali rade chociaż było sporo głosowania. Mi zalezy na tym żeby coś z tego głosowania wyszło. PMG (dyskusja) 13:10, 19 gru 2008 (CET)
Po głosowaniu
edytuj(Dyskusja przeniesiona z kawiarenki)
Rozchodzi się o wygląd infoboksów, który miał zostać zestandaryzowany po dyskusji (patrzy wyżej) i głosowaniu. Od jakiegoś czasu jednak Mareklug zmienia niektóre infoboksy ({{Jezioro infobox}}, {{Park narodowy infobox}}, nowy {{Takson infobox}}) - są to głównie bardzo przydatne rozbudowy szablonów (np. możliwość dodawania mapek), ale widoczną na pierwszy rzut oka zmianą jest powiększony (a raczej niepomniejszony) rozmiar czcionki, sprzeczny z zaleceniami (90% dla komórek infoboksu, 120% dla nagłówków). Marek nie zgadza się z zaleceniami i ma ku temu sensowne powody, które mnie jednak akurat nie przekonują:) Były już rewerty i przeczuwam, że jeśli nie rozwiążemy tej kwestii prędko, to a) prędzej czy później rozpęta się wielka kłótnia, b) standaryzację szlag trafi, bo każdy infoboks i tak będzie inny. Nie jestem bardzo nieprzychylny zmianom Marka od strony merytorycznej, ale mam wątpliwości w związku ze stylem ich wprowadzania. Proponuję przedyskutować jeszcze raz (a dobrze) drażliwe punkty zaleceń i przyjąć w końcu którąś wersję, której naprawdę będziemy się trzymać. ToSter→¿? 12:43, 5 lut 2009 (CET)
- Najlepiej wszystkie style (cellpadding, cellspacing, margin, border-collapse, background-color, etc.) wrzucić do klasy infobox w MediaWiki:Common.css i ustawić zgodnie z wypracowanymi zaleceniami. Osobom, którym przeszkadza zbyt mała czcionka (lub cokolwiek innego) mogą sobie zdefiniować style w monobooku. Yarl ✉ 12:50, 5 lut 2009 (CET)
- Drodzy ToSterze i Yarlu: Najlepiej wypracować sensowne zalecenia wpierw, w oparciu o merytoryczne potrzeby i dobre zasady designu dla GUI, dopiero wtedy gromadzić definicje w klasy i nalegać o trzymanie fasonu/zalecać cokolwiek w temacie. Może nie każdy jest tu designerem, ale co poniektórzy wikipedyści m.in. używający Apple Macintosha mają za pasem nie tylko ...zapasy :) ale i staż profesjonalny w tym zagadnieniu, wieloletnie doświadczenie projektowania dla sieci. Może jednak warto ustosunkować się podatnie/przychylnie do kombinowanych przezeń usprawniań? :)
- Zasiedzenie nie jest merytorycznie uzasadnionym powodem rewertowania usprawnień technicznych przez osoby o przyciskach admińskich czy nawet rzekomej przynależności do wikiprojektu infoboksy. O ile wiem, ostatnie wielkie usprawnienia w infoboksach i szablonach map lokalizacyjnych i współrzędnych zostały wykonane przez osoby niestowarzyszone z tym dead parrotem.... Może zacznijmy od tego, i nie od ustalania technicznych prawd głosowaniem, na litość boską, szczególnie jako lekarstwa na zamarcie dyskusji w temacie na stronie wikiprojektu, jak to miało miejsce niedawno właśnie w infoboksach. Teraz sam fakt tego głosowania jest wytaczany przez ToStera jako wiążący. Fakt zaistnienia zamarłej dyskusji nie usprawiedliwia narzucenia przez PMG i BartkaChoma wybiórczo zhakowanych paru opcji głosowanych przez kilkunastu osób co lubią głosować. :)
- Merytoryczność designu czy szaty graficznej Wikipedii polega na znajomości tematu, ale także na chęci sprawdzenia, jak ta Wikipedia się wyświetla bliźnim, następnie przemyślanego ustawienia tej szaty tak, aby nikomu nie popsuło. Stosowanie tej strategii nosi nazwę browser-neutral user interface design and implementation i jest nagminnie praktykowane tam, gdzie ludziom za interfejsy płacą. :)
- Proszę zatem o racjonalny dialog techniczny, a nie o przychylność do tego co piszę i koduję, czy brak przychylności. Bo mi tak naprawdę wisi, czy ktoś tu jest mi przychylny, lub czy ma opinie własne. Ja osobiście koduję usprawnienia dla wszystkich i pracuję nad tym zespołowo. Na IRC-u np. jestem cały czas. Jest gdzie i jak omówić interaktywnie wszystkie te sprawy. Wikipedyści Saper, JDavid i ja to robimy codziennie, i jakoś nam idzie. Dlaczego nie ma was tam? Dlaczego powstał zamiast waszej współpracy interaktywnej ten wątek w kawiarence?
- @Yarl, Wszyscy akurat nie mają możliwości ustawienia sobie tego co można, czy należy, w monobooku. Może byś napisał gadżeta do ustawień przez użytkowników pewnych rzeczy łatwo, w GUI, w preferencjach, które sterowałyby tymi zaproponowanymi przez Ciebie klasami? To samo jest potrzebnym w kwestii preferencyjnego ustawienia formatu używanego przez rozmaite szablony cytuj: w normie polskiej, Harvardu, APA. Także rozmiaru fontu w przypisach i bibliografii. Powinien on być wybieralny. Wtedy rzeczywiście ten temat będzie zaadresowany należycie i bezkonfliktowo.
- Zaistnienie gadżetu w preferencjach sterującego szatą graficzną również będzie kolejnym powodem do zalogowaniem się. Przecież potrzebujemy nowej krwi, aby nasz projekt rósł i angażowali się w niego nasi przyszli administratorzy.
- Co do metodologii testowania: Należy w pierwszej kolejności przetestować rozmaite urządzenia i ich soft w ustawieniu domyślnym, ponieważ kawiarenki internetowe, laboratoria szkolne często nie pozwalają na modyfikacje typu "ściągnę sobie lepszego fonta". No i ludzie często nie wiedzą jak ustawić sobie komputer lub korzystają z Wikipedii za pośrednictwem nieprzewidzianego przez nas oprogramowania (np. Eureka, Wikipanion, Wikiamo, WikiTap, WorldWiki na iPhonie/iPodzie touch).
- Strony typu Browser Cam są bardzo pomocne w testowaniu na rozmaitych ekranach i przeglądarkach, ale nic nie zastąpi testującemu wikipedyście obejrzenia i edytowania konkretnych artykułów Wikipedii w przeglądarkach innych nize jego codzienne. Należy to wykonać w miare dostepu do sprzętu na Linuksie, na Macu, w iPodzie/iPhonie, w telefonach Nokii, Ericssona, Samsunga, kieszonkowych Blackberry i Palm, na netbookach -- nie tylko pod polskim interfejsem dla Windows XP czy Visty na dużym ekranie, nie zapominając o Windows98, które to nadal żyje na starych komputerach w Azji i Afrce (Debian/OpenBSD/FreeBSD/NetBSD/One Laptop Per Child).
- Może nie każdy ma na to czas, ale jak nie ma czasu ani chęci na ogólne sprawdzanie jak bliźniemu Wikipedia się maluje na ekranie, to proszę raczej o nie ingerowanie w "ustalanie". Każdy z nas może sobie łatwo założyć minimalnego Linuksa Debian (net instaluj) obok domowego Windowsa, na dowolnym komputerze dowolnej architektury. Właśnie dlatego Debian jest doskonałą dystrybucją Linuksa na takie testowanie. Nic to nie kosztuje przy łączu stałym. Jeżeli potrzeba pomocy, np. w opanowaniu sprowadzania dysku systemowego metodą inkrementalną jigdo czy przy konfiguracji samego Debian, czy jaki soft konkretnie testować, i jak to robić, służę, zawsze służyłem.
- Nie przyjmuję za wikizasadną argumentację kroju "bo tak zagłosowaliśmy" lub "bo tak jest od lat". Wikipedia jest od informowania czytelników, ale też do usprawniania przez wszystkich wikipedystów. Proszę nie zabijać moich inicjatyw mających oba te cele na uwadze, tylko dlatego, bo co poniektóre przejściowe/tymczasowe ustawienia odstają komuś od ustalonego/zasiedzonego ustalenia. To jest wiki, i pewien rozgardiasz przejściowy jest pożyteczny, inaczej nic nie można by zmienić na lepsze.:) Pozdrawiam serdecznie przedmówców i czytających, zapraszając wszystkich do roboty w miarę ich możliwości. --Mareklug dyskusja 21:43, 5 lut 2009 (CET)
- No i bardzo fajnie, że o tym wszystkim piszesz - o to przecież chodzi :) Potrzebna jest spokojna dyskusja - mogłeś przecież to napisać na stronie głosowania czy dyskusji o infoboksach, a jedyna Twoja opinia na ten temat w tamtym miejscu to posłanie głosujących wszystkich w diabli i trudno się dziwić, że głosowanie zakończyło się tak, jak się zakończyło. Wcale nie chcę za wszelką cenę wersji z głosowania, chcę tylko, żeby kontynuować standaryzację - robimy to z navboksami, róbmy też z infoboksami. A tu nie obejdzie się bez dyskusji. Z IRC-a nie pozostaje ślad i śledzić dyskusję może tylko ułamek obecnych tam, a ja zresztą tego środka komunikacji specjalnie nie lubię :)
- Proponuję zatem dyskusję wskrzesić w wikiprojekcie Infoboksy, najlepiej, gdyby zdeklarowali się ci, którzy chcą w niej aktywniej uczestniczyć, żeby potem znów się nie okazało, że ktoś ma zupełnie inną koncepcję. Na razie, jeśli o stronę merytoryczną idzie - moim zdaniem powinniśmy sprawić w pierwszej kolejności, żeby 95% użytkowników miało estetyczną Wikipedię, taką, jaką chce. A potem dopiero martwić się o używających przeglądarki o promilowym rozpowszechnieniu. ToSter→¿? 22:28, 5 lut 2009 (CET)
- Dokładnie jak ToSter, najlepiej omówić wszystko na WP:IB, w końcu po to jest :). Yarl ✉ 14:26, 6 lut 2009 (CET)
No to się przenieśliśmy i tu kontynuujmy dyskusję, z której wiele dobrego powinno wyjść :) ToSter→¿? 13:47, 7 lut 2009 (CET)
- Powinno, ale dzisiaj widzę {{Wieś infobox}} w szacie graficznej rodem z początków internetu i nie wiem co o tym myśleć. Rozumiem argumenty, mnie też czasami małe fonty gryzą, ale trzema dojść do porozumienia, aby nie skończyło się revertami. Yarl ✉ 14:12, 14 lut 2009 (CET)
Z tego co widzę Mareklug stara się prowadzić dyskusję (przeforsować swe poglądy i propozycje nawet te wcześniej "odrzucone" ) na wszystkich frontach, że aż się mętlik robi i dojdzie zapewne niedługo do dantejskich scen Zmiana wyglądu szablonów Miasto i Wieś infobox. Tenautomatix (dyskusja) 20:49, 15 lut 2009 (CET)