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 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.

1. 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 michuka (więcej na stronie Kontakt).
2. Następnie autor informuje jednego z redaktorów wortalu o opublikowanym szkicu (oczywiście dopiero w momencie, kiedy uważa artykuł za ukończony)
3. Zaczyna się procedura weryfikacyjna. Artykuł dodawany jest do repozytorium Subversion i poddawany stopniowej korekcie. Najpierw artykuł przeglądany jest pod względem merytorycznym. Najczęściej zajmuje się tym michuk lub t_ziel
4. Jeśli artykuł przejdzie test merytoryczny, weryfikowany jest pod względem poprawności językowej i stylistycznej. To domena Studenta i Thara. Kolejni korektorzy są jednak mile widziani!
5. Na końcu, artykuł poprawiany jest pod względem poprawności składniowej (XHTML), o ile zachodzi taka potrzeba. Tym zajmuje się prawie zawsze michuk. Jeśli przestrzegane będą przez Was zasady opisane poniżej, ten krok będzie w przyszłości jedynie formalnością
6. Ostatecznie, artykuł jest klasyfikowany do odpowiedniej kategorii (jeśli autor tego nie zrobił) i publikowany
7. Na autora spada szereg pochwał i inwektyw, rozpoczyna się flamewar, itd, itp, standardowa nagonka po publikacji kolejnego tekstu na wortalu
8. 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
9. 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 <code> - wszelkie wstawki w tekście będące listingami kodu lub kolejnymi poleceniami, jakie należy wykonać w konsoli, powinny być zawarte w elemencie <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ż 250px), 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 xhref="" mce_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). Poniżej przykładowy kod wstawiający mały obrazek, fruwający z prawej strony tekstu:
  
<p class="img-right"><a xhref="/wp-content/JakisObrazek.png" mce_href="/wp-content/JakisObrazek.png" ><img xsrc="/wp-content/JakisObrazek_Miniaturka.png" mce_src="/wp-content/JakisObrazek_Miniaturka.png" alt="Opis alternatywny obrazka" title="Tytuł obrazka (pojawia się po najechaniu myszą)"/></a><br/><i>Rys 1. Przykładowy opis obrazka</i></p>

  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.
• 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 <i> - 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, pazkooda i tak wytnie w czasie korekty większość z takich naleciałości

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 zwalidować używając narzędzia validator.w3.org. W szczególności ten artykuł możemy sprawdzić klikając tutaj. 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, ja korzystam 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ą.