Ten tekst opisuje w jaki sposób należy pisać artykuły dla wortalu jakilinux.org. Jest to zarazem przykład modelowego artykułu, jeśli chodzi o formatowanie tekstu XHTML, do którego należy się stosować albo przynajmniej do niego dążyć pisząc własne teksty.
Do kogo ten tekst?
Ten artykuł powinni przeczytać wszyscy, którzy mają w planach napisanie artykułu lub tłumaczenia dla naszego wortalu. Dostajemy coraz więcej artykułów, które mimo że poprawne merytorycznie, zupełnie nie nadają się do publikacji ze względu na formę, w jakiej zostały przesłane (np. dokument programu Libre/OpenOffice.org, plain text, czy też zupełnie dowolnie sformatowany dokument HTML). Oczywiście, jeśli teksty są naprawdę dobre, przerabiamy je na własną rękę, dostosowując do wymogów CMS-a i standardów przyjętych w wortalu. Zdecydowanie przyjemniej jednak pracowałoby się, gdyby wszyscy trzymali się jednej określonej formy. To nam oszczędzi pracy, a także skróci czas publikacji artykułu do minimum. Bardzo prosiłbym wszystkich zainteresowanych o zapoznanie się z tym tekstem i w miarę możliwości przestrzeganie zasad tutaj opisanych przy tworzeniu własnych artykułów.
Proces publikacji
Proces publikacji artykułu dla wortalu jest kilkustopniowy. Opiszemy tu kolejne kroki w telegraficznym skrócie.
- Autor dodaje w systemie CMS (rejestrując się w nim wcześniej) nowy szkic artykułu (menu Publikuj). Aby móc publikować szkice (brudnopisy) należy zgłosić się do sirmacika (więcej na stronie Kontakt).
- Następnie autor informuje jednego z redaktorów wortalu o opublikowanym szkicu (oczywiście dopiero w momencie, kiedy uważa artykuł za ukończony)
- Zaczyna się procedura weryfikacyjna polegająca na poddawaniu artykułu stopniowej korekcie. Najpierw artykuł przeglądany jest pod względem merytorycznym. Najczęściej zajmuje się tym gidgnulur lub sirmacik
- Jeśli artykuł przejdzie test merytoryczny, weryfikowany jest pod względem poprawności językowej i stylistycznej. Kolejni korektorzy są bardzo mile widziani!
- Na końcu, artykuł poprawiany jest pod względem poprawności składniowej (XHTML), o ile zachodzi taka potrzeba. Tym zajmuje się prawie zawsze gidgnulur. Jeśli przestrzegane będą przez Was zasady opisane poniżej, ten krok będzie w przyszłości jedynie formalnością :)
- Ostatecznie, artykuł jest klasyfikowany do odpowiedniej kategorii (jeśli autor tego nie zrobił) i publikowany
- Na autora spada szereg pochwał i inwektyw, rozpoczyna się flamewar, itd, itp, standardowa nagonka po publikacji kolejnego tekstu na wortalu :)
- Autor wpisuje sobie do CV kolejny udany tekst na temat GNU/Linuksa. Następnie zostaje zatrudniony przez znaną amerykańską korporację i wyrzeka się wszystkiego co napisał, zbijając kokosy na publikowaniu faktów o Linuksie :P
- Wszyscy żyją długo i szczęśliwie. Ewentualnie żyją szybko i umierają młodo, wedle upodobań.
Tak właśnie wygląda proces publikacji artykułu dla wortalu jakilinux.org. Jeśli jeszcze nie postanowiłeś zrezygnować, wybierz dla siebie odpowiedni temat albo zaproponuj nowy, bierz się do pracy i pisz!
Forma artykułu - krótki przewodnik po XHTML
Artykuły piszemy w formacie XHTML (w wersji 1.0 Transitional) i podstawowa znajomość tego formatu będzie konieczna do stworzenia poprawnego (czyli walidującego się) artykułu dla wortalu. Oczywiście nie potrzeba tworzyć całej poprawnej strony w XHTML. Wystarczy napisać część znajdującą się w elemencie <div> z atrybutem id="content". Nie będziemy w tym miejscu opisywać podstaw standardu XHTML. Można o tym poczytać na wielu stronach, m.in. na oficjalnej stronie W3C opisującej standard XHTML. Dla potrzeb naszego wortalu stworzone zostały style CSS dla wszystkich podstawowych elementów XHTML. Oznacza to, że w zdecydowanej większości przypadków, nie będziemy chcieli zawierać w artykułach żadnych styli inline. XHTML w artykule służy więc tylko i wyłącznie do określenia jego struktury. I tego należy się trzymać. Pokrótce omówmy więc podstawowe znaczniki XHTML, z jakich można i należy korzystać formatując artykuł.
- Element <h2> - w nim znajduje się temat artykułu. Jeśli dodajemy artykuł do CMS-a, tytuł wpisujemy po prostu w odpowiednim polu - nie jest on częścią tekstu.
- Element <h3> - nim oznaczamy nagłówki kolejnych akapitów. W zależności od artykułu może być od 2 do 10 takich elementów w tekście.
- Paragraf <p> - tym elementem oznaczamy wszystkie akapity. Oznacza to, że każdy tekst, który nie jest nagłówkiem, wypunktowaniem, bądź tabelą, powinien znaleźć się w paragrafie.
- Listy <ul> i <ol> - wszystkie wypunktowania w tekście zawieramy w listach. W zależności od rodzaju wypunktowania (z oznaczeniem kolejności, bądź z kolejnością dowolną) używamy odpowiedniego znacznika. Oczywiście każdą linię wypunktowania zawieramy w elemencie <li>. Listy można zagnieżdżać. Przykład zagnieżdżonej listy znajduje się m.in. na stronie Pomocy!
- Tabele <table> - tabele służą do prezentacji danych tabelarycznych (co dla wielu web-deweloperów nie jest tak oczywiste, jak by się mogło wydawać). Prawidłowo skonstruowana tabela powinna zawierać co najmniej elementy: <table>, <tbody>, <tr> i <td>. Kolumny z opisami oznaczamy przez <th>. Oczywiście rozmiary tabeli zależą od prezentowanych danych.
- Kod i polecenia <pre lang="wybrany_język"> - wszelkie wstawki w tekście będące listingami kodu lub kolejnymi poleceniami, jakie należy wykonać w konsoli, powinny być zawarte w elemencie <pre lang="wybrany_język">. Dla poleceń, nazw plików lub ich położenia znajdującego się w jednej linijce z tekstem stosujemy <code>.
- Grafika <img> - obrazki powinny mieć odpowiednią wielkość. Maksymalna szerokość obrazka (tak, aby nie wychodził poza kolumnę z tekstem) to 500px. Wysokość ograniczona jest jedynie zdrowym rozsądkiem. W przypadku obrazków zajmujących całą szerokość kolumny, wystarczy zawrzeć je w paragrafie <p>. Jeśli obrazek jest mniejszy (przy czym warto zamieszczać albo obrazki 400-500-pikselowe, albo mniejsze/równe niż 300px), należy paragrafowi zawierającemu obrazek nadać klasę img-right lub img-left - wtedy obrazek będzie ładnie owijał się wokół tekstu, z prawej lub lewej strony. Jeśli zamieszczamy screenshot całego ekranu lub większej aplikacji (czyli w większości przypadków), należy oprócz miniaturki obrazka, która pojawia się w tekście, przygotować oryginał, który powinien się pojawić po kliknięciu na obrazek. Dokonujemy tego, zawierając element <img> w elemencie <a href="" > (link). Każdy obrazek powinien również zawierać opis, zarówno standardowy (parametry alt i title, jak również dodatkowy opis (w atrybucie <em>), pojawiający się pod obrazkiem (ale w tym samym paragrafie). Możemy przesyłać pliki graficzne na serwer przy pomocy funkcji uploadu w CMS (dostępne z poziomu tworzenia artykułu). Lądują one standardowo w katalogu wp-content. Dodatkowo dopuszczalne jest korzystanie z hostingu obrazków imageshack lub lżejszy wstaw.org. W przypadku tego drugiego obowiązkowe jest przypisanie obrazkowi tagu jakilnux.
Poniżej przykładowy kod wstawiający mały obrazek, fruwający z prawej strony tekstu:
<p class="img-right"> <a href="/wp-content/JakisObrazek.png"><img src="/wp-content/JakisObrazek_Miniaturka.png" alt="Opis alternatywny obrazka" title="Tytuł obrazka (pojawia się po najechaniu myszą)"/></a> <br/><em>Rys 1. Przykładowy opis obrazka</em> </p>
- Linki - czyli odsyłacze do innych stron internetowych. Linków robimy dużo, ale z sensem. Jeśli piszemy o tunelu SSH, warto podać link do definicji takiego tunelu. Jeśli piszemy o jakimś projekcie, warto wskazać jego stronę domową. Bardzo dobrym źródłem informacji jest Wikipedia. Linki do niej są jak najbardziej wskazane.
- Wytłuszczenia <strong> - gdy chcemy coś podkreślić, np. istotne zdanie, kluczowe dla danego paragrafu, używamy tylko i wyłącznie elementu <strong>. Zapominamy o istnieniu czegoś takiego jak <b> - nie będzie nam to do niczego potrzebne.
- Tekst pochylony <em> - italikiem owijamy ksywy oraz wszelkie obcojęzyczne określenia, które nie mają swoich polskich odpowiedników, lub z jakiegoś innego powodu chcemy ich użyć jak np. focus, franchise, czy target. Ogólnie wolałbym, żeby trzymać się z daleka od tego rodzaju słów i pisać jak najbardziej po polsku. Zresztą, znając życie, jeden z naszych korektorów i tak wytnie w czasie korekty większość z takich naleciałości :)
- Rozwinięcie tekstu <!--more--> - po pierwszym, wprowadzającym akapicie każdego artykułu powinniśmy wstawić poniższy kod, który spowoduje wytłuszczenie go oraz wyświetli reklamę, która pomaga nam utrzymywać wortal:
<!-- more --><!--header--> <p class="img-right"><!--adsense--></p>
Walidacja XHTML
Serwis napisany jest w poprawnym XHTML, dlatego też bardzo istotne jest, aby żaden artykuł nie zawierał błędów w składni XHTML (o merytorycznych powodach dlaczego warto tworzyć poprawne strony internetowe nie będę się tutaj rozwodził - można poczytać m.in. na stronie Browse Happy. Poprawność składni XHTML możemy sprawdzić korzystając z programu sprawdzającego składnię. Programów takich jest wiele. Ja polecić mogę m.in. wtyczkę do Firefoksa o nazwie Tidy, która na bieżąco monitoruje błędy w edytowanym tekście. Dostępne jest też wiele konsolowych, graficznych i webowych narzędzi do tego samego celu. Już po publikacji, artykuł możemy zweryfikować używając narzędzia validator.w3.org. Warto to zrobić, ponieważ czasem Wordpress płata różnorakie figle dodając niepotrzebne znaki końca wiersza (<br />).
Korekta tekstu
Każdy tekst należy przed wysłaniem sprawdzić narzędziem sprawdzania pisowni. Jest ich wiele, często wbudowanych w aplikacje takie jak przeglądarki www, czy edytory tekstowe - michuk korzysta z aspell. Proste polecenie: aspell -c tekst.html odpala sprawdzanie pisowni dla pliku tekst.html. Poprawienie literówek i błędów ortograficznych przed wysłaniem tekstu jest bardzo istotne - w znaczny sposób skraca nam to pracę przy korekcie tekstu przed jego publikacją.