Wikiprojekt:Infoboksy/standardy2

	Infoboksy Dyskusja
Standardy przyjęte głosowanie Standardy (część 2) Uczłowieczanie instrukcji Kategoria:Infoboksy

Podstrona służąca do ustalania i sprecyzowania zaleceń dot. tworzenia infoboksów.

W 2008 roku przeprowadzono długa dyskusję dotyczącą ujednolicenia infoboksów. Po tej dyskusji nastąpiło ogólne głosowanie, w wyniku którego zostały przyjęte Standardy infoboksu.

W związku z podważaniem przez niektórych ustaleń z tamtego głosowania oraz braków w ustaleniach, które wyszły na jaw podczas prób standaryzacji infoboksów chciałbym kontynuowac tę dyskusję i zakończyć ją ponownym głosowaniem.

Przyjęte standardy:

1. Nazwy parametrów z polskimi znakami i spacjami, małymi literami (z wyjątkiem nazw własnych), w formacie data śmierci. (NIE dataśmierci, data_śmierci, data smierci, Data śmierci)
2. Nazwy często używanych parametrów:
   • data urodzenia, data śmierci
   • łącza do projektów siostrzanych: wikisłownik, wikicytaty, wikinews, wikiźródła, wikibooks, wikiwersytet, wikispecies, commons.
3. Wstawianie grafiki: 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.
4. Wielkość czcionki: 90% - czcionka globalna i podnagłówki, 120% - dla nagłówka nadrzędnego.
5. Wstawienie łączy zewnętrznych z http://, bez mozliwości ustawiania opisu: kod typu [{{{www}}} Strona internetowa gminy] [{{{bip}}} BIP gminy].
6. Szerokość infoboksu: 250px lub 300px, gdy przy 250 się nie mieści.
7. Nazwy typu {{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}}).
8. Jeśli nie ma to dodatkowej funkcji (np. dodanie do kategorii z odpowiednim rokiem), nie tworzymy linków automatycznie w infoboksach.
9. W kodzie używamy szablonów infoboksów.
10. Kolory komórek takie jak obecnie, kolory nagłówków dowolne (z umiarem).
11. Nie definiujemy interlinii, zostawiamy wartość domyślną (line-height:150%).
12. Grupujemy współrzędne geograficzne i inne pola w bardzo uzasadnionych przypadkach:

{{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
}}

13. Linki do projektów siostrzanych są realizowane jako pojedyncze i bezpośrednie:

Zasady głosowania

IMO trzeba przyjąć podobne zasady głosowania co poprzednio. Tzn. w sytuacjach, w których pojawią się rozwiązania (maksymalnie 2-3 różne, najlepiej jedno wspólne) akceptowalne przez większość dyskutujących, taki punkt będzie poddany globalnemu głosowaniu. Głosowanie powinno być wspólne dla większości propozycji, z możliwością podziału na części tematyczne. Zagłosować powinno co najmniej 20 osób, co najmniej 70% głosów zdecydowanych (bez neutrealnych) jest potrzebnych do przyjęcia rozwiązania. Proponuję 14 dniowe głosowanie, najlepiej w terminie mało świąteczno/urlopowym (przynajmniej jeden cały/ciągły tydzień w dni, w których jest szkoła). ~malarz pl ^PISZ 11:19, 6 cze 2011 (CEST)

• Proponuję na początek spróbować przyjąć przez konsensus -- Bulwersator (dyskusja) 21:31, 28 mar 2012 (CEST)

Szerokość infoboksu

Czy można zdefiniować co oznacza (może oznaczać) Szerokość infoboksu 300px, gdy przy 250px się nie mieści? ~malarz pl ^PISZ 12:15, 2 cze 2011 (CEST)

Lepsze byłoby "w szczególnych przypadkach". Ta furtka została zostawiona np. dla {{pierwiastek infobox}} (który jeszcze pół roku temu miał 300px, o, w tej wersji), gdzie wg mnie wątpliwą ideą jest upychanie całego układu okresowego albo sześciokolumnowej tabelki z izotopami na 250px. Podobnie było z {{Związek chemiczny infobox}}, ale widzę, że i tam udało się zmieścić w 250px. Nie jest to wg mnie optynmalny pomysł, ale skoro zaaprobowali to nasi wikichemicy, to się nie wtrącam; jeśli nie zostało już ani jednego trzystupikselowca, to można tę uwagę wyciąć. Matma Rex dyskusja 14:58, 25 lut 2012 (CET)

{{Związek chemiczny infobox}} spokojnie mieści się w 250px. {{Pierwiastek infobox}} → odnośnie tabelki osobiście nie widzę przeciwwskazań dla 250px; odnośnie układu, to jego obecność jest IMHO bardziej wątpliwa niż 250px szerokości. Ad rem: jeśli do tego punktu podchodzić się będzie zdroworozsądkowo (czyli jeśli rzeczywiście potrzebne będzie 300px to się ten standard nagnie), to rzeczywiście można usunąć. ∼Wostr (dyskusja) 21:56, 25 lut 2012 (CET)

Ja bym wolał doprecyzowanie słów "gdy w 250 się nie mieści". Aktualnie są infoboksy rozpychane przez ilustrację (tylko jak potrzeba szeroką to IMO należy ją wstawić powyżej infoboksu) lub jakąś dużą tabelkę (która IMO nie spełnia wymogu "najważniejsze informacje"). Takie sytuacje są kwitowane w dyskusjach, że w standardach jest zalecenie o 300px. Oczywiście uproszczenie sytuacji i usunięcie zdanie o 300px też usunie takie argumenty, ale może jednak lepiej zdefiniujemy "nie mieści" i też będzie w porządku. ~malarz pl ^PISZ 22:12, 25 lut 2012 (CET)

Linki zewnętrzne

Propozycja aby w infobokise umieszczać tylko oficjalne linki zewnętrzne oraz linki do pewnych baz danych (państwowe, instytucji międzynarodowych o uznanym znaczeniu ...). Unikniemy wtedy sytuacji jak ze {{stopklatka}} ostatnio w przypadku {{film infobox}} czy {{Bazakolejowa.pl}} w {{stacja kolejowa infobox}}. Dotyczyłoby to też grafik zewnętrznych (okładek płyt, filmów). ~malarz pl ^PISZ 12:15, 2 cze 2011 (CEST)

Się wtrącę ze sprawą odnośników do przekazów audio/wideo. Chodzi mi o to, że np. w infoboksie dot. stacji radiowej, moim zdaniem, powinien wystarczyć link do oficjalnej strony www danej stacji. Poza tym, niektóre stacje nadają kilka strumieni, a jeszcze inne mają nawet po kilka kanałów z osobnymi programami. W przypadku telewizji chyba jeszcze nie było takiej sytuacji, ale może przy okazji dmuchnąć na zimne? SpiderMum (dyskusja) 18:30, 26 cze 2012 (CEST)

Nazwy infoboksów dla jednostek organizacyjnych

W przegłosowanych standardach jest informacja a właściwie przykład: {{wieś Francja infobox}} (nie {{wieś Francji infobox}} lub {{francuska wieś infobox}}). Ja bym tu dodał, że w przypadku jednostek organizacyjnych państw przed nazwą jednostki organizacyjnej (tu wieś) wstawiamy kod ISO 3166, czyli wyszłoby {{FRA gmina infobox}}. Jest to sprawdzone i dawno temu ujednolicone. Przez ponad dwa lata od wejścia w życie zaleceń nikt nie próbował zmieniać nazw tych szablonów. ~malarz pl ^PISZ 12:15, 2 cze 2011 (CEST)

Jeżeli ktoś się tego podejmie to jak najbardziej popieram. Wyjdą ustandaryzowane nazwy i każdy będzie wiedział jak tworzyć kolejne w razie potrzeby. PMG (dyskusja) 16:52, 25 lut 2012 (CET)

Jestem za, kody państw z ISO 31660-1 alpha 3 powinny być jednolitym standardem. Powerek38 (dyskusja) 09:47, 17 kwi 2012 (CEST)

Ustalenie jednolitego sposobu nazw dla parametrów dotyczących współrzędnych geograficznych

W większości infoboksów jest 12 parametrów dotyczących współrzędnych geograficznych, z których 6 powinno być użytych a pozostałe powinny być puste nieużyte. Mam do tego pewne zastrzeżenia, ale w wyniku dyskusji w kawiarence takiego rozwiązania używam w standaryzowanych szablonach. Proponuję coś ustalić, np. wprowadzić ten zestaw parametrów do standardu. ~malarz pl ^PISZ 12:15, 2 cze 2011 (CEST)

Biorąc pod uwagę to, że coś w końcu się ruszyło z prawdziwym językiem programowania dla szablonów (en:Wikipedia:Wikipedia Signpost/2012-01-30/Technology report), koordynaty, mapy lokalizacyjne i przyjaciele zapewne pójdą na pierwszy ogień i może będzie można napisać po prostu koordynaty = 50°03′41″N 19°56′18″E (i również działający wariant bez unikodowych znaczków, a co!). Nie wiem więc, czy jest sens głosować - aczkolwiek temat raczej niekontrowersyjny, więc chyba nie zaszkodzi. Matma Rex dyskusja 15:32, 25 lut 2012 (CET)

Generalnie już teraz można wprowadzić zapis typu:

|szerokość = 52/13/56/N
|długość   = 21/00/30/E

Tylko nie wiem, czy się przyjmie. ~malarz pl ^PISZ 12:26, 4 kwi 2012 (CEST)

"a pozostałe powinny być puste" - a nie lepiej by wyciąć te zbędne? Jak mamy hasło Kraków i mamy " |stopniN = 50 |minutN = 03 |sekundN = 41" to puste parametry "|stopniS" są całkowicie zbędne -- Bulwersator (dyskusja) 12:04, 4 kwi 2012 (CEST)

Pisałem tę wiadomość patrząc od innej strony (wnętrza szablonu). Mój bot jak pewnie zauważyłeś, usuwa pozostałe współrzędne jeżeli któreś są wypełnione. ~malarz pl ^PISZ 12:26, 4 kwi 2012 (CEST)

Uh, no niby można, ale ja bym jednak wolał nie wprowadzać u nas magicznych szablonów, które wyciągają substringi poprzez szalone #switch-e, składnia MediaWiki jest już wystarczająco chora... Poza tym warty zastanowienia byłby separator - bo według mnie wersja z ukośnikiem wygląda jak data, a nie współrzędne geograficzne. Wg mnie niezły byłby pipe (no ale to nie przejdzie), albo po prostu spacja. Matma Rex dyskusja 15:46, 4 kwi 2012 (CEST)

Mi też się nie podoba. Ale można te stringi dzielić poprzez #titleparts właśnie na fragmenty rozdzielane ukośnikiem. Inaczej chwilo się nie da. ~malarz pl ^PISZ 15:59, 4 kwi 2012 (CEST)

• Ja jestem bardzo mocno za tym, aby parametry te wyglądały w sposób kompatybilny z Geolocatorem, który jest podstawowym narzędziem generowania fragmentów kodów z koordynatami (chyba, że ktoś je wklepuje ręcznie, ale ja z moimi bardziej "masowymi" pracami na tym polu, to bym się skichał bez tego narzędzia). Więc dla mnie może być każdy format, tak długo jak będzie to format z tego narzędzia lub dogadacie się z jego słowackim autorem, żeby zmienił też u siebie. Powerek38 (dyskusja) 09:51, 17 kwi 2012 (CEST)

---

Nie wiem czy to jest archiwum, i czy ktoś to czyta, ale ja mógłbym odgrzać temat i zaimplementować w Lua wszystkie możliwe formaty zapisu dwóch parametrów:

|szerokość = 52[ _°/]13[ _'/]56[ _"/]N
|długość   = 21[ _°/]00[ _'/]30[ _"/]E

definiując funkcje do parsowania wywoływane przez np. {{Szerokość|{{{szerokość}}}|opcje}} i {{Długość|{{{długość}}}|opcje}} jak również przypadek specjalny dla {{Współrzędne|{{{szerokość}}}|{{{długość}}}|opcje}}. Podział na szerokość i długość uważam za zasadny, gdyż jest przydatny dla map lokalizacyjnych. Chociaż nie wykluczam wersji, w której wszystko by bazowało na jednych koordynatach. Paweł Ziemian (dyskusja) 23:05, 15 sie 2013 (CEST)

Mam w brudnopisie moduł, który akceptuje koordynaty w jednym parametrze:

{{Wikipedysta:Paweł Ziemian/Koordynaty|50°03′41″N 19°56′18″E}} → 50°03′41″N 19°56′18″E

{{#invoke:Brudnopis/Paweł Ziemian/Koordynaty|szerokość|50°03′41″N 19°56′18″E}} → {{#invoke:Brudnopis/Paweł Ziemian/Koordynaty|szerokość|50°03′41″N 19°56′18″E}}

{{#invoke:Brudnopis/Paweł Ziemian/Koordynaty|długość|50°03′41″N 19°56′18″E}} → {{#invoke:Brudnopis/Paweł Ziemian/Koordynaty|długość|50°03′41″N 19°56′18″E}}

Paweł Ziemian (dyskusja) 16:42, 18 sie 2013 (CEST)

Spacje w wywołaniach

Jest to element standardu, który nie został przyjęty w poprzednim głosowaniu (choć był głosowany).

Wariant 1

wyrównanie znaków równości

{{Wikipedia:Infoboksy/wariant 1
 |        nazwa = Artykuł
 |nazwa grafiki = Przyklad.jpg
}}

Wariant 2

pojedyncze spacje

{{Wikipedia:Infoboksy/wariant 2
 |nazwa = Artykuł
 |nazwa grafiki = Przyklad.jpg
}}

Wariant 3

{{infobox 
 |nazwa         = Artykuł
 |nazwa grafiki = Przyklad.jpg
}}

Na wariant pierwszy oddano 3 głosy, na wariant 2 - 20 głosów i na wariant 3 - 14 głosów. Nie ukrywam, że mi najbardziej odpowiada wariant 3. W większości wywołań infoboksów oraz w większości instrukcji do nich jest właśnie on jest stosowany. Proponowałbym powtórzyć głosowanie biorąc pod uwagę jedynie warianty 2 i 3. ~malarz pl ^PISZ 12:15, 2 cze 2011 (CEST)

Też uważam że tutaj byłoby dobrze to ustalić. Jeżeli zostanie to ustalone warto by to wstawić do SK. Też pasuje mi najbardziej wersja trzecia - najlepsza możliwość sprawdzenia kilku parametrów na raz. Przykładem może być poprawianie interpunkcji z metrami, kilogramami - bardzo to poprawia szybkość poprawek. A jak ktoś chce czytać tylko dane to nie ogląda ich w trybie edycji, więc sprawa czytelności (podawana zapewne w przypadku wariantu 2) jest mniej istotna. PMG (dyskusja) 16:55, 25 lut 2012 (CET)

Uważam, że pojedyncze spacje są optymalne, można ewentualnie dodać po spacji po "|". To umożliwiłoby proste eliminowanie multispacji z artykułów. Są nieliczne przypadki, w których dla przejrzystości trzeba ich użyć. Poza tym sztucznie rozpychają wielkości artykułów i trudno jest utrzymać na dłuższą metę określoną ilość spacji, aby utrzymać równy układ zmiennych. Zatem najbliższym rozwiązaniem jest dla mnie wariant 2. Karol007dyskusja 12:15, 28 mar 2012 (CEST)

Ja poprzednio głosowałem chyba za wariantem 2, ale teraz zmieniłem zdanie i botując infoboksy zmieniam na wariant 3 + spacje po "|" (przykładowa edycja, w diffie nie widać spacji). Byłbym w stanie dołożyć to do WP:SK, mój kod jest w Rubym, ale łatwo go będzie przetłumaczyć. Matma Rex dyskusja 18:31, 28 mar 2012 (CEST)

• Wersja 3, o wiele czytelniejsze -- Bulwersator (dyskusja) 18:33, 28 mar 2012 (CEST)
  • Parametry infoboksu w wersji 3 wygodniej się uzupełnia niż w wersji 2. --MPK100 (dyskusja) 00:44, 29 mar 2012 (CEST)

Poniżej dołączony nowy wątek rozszerzający zawarte tu propozycje. ~malarz pl ^PISZ 20:50, 29 mar 2012 (CEST)

Mamy czasami:

{{Pewien infobox
 | bardzo długa nazwa parametru = 
 | parametr2    = 
}}

Czy długość nazwy parametru winna być ograniczona aby = były w jednej linii, pionowo?

Dobrze byłoby poskracać te bardzo długie nazwy. Najczęściej to są jakieś specjalistyczne nazwy i tak trzeba zerknąć do opisu, by wiedzieć czego dotyczą. Teraz mamy monstrualne pompowanie wielkości artykułów poprzez spacje w infoboksach. Przykuta (dyskusja) 18:01, 6 cze 2012 (CEST)

Czasami długa nazwa musi być długa, bo chodzi nam o czytelność i zrozumienie. W wielu szablonach są porobione skróty, które zna tylko ich autor i garstka jego znajomych. Żeby dokonać edycji trzeba wejść na stronę opisu (w tym wypadku infoboksu) - i edycja która mogła zająć 3 sek. zajmuje 5 min. Wracając do tematu - wariant 3 jest najczytelniejszy przy wypełnianiu infoboksu informacjami. - Beax 21:11, 19 cze 2012 (CEST)

Hej, infoboksy edytują nie tylko boty, ale często też ludzie. Już kiedyś zrezygnowaliśmy z wyrównywanych w pionie znaków równości, bo szlag ludzi trafiał gdy poprawiali, przeredagowywali tak sformatowane szablony. Spacja po "|", przed i po znaku "=" to rozwiązanie najwygodniejsze do edycji. Kenraiz (dyskusja) 08:03, 8 lip 2012 (CEST)

"Perfekcyjny" szablon wywołania infoboksu

To jest mocno techniczne zagadnienie i właściwie takie czepianie się szczegółów, zupełnie nieistotne dla większości edytorów, a tylko dla twórców botów i narzędzi sprzątających.

Jak powinno wyglądać idealne wywołanie infoboksu? A dokładniej, gdzie i ile powinno być spacji? Są tu dwa zagadnienia poniekąd istotne (1. znaki pipe na początku linii, nie na końcu; 2. czy wyrównujemy znaki równości?), ale też parę pierdółkowatych ;), które pasowałoby ustalić, aby uniknąć "wojen narzędzi". Ciągle widzę edycje z WP:SK usuwającym spacje na końcach linii (również po znakach "=" w parametrach bez wartości), a ostatnio zauważyłem, że mój kanon infoboksu różni się nieco od kanonu malarza i mój bot przy okazji dodawania koordynatów ponownie zestandaryzował {{cmentarz infobox}} w przynajmniej kilkudziesięciu artykułach (przykład edycji). Przydałoby się jakieś rozwiązanie, aby uniknąć wojen narzędzi (skoro już i tak chyba wyjątkowo spośród wszystkich Wikipedii dbamy o wygląd kodu, a nie tylko artykułu).

Dla ilustracji, weźmy sobie taki fragment wywołania. Zaznaczyłem chyba wszystkie problematyczne miejsca. Układ nowych linii i pisanie nazwy infoboksu dużą literą chyba nie budzą żadnych kontrowersji.

{{Pewien infobox
<1>|<2>nazwa obiektu<3>=<4>Wikipedia
<1>|<2>oryginalna<3>=<5>
<1>|<2>stopniN<11>=<6>52.197<1>|<2>minutN<11>=<7><1>|<2>sekundN<11>=<8>
<1>|<2>stopniE<11>=<6>18<1>|<2>minutE<11>=<6>38<1>|<2>sekundE<11>=<6>27
<1>|<2>parametr wielolinijkowy<9>=<10>
* Na przykład lista
* Cośtam
<1>|<2>www<3>=<5>
}}

1. Przed |
2. Po |
3. Przed =; normalny parametr
4. Po =; normalny parametr, z wartością
5. Po =; normalny parametr, bez wartości
6. Po =; koordynaty, z wartością
7. Po =; koordynaty, bez wartości
8. Po =; koordynaty, bez wartości, koniec linii
9. Przed =; parametr wielolinijkowy
10. Po =; parametr wielolinijkowy
11. Przed =; koordynaty

Według mnie pojedyncze spacje powinny być w miejscach: 1, 2, 4, 5, 6, 7, 8, 9, 11. Bez spacji: 10. Wyrównanie: 3. (Pogrubiłem te, które nie zgadzają się z szablonem WP:SK lub malarza.) Powyższe wywołanie wyglądałoby więc tak:

{{Pewien infobox
 | nazwa obiektu = Wikipedia
 | oryginalna    = 
 | stopniN = 52.197 | minutN =  | sekundN = 
 | stopniE = 18 | minutE = 38 | sekundE = 27
 | parametr wielolinijkowy = 
* Na przykład lista
* Cośtam
 | www           = 
}}

Chyba tylko kwestia wyrównania budzi jakiekolwiek emocje w szerszej społeczności, resztę możemy przeforsować sami ;) Po ustaleniu wspólnej wersji należałoby ją zaimplementować w narzędziach infoboksowych - w tej chwili jest to chyba tylko WP:SK Nuxa i ekipy (w JavaScripcie), bot malarza (bodajże Perl?) i mój bot (Ruby) (i jeszcze moje stare narzędzie infobox.js, ale nie wiem, czy ktokolwiek tego używa). Jestem gotowy zaaplikować to do WP:SK (pasowałoby puścić Nuxowi info o tej dyskusji, o ile jeszcze go to interesuje :) ). Matma Rex dyskusja 19:17, 28 mar 2012 (CEST)

Przyznam, ze jako laik mniej wiecej tak to sobie tez dotychczas wyobrazalem, w podobny sposob formatujac edytowane czasami przyklady uzycia dla niektorych infoboksow.

A z drugiej strony za dosc uciazliwe dla (w szczegolnosci niedoswiadczonych. czy tez majacych problemy ze wzrokiem) uzytkownikow jest IMO dotychczasowe generowane przez niektore narzedzia przypisow, jako jeden dlugi nieprzerwany ciag znakow bez jakiejkolwiek spacji, jak np. w przypadku dostepnego jako gadzet w oknie edycji narzedzia cytowania. IMO, gdyby poszczegolne parametry oddzielane bylyby w tym przypadku spacjami, byloby znacznie przejrzysciej i latwiej dla uzytkownikow odnajdywac poszczegolne elementy przypisow w tresci edytowanych artykulow, np. w celu naprawy martwych linkow, aktualizacji, uscislenia itp. -- Alan ffm (dyskusja) 19:55, 28 mar 2012 (CEST)

Powstał fork #Spacje w wywołaniach, więc go dołączam do tamtej sekcji. W sumie ciekawy pomysł. Mój bot w stosunku do tej propozycji nie dodaje spacji 2 za to dodaje spacje 10. Spacje przy współrzędnych obydwa kody robią jak w przykładzie. Mam tez przygotowany kod (jako rozszerzenie do wp:sk) robiący w praktyce dokładnie to samo. Ten .js tylko formatuje kod, bot (w Perlu) czyta opis szablonu i odpowiednio przegrupowuje parametry wywołania. Po zastanowieniu - spacja "2" łatwa do doimplementowania do obu rozwiązań, spacja "10" tylko w przypadku znanego opisu szablonu, więc w przypadku wp:sk może być trudna do realizacji. ~malarz pl ^PISZ 20:50, 29 mar 2012 (CEST)

Ja bym się zastanowił nad drobna modyfikacją:

{{Pewien infobox
<1>|<2>stopniN<11>=<6>52.197<1>|<2>minutN<11>=<7>__<1>|<2>sekundN<11>=<8>
<1>|<2>stopniE<11>=<6>18____<1>|<2>minutE<11>=<6>38<1>|<2>sekundE<11>=<6>27
}}

albo:

{{Pewien infobox
<1>|<2>stopniN<11>=<6>52.197<1>|<2>minutN<11>=<7>__<1>|<2>sekundN<11>=<8>
<1>|<2>stopniE<11>=<6>____18<1>|<2>minutE<11>=<6>38<1>|<2>sekundE<11>=<6>27
}}

W obu przypadkach "nowe" spacje zastąpiłem podkreśleniami. ~malarz pl ^PISZ 21:37, 29 mar 2012 (CEST)

Wydaje mi się, że nie warto - pomieszane koordynaty w st./min./sek. i dziesiętne raczej są rzadkie (mój przykład był spreparowany; ew. można by wyrównywać wartości dwucyfrowe z trzycyfrowymi), a utrzymanie wyrównania wymagałoby zabawy spacjami przez użytkowników - w pozostałych przypadkach wystarczy skopiować wywołanie i nic nie zmieniać. Matma Rex dyskusja 23:35, 29 mar 2012 (CEST)

Też tak uważam, lepiej zostawić pojedyncze spacje. Z tego co widzę, to jedynym miejscem multispacji w kodzie będą puste parametry szablonu współrzędnych geograficznych. Ja swojego bota też poprawię i dołożę mu spacje 5-11. OFF TOPIC: Swoją drogą w innych szablonach (nie tylko infoboksach) też przy okazji można sprzątać multispacje na pojedyncze, a gdzie brakuje dodawać. W samej treści artykułów bardzo często obserwuję multispacje, które są traktowane jako błąd. Karol007dyskusja 18:41, 7 kwi 2012 (CEST)

W przypadku wariantów 1 i 3 tłuczemy dodatkowe puste spacje, które liczone są do wielkości artykułu, co zawyża sztucznie liczbę artykułów z dużą liczbą znaków. Widoczne jest to chociażby podczas DNA, czy też podczas skanowania "stubów". Pewnym rozwiązaniem dla lepszej optyki byłoby jakieś zalecenie, aby nie stosować zbyt długich nazw parametrów. Przepraszam, że tak późno z tym wyskakuję, ale wolę teraz niż przy głosowaniu. Przykuta (dyskusja) 20:43, 8 paź 2012 (CEST)

Wielkość ilustracji

Przy szerokości infoboksu 250px grafika może być ograniczana do wielkości 240px albo 240x240px. W drugim przypadku unikamy wyświetlania bardzo wysokich i wąskich zdjęć. Czy można przyjąć taki rozmiar (240x240px) jako standardowy grafiki w infoboksie. ~malarz pl ^PISZ 12:15, 2 cze 2011 (CEST)

IMHO Ten ”rozmiar (240x240px)” jest najbardziej optymalny. --Władysław Komorek (dyskusja) 10:57, 24 paź 2011 (CEST)

W okrętach wyszło że czasem jest tak że zdjęcie jest wyższe niż szersze. Wszelkie wieże myślę że też będą wyższe niż szersze. Może nie ustawiać na twardo tego 240x240 ale zalecać to ? PMG (dyskusja) 16:56, 25 lut 2012 (CET)

Ja bym chętnie ustawił na twardo z jakąś ostateczną możliwością zmiany. I ujednolicił kwestię kodu. Typu czy trzeba dawać [[Plik:..]], czy bez klamerek, czy wystarczy nazwa pliku bez podania przestrzeni, czy trzeba w ogóle podawać wielkość itd. Bo teraz jest od Sasa do Lasa i mi się to bardzo nie podoba. Tar Lócesilion|queta! 21:44, 25 lut 2012 (CET)

Teoretycznie pkt 3 to załatwia. Tylko, że przerobienie dotychczasowych szablonów zajmuje trochę czasu. Ja już w kilkunastu szablonach (łącznie z wywołaniami) ten aspekt poprawiłem. ~malarz pl ^PISZ 21:53, 25 lut 2012 (CET)

Opcja 240x240px zdecydowanie nie powinna być zastosowana, jedynie ograniczenie szerokości do 240px. Opcja 240x240px nie sprawi że unikniemy wyświetlania bardzo wysokich i wąskich zdjęć, tylko sprawi że tego typu zdjęcia (których jest mnóstwo) będą tak wyświetlane, że będą zmniejszone do zbyt małych rozmiarów (nawet mniej niż 100px szerokości), a co za tym idzie obiekty na nich uchwycone, np. sylwetka człowieka, będą słabo widoczne.--Oleola (dyskusja) 00:34, 29 lut 2012 (CET)

• ale żeby nie było tak, że wszystkie grafiki maja mieć obowiązkowo 240px. Bo jeśli oryginalna grafika ma mniej ? Nie rozciągajmy jej na siłę, bo traci na czytelności. Przykładem są np. zdjęcia legitymacyjne polityków udostępnione jakiś czas temu przez Sejm. Są one b.małych rozmiarów - i są to jedyne zdjęcia na wolnej licencji jakimi dysponujemy. Podobnie jest np. z Plik:Gustaw Holoubek.jpg która wstawiona od infoboksu wygląda jeszcze gorzej Gustaw Holoubek. Dlatego pragnę zwrócić uwagę na dwa aspekty: 1). część grafik wstawianym do infoboksu może mieć b.mały rozmiar (np. ikonki) i rozciąganie tego do 240px może doprowadzić do formy pikselowatego obrazka. Dlatego pozostawiłabym jako opcję parametr z szerokością obrazka. Ale tak, że jeśli ktoś wpisze 500px to wyświetlać sie i tak będzie 240px. 2). Jest też problem zdjęć dużych, które przy 240px tracą na czytelności (choćby każda mapa). Nie wiem dokładnie jak... ale pomyślałabym na dodatkowym opisie (?), linku (?) a może informacji wyświetlanej po najechaniu myszką - "kliknij aby powiększyć". Zdziwilibyście się, że nawet młodzi ludzi pracujący przy komputerze nie wiedzą takich rzeczy. Co więcej, nie zapamiętując że taka "opcja" istnieje. Trzeba zacząć zakładać, że obecni konsumenci - mimo, że korzytają z najnowszych technologii - są kompletnymi ignorantami, nie umieją niczego sami zainstalować (bo przecież "instaluje się samo"...), nie wiedzą czym się różni link na wiki w kolorze niebieskim od tego w kolorze czerwonym ... ect. Naprawdę często spotykam się ze zdaniem, ze na Wikipedii jest ilustracja, ale mała i nic z niej nie wynika.. Tymczasem po "kliknięciu" okazuje się, że jest załadowana w rozmiarze 1600x1200. Taka obserwacja - Beax 21:31, 19 cze 2012 (CEST)

Grafika - ogólniej

Wstawianie grafiki: 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.

Proponuję zamienić na "Wstawianie grafiki: dwa parametry: "grafika" (np. Przykład.jpg) i "opis grafiki" -- Bulwersator (dyskusja) (czyli rezygnujemy z i tak nieużywanej możliwości linkowania a rozmiar będzie ustawiał infobox) -- Bulwersator (dyskusja) 16:54, 2 mar 2012 (CET)

Jestem za, to tylko niepotrzebnie komplikuje szablon, jeśli ma się ręcznie ustawiać np. wielkość zdjęcia. Powerek38 (dyskusja) 09:54, 17 kwi 2012 (CEST)

Tylko zwracam uwagę, że od jakiegoś czasu preferowanym (trafniejszym) określeniem jest "ilustracja", a nie "grafika". Zmiana określenia dokonała się chyba wszędzie z wyjątkiem właśnie szablonów. Jest okazja by rzecz ujednolicić wszędzie. Kenraiz (dyskusja) 08:07, 8 lip 2012 (CEST)

• Propozycja parametru rozmiar wychodzi na przeciw potrzebie dopasowywania wielkości ilustracji do infoboksów, a nie odwrotnie. Można znaleźć przykłady artykułów o dominujących wielkością infoboksach, w których proporcje ilustracji deformują ten element. Jestem  Za propozycją zgłoszoną w projekcie standardu w całości i bez zastrzeżeń. Tomasz Wachowski (dyskusja) 20:17, 11 lip 2012 (CEST)

Kolor linków

WlaKom proponował czarne linki w infoboksie. Innym rozwiązaniem jest unikanie trywialnych linków (metr, powierzchnia, ...) w infoboksie. Proponuję ustalić jedną wersję i wpisać ja do standardu. ~malarz pl ^PISZ 12:15, 2 cze 2011 (CEST)

Wtłaczanie wszędzie linksInherit to używanie armaty na muchę. Jestem gotowy uwierzyć w sens tego np. w nagłówkach navboksów (gdzie niebieski tekst na granatowym tle to faktycznie kiepski pomysł), ale w infoboksach tło wszędzie (z wyjątkiem niektórych nagłówków - wtedy OK) jest białe, jasnoszare lub beżowe, a niebieskie linki nie rażą oczu. Matma Rex dyskusja 15:35, 25 lut 2012 (CET)

Jestem jak najbardziej przeciw zmienianiu koloru linków. Wszędzie uczymy czytelników i edytorów że klikalne linki to kolor niebieski, hasła których jeszcze nie ma to kolor czerwony. Uważam że wszelkie pomysły mające na celu zmianę koloru linków są naganne i idą całkowicie przeciw temu, do czego staramy się przyzwyczaić ludzi. Ludzie mają pojmować tak: czarne - tekst, niebieskie - link do hasła, czerwone - link ale hasło nie istnieje - może chciałbyś utworzyć. Powstawanie pułapek w stylu "to link - ale nie wiesz że to link bo tego nie widzisz" jest złe. PMG (dyskusja) 16:49, 25 lut 2012 (CET)

== class=”linksInherit” ==

Kod class=”linksInherit” pozwala na usunięcie niebieskiego koloru linku, zachowując jednak wszystkie jego właściwości. Linkowany wyraz, bez poprawnego linku, w dalszym ciągu będzie na czerwono.

• Za – eliminując kolor niebieski linku, infoboks wygląda bardziej schludniej, pozwala na większe skoncentrowanie się na treści infoboksu, a nie jego szacie (koloryzacji). Oczywiście najeżdżając myszą na linkowany wyraz w infoboksie, widzimy wyraz podkreślony jak i „chmurki” o ile dostępne. --Władysław Komorek (dyskusja) 19:44, 21 paź 2011 (CEST)

IMO zbędne. Była kiedyś dyskusja w kawiarence na ten temat. Generalnie należy unikać zbędnych linkowań w infoboksie, zaś te istotne powinny być widoczne "bez najeżdżania myszką". ~malarz pl ^PISZ 13:57, 25 lut 2012 (CET)

Temat jest już wyżej (#Kolor linków); zbędne, z wyjątkiem nagłówków o ciemnym tle, jak w {{Żołnierz infobox}}. Matma Rex dyskusja 15:55, 25 lut 2012 (CET)

Tak jak opisałem w "kolorze" - jestem jak najbardziej przeciw temu. Całkowicie sprzeczne z tym do czego przyzwyczajamy użytkowników. PMG (dyskusja) 17:06, 25 lut 2012 (CET)

Połączyłem te dwie sekcje w jedno. ~malarz pl ^PISZ 18:49, 25 lut 2012 (CET)

W jaki sposób infobox będzie bardziej schludny i pozwalał na większe skoncentrowanie się na treści infoboksu? Następnym krokiem byłoby chyba zastosowanie tego dla całej Wiki, aby polepszyć możliwości naszych czytelników w skupianiu się na treści... Tam gdzie nie trzeba - nie linkuje się i jest schludnie. A tam gdzie się linkuje - tam użytkownik powinien wiedzieć, że może kliknąć. Po coś w końcu się linkuje, przecież nie dla samego linkowania. ∼Wostr (dyskusja) 22:04, 25 lut 2012 (CET)

Nazwy polskich i ogólnych infoboksów

Aktualnie jest tak, że polskie miasta są opisywane przez {{Miejscowość infobox}} a miasta z całego świata przez {{miasto zagranica infobox}} lub specjalne dla danego państwa np. {{RFN miasto infobox}}. Swego czasu pamiętam dyskusje w kawiarence dotyczące polskocentryczności nazw infoboksów. Czy nie powinno być tak, że polskie miasta są opisywane przez {{POL miasto infobox}} zaś miasta z całego świata, dla których bardziej szczegółowy infoboks nie jest potrzebny przez {{Miejscowość infobox}}? ~malarz pl ^PISZ 12:20, 2 cze 2011 (CEST)

IMO uscislenia nazw infoboksow typu "zagranica" są dosc silnym przejawem polonocentryzmu i swiat sie wprawdzie od tego nie zawali, ale wskazane byloby tu w miare mozliwosci stopniowe wycofywanie sie z tego typu nazw. Nie musi to nastepowac na zlamanie karku, ale juz conajmniej przy okazji przebotowywania jakiegokolwiek infoboksu nalezaloby tu przy okazji zalatwic w jednej edycji rowniez i ewentualną kwestie tego typu niepozadanego nazewnictwa infoboksow. -- Alan ffm (dyskusja) 16:34, 2 mar 2012 (CET)

Mnie generalnie trochę utrudniają pracę infoboksy dla konkretnego kraju, lepiej żeby był jeden. Dla Polski od biedy jeszcze ok, może być na zasadzie wyjątku osobny, ale dla pozostałych państw zintegrowałbym wszystko w jeden. Nazwa jest sprawą drugorzędną, ale miasto brzmi sensownie. Powerek38 (dyskusja) 09:56, 17 kwi 2012 (CEST)

• A to nie chodzi o to, że jeśli definiujemu coś dla danego kraju, to mamy podział administracyjny od razu taki jaki w danym kraju jest ? W sensie, że wywołaniem nie jest "podział administracyjny 1" i "podział administracyjny 2" tylko bardziej konkretnie "województwo " "powiat czy też w "land" "rejencja". Dla geograficznych wydaje mi się to logiczne, choć oczywiście wrzucenie całej "zagranicy" do jednego worka .... no ale następne pokolenia muszą mieć co robić. Ja bym zostawiła - sprawa rozwojowa, kiedyś będziemy mieli podział ze względu na wszystkie kraje świata (tak myślę ;-)) - Beax 21:43, 19 cze 2012 (CEST)

elementy graficzne w nagłówkach

Proponuję całkowity zakaz używania graficznych ozdóbek w nagłówkach tytułowych infoboksów. Przykład usunięcia takich zbędnych ozdóbek. ~malarz pl ^PISZ 22:02, 2 cze 2011 (CEST)

Zmień proszę przykład bo przez rozsypany infoboks nie wiem co usunąłeś (domyslam się po kodzie, ale nie widzę). PMG (dyskusja) 16:59, 25 lut 2012 (CET)

Chodzi o coś takiego? ∼Wostr (dyskusja) 00:55, 28 lut 2012 (CET)

A symbol zabytku w Szablon:Zabytek infobox? Jestem cięty na takie cuda ale tam jest to chyba OK -- Bulwersator (dyskusja) 06:36, 3 mar 2012 (CET)

Raczej chodziło mi o wstawiane w różnych sytuacjach symbole odznaczeń, flagi itp w wywołaniach infoboksu w pierwszym nagłówku (nazwa, imię i nazwisko itp). Symbole wstawiane przez kod szablonu, na ogół przemyślane i przedyskutowane ({{zabytek infobox}}, {{klub sportowy infobox}}) IMO są ok. Problemem są te, które są w każdym wywołaniu szablonu wstawiane inaczej. Przykładu innego niż pierwotny nie jestem w stanie szybko podać. Wiem, że niedawno usunąłem flagi z jakiegoś piłkarza (były w infoboksie jeszcze wielokrotnie przy miejscu urodzenia i reprezentacjach, w których grał~). ~malarz pl ^PISZ 09:26, 3 mar 2012 (CET)

refy w infoboksach

Wszystkie refy (także te z infoboksu) powinny być rozwinięte na dole artykułu, a nie w dodatkowej sekcji "przypisy" w infoboksie. ~malarz pl ^PISZ 18:34, 5 cze 2011 (CEST)

A co z refami typu tych nt. aktualności danych w {{Piłkarz infobox}}? Trzymanie wszystkiego w jednym miejscu tutaj jest wg mnie wskazane, a wepchnięcie daty w sam nagłówek brzydko go powiększy. Wywalanie tego na dół całego artykułu mi się nie podoba, ew. można uniknąć "refowania" poprzez wstawienie tej notatki jako zwykły tekst pod odpowiednią sekcją infoboksu. Matma Rex dyskusja 15:38, 25 lut 2012 (CET)

W infoboksie w ogole nie powinno być przypisow. Infoboks jest jak naglowek - nie ma w nim informacji samodzielnych, lecz wyłącznie takie, które znajdują sie w głównym tekście, i tam sa uźródłowione przypisami. W koncu infoboks to nic innego jak tylko syntetyczne przedstawienie iformacji z artykulu. --Matrek (dyskusja) 22:24, 23 mar 2012 (CET)

{{{aktuaność}}} w infoboksie

W niektórych infoboksach wstawiane jest pole {{{aktualność}}} lub podobne, w którym wpisywana jest data aktualizacji. W części infoboksów dotyczących startujących sportowców/klubów są, w części nie ma. IMO należy to ujednolicić.

Z kolei przy nieżyjących informacje o ostatniej aktualizacji statystyk są raczej nie na miejscu. ~malarz pl ^PISZ 18:37, 5 cze 2011 (CEST)

W przypadku sportowców jest to potrzebne bo im się z każdym meczem zmienia (a czasem statystyki są sprzed roku a piłkarz gra w każdym meczu). Dlatego w niektórych przypadkach jest to potrzebne. Ale z kolei nie wiem co miałaby robić aktualizacja w żaglowcu z XV wieku albo państwie z XIII wieku. Dlatego nie wiem jak by to można było ujednolicić. PMG (dyskusja) 14:00, 6 maj 2012 (CEST)

mapa lokalizacyjna / geolokator

Trzeba ustalić zasady dla jakich obeiktów można umieszczać mapę lokalizacyjną i / lub współrzędne z linkiem do geolokatora. O ile nie ma wątpliwości z tymi danymi dla obiektów punktowych (budynek, plac, miejscowość) to problem jest z jednostkami administracyjnymi, które w określonych warunkach maga być wielkości Polski (np. Eparchia wrocławsko-gdańska). ~malarz pl ^PISZ 13:11, 9 cze 2011 (CEST)

Ja bym zdał się tu na rozsądek edytorów i w boksach, gdzie potencjalnie może być taki problem (np. administratury kościelnej) ustawiłbym koordynaty i mapkę jako parametry opcjonalne. Powerek38 (dyskusja) 10:00, 17 kwi 2012 (CEST)

ukrywanie

Proponowałbym wypracowanie zasad regulujących warunki w jakich można dodać w infoboksie ukrywane fragmenty lub ukrywanie całego infoboksu. ~malarz pl ^PISZ 22:09, 12 cze 2011 (CEST)

To mi się wydaje dość oczywiste - można (ale nie trzeba) ukrywać całości infoboksu, gdy w jednym artykule może być kilka infoboksów tego samego typu - jedyne przypadki, które przychodzą mi do głowy, to kolejne wersje samochodów w jednym artykule (np. Fiat Punto, Renault Clio) lub gry komputerowe z dodatkami w jednym art. (w tej chwili nie mam pod ręką ładnego przykładu). (Sam infobox, który ma potencjał do takiego wykorzystania, powinien obsługiwać ukrywanie, ale w art. nie musi być użyte.)

Ukrywać fragmenty infoboksu można (w sensie: infobox nie musi tego obsługiwać, jeśli nie miałoby to sensu; nie ma możliwości kontroli tego, czy przyciski pokaż/ukryj pokazują się w danym artykule) wtedy, gdy jego wysokość ze wszystkimi parametrami wypełnionymi (proponuję nie liczyć wymiarów grafiki i mapy lokalizacyjnej) przekracza, powiedzmy, 1000 pikseli (wartość do ustalenia, ale ta jest ładna i okrągła). Matma Rex dyskusja 15:51, 25 lut 2012 (CET)

opcjonalne parametry

Uważam, że wszystkie infoboks powinien być tak skonstruowany aby w wywołaniu występowały wszystkie wprost widoczne w infoboksie pola. Natomiast dodatkowe pola, które będą wykorzystywane bardzo rzadko (doprecyzować) mogą być sterowane nieobowiązkowym parametrem (np {{{parametr|}}}). ~malarz pl ^PISZ 07:34, 18 cze 2011 (CEST)

szerokość kolumn w infoboksie

Zastosowanie stałej (sztywnej) szerokości kolumny w infoboksie w niektórych sytuacjach doprowadza do jego zbędnego wydłużenia. Moim zdaniem należy tego unikać, w szczególności w przypadku długich infoboksów. ~malarz pl ^PISZ 08:26, 24 paź 2011 (CEST)

• Minimalne wydłużanie nie jest uciążliwe, tym bardziej, kiedy grupa tych parametrów jest „zwinięta” (Szablon:Świątynia chrześcijańska infobox), jak przesunięcia położenia wartości parametru względem nazwy parametru, przy zmiennej szerokości kolumny. Dla przykłady podaję: Kościół Zesłania Ducha Świętego w Krakowie.--Władysław Komorek (dyskusja) 10:40, 24 paź 2011 (CEST)

Mapa lokalizacyjna - parametr umieść=

Wartości parametru:

1. w tekście
2. na górze
3. w tekście i na górze

Pozwala na umieszczenie koordynatów w prawym górnym rogu artykułu lub pod mapą lokalizacyjną.

u góry

• Za – utrzymanie obecnego statusu jak na innych Wiki i wygoda
• Przeciw - przy używaniu co najmniej dwóch infoboksów z mapą lokalizacyjną, pokrywanie się wartości u góry artykułu

w tekście

• Za - zblokowanie parametrów i ich wartości, czyli podaje informacje z wartościami koordynatów, bezpośrednio pod mapą lokalizacyjną, która właśnie je generuje.
• Przeciw - informacja w postaci wartości koordynatów wydłuża infoboks, dubluje wartość „u góry”, zbyteczna, gdyż można osiągnąć ten sam rezultat linkują mapę lokalizacyjną do GeoHack w którym są podane te wartości.--Władysław Komorek (dyskusja) 19:44, 21 paź 2011 (CEST)

• Przede wszystkim nie zawsze jest tak że opisujemy dajmy na to jedno miejsce. Jeżeli walki toczyły się na morzu, to mogę podać dziesięć razy w tekście gdzie jakiś okręt zatopił statki, a później w jedenastym miejscu gdzie on sam został zatopiony. I ta ostatnia wartość powinna iść także na górę. Jeżeli podajemy koordynaty dajmy na to pomniku, to moim zdaniem powinno to być widoczne u góry. To standard na wszystkich wiki i myślę że nie ma co za dużo mieszać. Przykład Lista okrętów United States Navy zatopionych podczas II wojny światowej - opcja musi być i na tekst i na górę (jakiś pomnik). PMG (dyskusja) 17:08, 25 lut 2012 (CET)
  • PMG - tu chodzi o pojedyncze współrzędne podane w infoboksie dla mapy lokalizacyjnej. Nie dyskutujemy tu o niczym poza infoboksem. ~malarz pl ^PISZ 18:50, 25 lut 2012 (CET)
• Moim zdaniem koordynaty z linkiem do Geohacka w prawym górnym rogu są standardem, do którego ludzie się przyzwyczaili i który warto zachować, niezależnie od tego, czy w danym arcie koordynaty są wpisane w boks czy jako osobny szablon (chociaż generalnie tępiłbym i poprawiał sytuację, w której szablon {{współrzędne}} istnieje sobie w jednym arcie razem z boksem - z różnych względów lepiej go wtedy przekonwertować na parametry w boksie). Czy natomiast warto je dublować pod mapą - rzecz do dyskusji, mnie to nie przeszkadza, ale nie będę też tego za mocno bronił. Powerek38 (dyskusja) 10:04, 17 kwi 2012 (CEST)

Linkowanie mapy lokalizacyjnej

Linkowanie mapy lokalizacyjnej bezpośrednio do GeoHack.

• Za – pozwala, po kliknięciu na mapę lokalizacyjną, bezpośrednie (czyli bez potrzeby klikania na wartość koordynatów) otwarcie GeoHack z listą map.
• Przeciw – bez linkowania mapy lokalizacyjnej, pozwala na link do pliku z mapą a otwarcie GeoHack następuje po kliknięciu na wartość parametru koordynatów.--Władysław Komorek (dyskusja) 19:44, 21 paź 2011 (CEST)

Tu chyba nikogo nie będzie przeciw. W infoboksach, w których mapa lokalizacyjna powstaje na bazie {{mapa lokalizacyjna}} to działa. W pozostałych bazujących na {{mapa lokalizacyjna+}} niestety nie. Niestety te szablony trzeba istotnie poprawić i zintegrować. W wolnych chwilach nad tym pracuję, leż zadanie jest bardzo złożone. ~malarz pl ^PISZ 13:59, 25 lut 2012 (CET)

Dokładnie, sprawa jest raczej oczywista :) Powerek38 (dyskusja) 10:05, 17 kwi 2012 (CEST)

Linkowanie do commons

Proponuję ustalić iż linkujemy zawsze do kategorii, nie do galerii (galerie są zapuszczone, nieaktualizowane, ciężkie do użycia) itd -- Bulwersator (dyskusja) 09:56, 2 mar 2012 (CET)

Nie wiem czy jest to wykonalne. Można narzucić w kodzie infoboksu "Category:", ale co zrobić z dotychczasowymi wywołaniami tam gdzie jest odwołanie do galerii. Ale sugestia zdecydowanie słuszna. ~malarz pl ^PISZ 10:17, 2 mar 2012 (CET)

Cóż, można to załatwiać przy okazji przebotowywania (na przykład planuję to zrobić z rzekami) -- Bulwersator (dyskusja) 16:48, 2 mar 2012 (CET)

Według mnie konieczne jest linkowanie tylko i włącznie do kategorii commons. Sam zajmuję się poprawianiem tego faktu w infoboksach (zamiana z galerii na kategorię). Dotyczy to przede wszystkim artykułów o miastach - zauważyłem, że w przeszłości (gdy nie rozwinęły się jeszcze tak dokładne i obszerne kategorie i podkategorie commons) tworzono galerie commons miast zawierające czasem kilka, bądź kilkanaście zdjęć. I wywołanie do nich znajduje się w infoboksach wikipedii artykułów. Natomiast kategorie commons zawierają obecnie przejrzysty podział na dziedziny i posiadają w każdym przypadku o wiele więcej ilustracji niż sama galeria. Zatem wybór jest uzasadniony - bezprzecznie trafniejsze jest odwołanie do kategorii commons. --Lowdown (dyskusja) 10:26, 6 mar 2012 (CET)

W przypadku niektórych iboksów linkuje się do galerii, a galerie się aktualizuje i wybiera dobre jakościowo grafiki i/lub systematyzuje się w sekcjach szczegółowe informacje. Przykłady: commons:Pinus sylvestris, commons:Pinus strobus, commons:Whippet - to znacznie lepsze rozwiązanie niż commons:Category:Pinus sylvestris, commons:Category:Pinus strobus, commons:Category:Whippet. W dużych kategoriach na Commons jest mydło i powidło. Przykuta (dyskusja) 17:03, 5 kwi 2012 (CEST)

• ja bym tego nie ruszała - bo faktycznie raz będziemy potrzebować fachowo opisanej galerii, a innym razem kategorii - Beax 21:54, 19 cze 2012 (CEST)

infobox a liczba potencjalnych wywołań

Właśnie się zastanawiam, czy i kiedy tworzyć specjalistyczny infobox w miejsce ogólnego. sprawa dotyczy przede wszystkim jednostek administracyjnych i miejscowości. Np. czy tworzyć {{POL miasto infobox}} lub {{BRB parafia infobox}} zamiast używać {{Jednostka administracyjna infobox}}. IMO {{BRB parafia infobox}}, który na chwilę obecną może być użyteczny w maksymalnie 11 artykułach jest do zastąpienia uniwersalnym. Proponowałbym przyjęcia pewnych kryteriów, w przypadku wystąpienia których można utworzyć szablon dla specyficznej jednostki administracyjnej: potencjalna liczba wywołań infoboksu przynajmniej 100 lub konieczność zawarcia w infoboksie takich informacji, których umieszczenie w ogólnym byłoby bezcelowe. To jest oczywiście tylko wstępna propozycja. ~malarz pl ^PISZ 10:45, 11 cze 2012 (CEST)

Ja jestem za tym, aby w miarę możliwości tworzyć jak najmniej szablonów boksów dla konkretnych państw, one tylko komplikują pracę w przypadku różnych zmian technicznych, regeneracji itd. Chętnie zastąpiłbym większość tych szablonów zaczynających się od kodów państw boksami ogólnymi, byłoby dzięki temu prościej i bardziej przejrzyście. Powerek38 (dyskusja) 11:22, 11 cze 2012 (CEST)

Wiek

Kiedyś się nad tym zastanawialiśmy, ale temat umarł. Czy nie można by wprowadzić - wzorem en - podawania, a w zasadzie obliczania w infoboksach wieku osób żyjących ? Przykład: en:Salman bin Abdul-Aziz Al Saud - akurat na samym dole. Mnie się nigdy nie chce odejmować... - Beax 22:02, 19 cze 2012 (CEST)

To nie jest tylko kwestia infoboksów, ale wprowadzenia u nas szablonu typu en:template:birth date and age. Problem jest taki, że już był i wyleciał z hukiem w poczekalni (Wikipedia:Poczekalnia/kwestie techniczne/2011:02:06:Szablon:Data urodzenia wiek), były też chyba ze dwie dyskusje w kawiarence (na szybko znalazłem Wikipedia:Kawiarenka/Artykuły_dyskusja/Archiwum/2012-marzec#Szablon:Wiek_w_latach). Argumenty za i przeciw są tam podane, więc nie będę ich powtarzał.

Osobiście nie jestem zasadniczo przeciwko podawaniu wieku danej osoby przy dacie urodzenia, natomiast rzeczywiście kojarzy mi się to trochę z Faktem i plotkarskimi pismami dla pań domu. Jestem natomiast zasadniczo przeciwko wprowadzaniu w tym celu dodatkowych szablonów i utrudnianiu jeszcze bardziej edycji artykułów; ciężko mi powiedzieć, na ile praktyczne byłoby wprowadzenie jakiegoś rozwiązania w samych infoboksach; na pewno wymagałoby to podawania w nim dat w formacie typu "YYYY-MM-DD" lub innym standardowym. W każdym razie to jest temat do szerszego omówienia (jeśli się odważysz wsadzić kij w to mrowisko ;) ). Matma Rex dyskusja 22:20, 19 cze 2012 (CEST)

;-) OK - Beax 12:27, 20 cze 2012 (CEST)

Ja też nie mam nic przeciwko podawaniu wieku osób w infoboxach. Ale użycie ewentualnego szablonu do jego obliczania, jeśli by cichaczem wrócił, mimo, że z hukiem wyleciał, ograniczyłbym tylko do kodu szablonów infoboxów. Jeśli by podawać parametry "data urodzenia" i "data śmierci" w standardowy sposób, kod szablonu zrobi całą czarną robotę. Skoro temat powrócił, to należy rozważyć, czy pewna grupa szablonów biograficznych faktycznie go nie potrzebuje. Dotyczy to zwłaszcza haseł na temat aktorów i celebrytów. Każde hasło można przypisać do pewnej grupy odbiorców. Hasła o aktorach i celebrytach są najpewniej czytane przez czytelników Faktu lub innych tabloidów, a oni takich danych potrzebują i oczekują, stąd najpewniej często dochodzi w tych hasłach do edycji właśnie wieku. Wprowadzenie systemowego rozwiązania prezentacji wieku, być może zapobiegnie jałowym rewertowaniem zmian. W innych hasłach biograficznych (naukowiec, święty, zasłużony, żołnierz, itp. itd.) wieku można nie podawać. Do tego dochodzą kwestie techniczne. Teoretycznie wszystkie niezbędne dane do wyliczania wieku już są w wywołaniu szablonu. Ich odpowiednie ustandaryzowane wywołanie powinno automatycznie wstawić wiek osoby albo po dacie urodzenia (jeśli data śmierci nie jest podana), albo po dacie śmierci (jeśli obie daty urodzenia i śmierci są znane). Paweł Ziemian (dyskusja) 21:56, 25 cze 2012 (CEST)

Czasem jest wpisanych kilka wersji daty urodzenia lub śmierci (bo źródła nie są ze sobą zgodne) – takie "ustandaryzowane wywołanie" mogłoby utrudnić wpisywanie takich różnych niestandardowy danych. Pewnie dlatego na en wiki dodają do infoboksów ręcznie szablony dat/wieku. SpiderMum (dyskusja) 17:17, 26 cze 2012 (CEST)