From de5c456ebded0e038adbf23db34cc290c8829180 Mon Sep 17 00:00:00 2001 From: Florian Merz Date: Thu, 11 Feb 2021 14:49:24 +0100 Subject: unslug pl: move --- files/pl/mdn/at_ten/index.html | 43 ++ .../budowa_dany_edycja_artyku\305\202/index.html" | 66 --- .../howto/create_an_mdn_account/index.html | 41 -- .../howto/do_a_technical_review/index.html | 49 -- .../howto/set_the_summary_for_a_page/index.html | 50 -- .../howto/tag_javascript_pages/index.html | 75 --- files/pl/mdn/guidelines/style_guide/index.html | 556 --------------------- .../mdn/guidelines/writing_style_guide/index.html | 556 +++++++++++++++++++++ files/pl/mdn/kuma/index.html | 25 - files/pl/mdn/tools/index.html | 8 + files/pl/mdn/user_guide/index.html | 8 - files/pl/mdn/yari/index.html | 25 + 12 files changed, 632 insertions(+), 870 deletions(-) create mode 100644 files/pl/mdn/at_ten/index.html delete mode 100644 "files/pl/mdn/contribute/howto/budowa_dany_edycja_artyku\305\202/index.html" delete mode 100644 files/pl/mdn/contribute/howto/create_an_mdn_account/index.html delete mode 100644 files/pl/mdn/contribute/howto/do_a_technical_review/index.html delete mode 100644 files/pl/mdn/contribute/howto/set_the_summary_for_a_page/index.html delete mode 100644 files/pl/mdn/contribute/howto/tag_javascript_pages/index.html delete mode 100644 files/pl/mdn/guidelines/style_guide/index.html create mode 100644 files/pl/mdn/guidelines/writing_style_guide/index.html delete mode 100644 files/pl/mdn/kuma/index.html create mode 100644 files/pl/mdn/tools/index.html delete mode 100644 files/pl/mdn/user_guide/index.html create mode 100644 files/pl/mdn/yari/index.html (limited to 'files/pl/mdn') diff --git a/files/pl/mdn/at_ten/index.html b/files/pl/mdn/at_ten/index.html new file mode 100644 index 0000000000..c802ba1a07 --- /dev/null +++ b/files/pl/mdn/at_ten/index.html @@ -0,0 +1,43 @@ +--- +title: 10 lat MDN +slug: dziesiec_lat_mdn +tags: + - História + - Internet + - MDN + - Mozilla + - Społeczność +translation_of: MDN_at_ten +--- + + +
+
+

Historia MDN

+ +

Na początku 2005 roku mały zespół idealistów postanowił stworzyć nowe, darmowe, prowadzone przez społeczność źródło zasobów dla wszystkich Web developerów. Ich genialny ale niecodzienny pomysł przerodził się w dzisiejsze Mozilla Developer Network — główne źródło zasobów dla otwartych technologii Internetowych. Po dziesięciu latach nasza globalna społeczność jest większa niż kiedykolwiek i nadal wspólnie tworzymy dokumentacje, próbki kodu i materiały szkoleniowe dla wszystkich otwartych technologii włączając w to CSS, HTML, JavaScript i wszystkich innych, które sprawiają, że otwarty Internet jest tak potężny jak teraz.

+ +

Dowiedz się więcej about the history

+ + +

Pomóż rozwijać MDN

+ +

Przez dziesięć lat społeczność MDN zajmowała się dokumentowaniem otwartego Internetu. Od poprawiania literówek po dokumentowanie nowych API. Każdy ma coś do zaoferowania, żaden wkład nie jest zbyt mały ani zbyt duży. Posiadamy ponad 90,000 stron treści które zostały napisane i przetłumaczone przez członków wybitnej społeczności Mozillianów. Ty też możesz stać się jednym z nich.

+ +

Dowiedz się więcej about contributing

+ +

 

+ +

 

+
+ +
{{TenthCampaignQuote}}
+ +

Nawigacja

+ +
    +
  1. 10 lat MDN
    2. +
  2. Historia MDN
    3. +
  3. Pomóż rozwijać MDN
    4. +
+
diff --git "a/files/pl/mdn/contribute/howto/budowa_dany_edycja_artyku\305\202/index.html" "b/files/pl/mdn/contribute/howto/budowa_dany_edycja_artyku\305\202/index.html" deleted file mode 100644 index 5c7876a4b7..0000000000 --- "a/files/pl/mdn/contribute/howto/budowa_dany_edycja_artyku\305\202/index.html" +++ /dev/null @@ -1,66 +0,0 @@ ---- -title: 'Jak budować, edytować dany artykuł' -slug: MDN/Contribute/Howto/Budowa_dany_edycja_artykuł -tags: - - Dokumentacja - - Edycja artykułu - - Przewodnik - - Publikaja artykułu - - Wprowadzanie zmian - - Wprowadzanie zmian w hasłach -translation_of: MDN/Contribute/Howto/Do_an_editorial_review ---- -

{{MDNSidebar}}

- -

{{IncludeSubnav("/en-US/docs/MDN")}}

- -

Edycja budowanego artykułu sklada sie z:

- -

naprawy składni , poprawy błędów ortograficznych,
- interpunkcyjnych zawartych w tekście, który powinien być łatwy do zrozumienia. Osoba redagująca tekst nie musi być pisarzem aby pomoc w tworzeniu dokumentacji technicznej MDN's, która zawsze jest otwarta na potrzeby udoskonalania dla przyszłych czytelników danego artykułu.

- -

Ten przewodnik opisuje jak dokonać przeglądu edytorskiego, co ma zapewnić, że zawartość witryny MDN jest odpowiednio napisana i zredagowana.

- -
-
Na czym polega to zadanie?
-
Edycja i korekta artykułów oznaczonych jako wymagające przeglądu redakcyjnego.
-
Gdzie należy to zrobić?
-
W obrębie konkretnych artykułów oznaczonych jako wymagające przeglądu redakcyjnego.
-
Co potrzebujesz aby dobrze wykonać to zadanie?
-
Musisz znać gramatykę i styl języka. Przegląd redakcyjny polega na zapewnieniu poprawnej gramatyki i stylistyki, braku literówek, użyciu właściwych terminów technicznych, zgodnie ze standardem podanym w Przewodniku tworzenia zasobów MDN.
-
W jakich krokach to osiągnąć?
-
-
    -
  1. Wybierz artykuł wymagający przejrzenia: -
      -
    1. Idź do listy artykułów wymagających oceny redakcji. Gdzie zobaczysz listę stron, które wymagają poprawek edytora.
      2. -
    2. Kliknij w tytuł artykułu, by załadować stronę.
      - Uwaga: Lista artykułów przeznaczonych do edycji jest generowana automatycznie i odświeżana jest rzadko, dlatego część artykułów, nie będzie wymagała żadnych zmian, ponieważ była już przetłumaczona i sprawdzona. Jeśli artykuł nie wyświetla informacji "Ten artykuł wymaga przeglądu redakcyjnego", możesz pominąć jego edycję i wybrać inny artykuł.
      3. -
    -
    2. -
  2. Każdy artykuł czytaj uważnie, zwracając uwagę na literówki, ortografię, gramatykę lub błędy użytkowania. Jeśli strona, którą wybrałeś - nie pasuje ci - nie wahaj przełączać się między stronami podczas edycji,
    3. -
  3. Jeśli strona artykułu nie posiada błędów, nie ma potrzeby, by edytować artykuł, żeby oznaczyć go jako sprawdzony. Spójrz na okienko wyboru "Wymaga sprawdzenia" w lewym pasku nawigacyjnym poniżej artykułu:
    4. -

  4. - Screenshot of the editorial review request sidebar box
    5. -
  5. Odznacz opcję Editorial i zapisz, klikając Save.
    6. -
  6. Jeśli znajdziesz błędy wymagające korekty: -
      -
    1. Kliknij guzik Edit znajdujący się na górze strony; zostaniesz przeniesiony na stronę MDN edytor.
      2. -
    2. Popraw wszystkie literówki, będy ortograficzne i gramatyczne i inne błędy, które uda ci się znaleźć. Jeśli do końca nie jesteś pewny, czy edycja artykułu została przez ciebie skończona,  upewnij się, że zostawiasz prośbę o dalszy przegląd redakcyjny włączoną.
      3. -
    3. Wprowadź Komentarz dotyczący sprawdzenia  na dole artykułu; np. Nick edytora: 'poprawione błędy ortograficzne, gramatyczne i składniowe'. Pomoże to innym użytkownikom i autorom edytowanej strony dowiedzieć się, które hasło wymagało zmian i dlaczego takie zmiany były wprowadzane.
      4. -
    4. Odznacz w polu 
      - Wymaga sprawdzenia > Redakcjynego. Znajdującego się powyżej sekcji Komentarz dotyczący sprawdzenia.
      5. -
    5. Kliknij guzik Publikuj.
      6. -
    -
    7. -
- - -
-
- -
-
-
Zapisane zmiany wprowadzone do artykułu, mogą pojawić się z opóźnieniem.
-
-
diff --git a/files/pl/mdn/contribute/howto/create_an_mdn_account/index.html b/files/pl/mdn/contribute/howto/create_an_mdn_account/index.html deleted file mode 100644 index ed988c32bc..0000000000 --- a/files/pl/mdn/contribute/howto/create_an_mdn_account/index.html +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: Jak utworzyć konto MDN -slug: MDN/Contribute/Howto/Create_an_MDN_account -tags: - - Beginner - - Guide - - MDN - - nowy - - pierwsze kroki - - podręcznik - - zacznij -translation_of: MDN/Contribute/Howto/Create_an_MDN_account ---- -
{{MDNSidebar}}

Wstęp współdworz MDN, sửa các thay đổi và các trang cần thiết là MDN. Profil does not we expected, unwatched MDN i useful załeych tu information. Ten krótkie poradnik Ci Successful Accounts MDN.

- -
Tại sao MDN lại cần email?
-
-Email của bạn cho phép khôi phục các tài khoản, cũng như các vấn đề quản trị MDN, để kết hợp với Tobą trong phần mềm hoặc thông tin.
-
-Opcjonalnie możesz Tez otrzymywać powiadomienia (na przykład w wypadku zmian na interesującej CIE Stronie ) oraz wiadomości (przykładowo, jeśli zdecydujesz sie dołączyć làm naszego zespołu beta testerów, możesz otrzymywać Maile dotyczące nowych funkcji wymagających przetestowania).
-
-Your email adres is offline na MDN i using us with the groups .
- -
    -
  1. Na górze tất cả các trang web MDN nút "Đăng Sắp za Uy tín". Najedź na nút (hoặc bấm, nếu bạn sử dụng điện thoại di động). Rozwiniesz w ten way list uwierzytelinally serwisów, using a MDN.
    2. -
  2. Choose availing Ci service, to be used to MDn. Wybranie (Tùy chọn " Persona ") có thể được sử dụng trong hai trang chính.
    3. -
  3. Postęp các theo dõi của nó, để cho các tài khoản dự phòng với MDM profilem.
    4. -
  4. Po powrocie do MDN bị bỏ qua poproszony và podanie địa chỉ email cũng như chọn lựa đặt người dùng. Tên người có thể nhìn thấy rõ ràng. Nigdy không sử dụng email địa chỉ email khi đặt mục tiêu!
    5. -
  5. Then click button " Wykonaj ".
    6. -
  6. Podane podany w punkcie 4 không phải là lý do tại sao, việc sử dụng để đăng nhập vào trang chủ, bạn cần skrzynkę mailową. W otrzymanych từ nas mailu nhấn vào nút " Potwierdź konto " trong việc hướng tới việc đăng nhập.
    7. -
- -

Để tất cả! Posiadasz các tài khoản và MD5 của bạn.

- -

Na górze tất cả các trang MDN có thể là người dùng của bạn. Click it, to make your profile. Teraz możesz wybrać opcję " Edytuj ", aby uzupełnić swój Profil, dzielić sie z innymi użytkownikami informacjami o Tobie, dodawać linki làm swojego Twittera lub bloga ITD.

- -
-

Chú ý: Không thể phân biệt người dùng có ký hiệu "@". Pamiętaj, as Bạn có thể chứng tỏ được rằng mình là một trong những người hiểu rõ nhất về dịch vụ của bạn.

-
- -

 

diff --git a/files/pl/mdn/contribute/howto/do_a_technical_review/index.html b/files/pl/mdn/contribute/howto/do_a_technical_review/index.html deleted file mode 100644 index 624ea0dc0d..0000000000 --- a/files/pl/mdn/contribute/howto/do_a_technical_review/index.html +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: How to do a technical review -slug: MDN/Contribute/Howto/Do_a_technical_review -translation_of: MDN/Contribute/Howto/Do_a_technical_review ---- -
{{MDNSidebar}}

Technical review consists of reviewing the technical accuracy and completeness of an article, and correcting it if necessary. If a writer of an article wants someone else to check the technical content of an article, the writer ticks the "Technical review" checkbox while editing. Often the writer contacts a specific engineer to perform the technical review, but anyone with technical expertise in the topic can do one.

- -

This article describes how to go about performing a technical review, thereby helping to ensure that MDN's content is accurate.

- -
-
What is the task?
-
Reviewing and correcting of articles for technical accuracy and completeness.
-
Where does it need to be done?
-
In specific articles that are marked as requiring a technical review.
-
What do you need to know to do the task?
-
-
    -
  • Expert knowledge of the topic of the article you are reviewing.
    • -
  • Ability to edit a wiki article on MDN.
    • -
-
-
What are the steps to do it?
-
-
    -
  1. Pick an article to review: -
      -
    1. Go to the list of pages that need technical reviews. This lists all the pages for which an technical review has been requested.
      2. -
    2. Choose a page whose topic you are very familiar with.
      3. -
    3. Click on the article link to load the page.
      4. -
    -
    2. -
  2. Read the article, paying close attention to technical details: Is the article correct? Is there anything missing? Don't hesitate to switch to a different page if the first one you choose doesn't suit you.
    3. -
  3. If there are no errors, you don't need to edit the article to mark it as reviewed. Look for the "quick review" box in the left sidebar of the page. This yellow box lists any pending reviews and lets you clear their review request flag. It looks like this if a technical review has been requested:
    - Screenshot of the sidebar's box listing reviews that have been requested and allowing the flags to be changed.
    4. -
  4. Deselect the Technical checkbox, and click Save.
    5. -
  5. If you find errors that need to be corrected, you'll be glad to know that you can also change the review request status from within the editor. Here's the workflow: -
      -
    1. To edit the page, click the Edit button near the top of the page; this puts you into the MDN editor.
      2. -
    2. Fix any technical information is not correct, and/or add any important information that is missing.
      3. -
    3. Enter a Revision Comment at the bottom of the article. This is a brief message that describes what you did, like 'Technical review completed.' If you corrected information, include that in your comment, for example 'Technical review and fixed parameter descriptions.' This helps other contributors and site editors know what you changed and why.
      4. -
    4. Deselect the Technical box under Review Needed? just below the Revision Comment area of the page.
      5. -
    5. Click the PUBLISH button.
      6. -
    -
    6. -
- -

Congratulations! You've finished your first technical review! Thank you for your help!

-
-
diff --git a/files/pl/mdn/contribute/howto/set_the_summary_for_a_page/index.html b/files/pl/mdn/contribute/howto/set_the_summary_for_a_page/index.html deleted file mode 100644 index e3c2632242..0000000000 --- a/files/pl/mdn/contribute/howto/set_the_summary_for_a_page/index.html +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: How to set the summary for a page -slug: MDN/Contribute/Howto/Set_the_summary_for_a_page -translation_of: MDN/Contribute/Howto/Set_the_summary_for_a_page ---- -
{{MDNSidebar}}

Możesz opracować streszczenie strony MDN. Twoje streszczenie zostanie potem wykorzystane w wielu miejscach: w wynikach wyszukiwania, na innych stronach MDN, takich jak np. strony tematyczne, oraz w dymkach z podpowiedziami. Twój tekst powinien być zrozumiały zarówno jako fragment oryginalnej strony, jak i wtedy, gdy zostanie wyrwany z kontekstu i wyświetlony samodzielnie na innej stronie.

-

Każda strona może mieć zdefiniowane streszczenie. Jeśli jednak go nie ma, streszczenie jest tworzone automatycznie na podstawie pierwszych paru zdań tekstu. Niestety to nie zawsze jest najlepszy wybór.

- - - - - - - - - - - - - - - - - - - -
Na czym polega zadanie?Zadanie polega na zaznaczaniu takiego fragmentu tekstu na stronie, który mógłby posłużyć jako streszczenie strony do wykorzystania w innych kontekstach. Może się zdarzyć, że trzeba będzie ten tekst napisać.
Gdzie możesz to zrobić?Na stronach, które nie mają streszczenia lub pozostawia ono wiele do życzenia.
Jakich umiejętności potrzebujesz?Umiejętność obsługi edytora MDN; umiejętność pisania tekstów; na tyle biegła znajomość omawianych tematów, żeby napisać sensowne streszczenie.
What are the steps to do it? -
    -
  1. Pick a page on which to set the summary: -
      -
    1. In the MDN documentation status page, click the link under Sections for a topic that you know something about (for example, HTML):
      -
      2. -
    2. On the topic's documentation status page, click the Pages header in the Summary table. This takes you to an index of all the pages in that topic section; it shows the page links in the left column, and the tags and summaries in the right column:
      -
      3. -
    3. Pick a page that is missing a summary, or that has a poor summary:
      -
      4. -
    4. Click the link to go to that page.
      5. -
    -
    2. -
  2. Click Edit to open the page in the MDN editor.
    3. -
  3. Look for a sentence or two that works as a summary out of context. If needed, edit the existing content to create or modify sentences to be a good summary.
    4. -
  4. Select the text to be used as a summary.
    5. -
  5. In the Styles widget of the editor toolbar, select SEO Summary. (In the page source, this creates a {{HTMLElement("span")}} element with class="seoSummary" around the selected text.)
    -
    6. -
  6. Save your changes with a revision comment like "Set the page summary."
    7. -
-
-

 

-

 

-

 

diff --git a/files/pl/mdn/contribute/howto/tag_javascript_pages/index.html b/files/pl/mdn/contribute/howto/tag_javascript_pages/index.html deleted file mode 100644 index 4d0f8b785f..0000000000 --- a/files/pl/mdn/contribute/howto/tag_javascript_pages/index.html +++ /dev/null @@ -1,75 +0,0 @@ ---- -title: How to tag JavaScript pages -slug: MDN/Contribute/Howto/Tag_JavaScript_pages -tags: - - JavaScript - - MDN - - Poradnik -translation_of: MDN/Contribute/Howto/Tag_JavaScript_pages ---- -
{{MDNSidebar}}
- -

Tagowanie opiera się na dodawaniu meta-danych do stron, tak aby powiązane ze sobą treści mogły być grupowane - przykładowo na potrzeby wyszukiwania.

- -
-
Gdzie jest to potrzebne?
-
Na konkretnych stronach związanych z JavaScriptem, na których jeszcze nie ma tagów
-
Co musisz wiedzieć, aby wykonać tą czynność?
-
Podstawowa wiedza o programowaniu w JavaScripcie - przykładowo wiedzieć, czym jest metoda lub właściwość obiektu.
-
Jakie są kroki?
-
-
    -
  1. Wyberz jedną ze stron z listy w odnośniku powyżej
    2. -
  2. Kliknij na odnośniku do artykułu, aby załadować jego stronę.
    3. -
  3. Gdy strona się załaduje, kliknij przycisk EDYTUJ, zlokalizowany nad artykułem; uruchomiony zostanie edytor MDN.
    4. -
  4. Przynajmniej tag JavaScript powinien być dodany. Oto inne przykładowe tagi, które mogą być dodane: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    TagNa jakich stronach użyć
    Methodmetody
    Propertywłaściwości
    prototypeprototypy
    Nazwa typu obiektumetody danego obiektu; przykładowo metoda String.fromCharCode powinna mieć tag String
    ECMAScript6 i Experimentalfunkcjonalności dodane w nowych wersjach ECMAScript
    Deprecatedprzestarzałe funkcjonalności (wciąż są wspierane, ale nie zaleca się ich używania)
    Obsoletewycofane funkcjonalności (nie są już wspierane przez współczesne przeglądarki)
    inneZobacz artykuł Standardy tagowania MDN aby przejrzeć inne tagi, które można dodać
    -
    5. -
  5. Zapisz wraz z komentarzem.
    6. -
  6. Zrobione!
    7. -
-
-
- -

 

diff --git a/files/pl/mdn/guidelines/style_guide/index.html b/files/pl/mdn/guidelines/style_guide/index.html deleted file mode 100644 index 370bd6714e..0000000000 --- a/files/pl/mdn/guidelines/style_guide/index.html +++ /dev/null @@ -1,556 +0,0 @@ ---- -title: Przewodnik po stylach dokumentacji MDN -slug: MDN/Guidelines/Style_guide -tags: - - Dokumentacja - - Dokumenty MDN - - Przewodnik - - Przewodnik stylu MDN - - Style w MDN -translation_of: MDN/Guidelines/Writing_style_guide ---- -
{{MDNSidebar}}
- -

W celu wyświetlenia dokumentacji w zorganizowany, znormalizowany i łatwy do odczytania sposób, przewodnik stylu Mozilla Developer Network opisuje, w jaki sposób tekst powinien być zorganizowany, zapisany, sformatowany i tak dalej. Są to wytyczne, a nie surowe zasady. Jesteśmy bardziej zainteresowani treścią niż formatowaniem, nie jesteś zobowiązany do uczenia się całego przewodnika po stylach MDN przed wniesieniem wkładu. Nie bądź jednak zdenerwowany lub zaskoczony, jeśli inny tłumacz zmodyfikuje w późniejszym czasie edytowany przez ciebie artykuł, aby dostosować się go, do głównych wytycznych stawianych dokumnetacji MDN.

- -

Jeśli szukasz informacji jak dany typ strony powinien być ustrukturyzowany, zobacz poradnik dotyczący układu stron MDN

- -

Aspekty językowe tego przewodnika dotyczą przede wszystkim dokumentacji w języku angielskim. Inne kraje mogą mieć (i mogą tworzyć) przewodniki po stylach we własnym języku. Tłumaczenia takie powinny być opublikowane jako podstrony, na lokalnych stronach MDN, dedykowanych dla danego języka przez zespół zajmujący się tłumaczeniami tzw. zespół lokalizacyjny.

- -

Zapoznaj się ze standardami styli stosowanych do treści witryn innych niż MDN, zobacz Przewodnik po stylach One Mozilla.

- -

Podstawy

- -

Tytuły stron

- -

Tytuły stron używane są w wynikach wyszukiwania, dzięki temu łatwiej jest znaleźć stronę w wynikach organicznych wyszukiwarek. Tytuły służą również do zachowania odpowiedniej struktury strony. Dlatego wraz z menu okruszkowym lub inaczej okruszkami(z ang. breadcrumbs)  umieszczane są na górze strony, w celu zachowania odpowiedniej jej hierarchii. Tytuł,  wyświetlany na górze w oknie przeglądarki, może różnić się od tzw. slug'a, który jest elemnetem adresu URL, następującym po "<locale>/docs/".

- -

Tytuł i wielkie litery(kapitaliki)

- -

Tytuły stron i nagłówki sekcji(H1-H6) powinny być formatowane w taki sam sposób jak zdania. Wielka litera powinna być pisana na początku pierwszego słowa, również powinna wystąpić w nazwach własnych. Powinieneś unikać słów pisanych tzw. pismem wielbłądzim(które w anglojęzycznych krajach jest stosowane w tytułach): 

- - - -

Mamy wiele starszych stron, które zostały napisane przed ustanowieniem tej reguły stylu. Jeśli chcesz, możesz je aktualizować w razie potrzeby. Stopniowo do nich docieramy.

- -

Choosing titles and slugs

- -

Page slugs should be kept short; when creating a new level of hierarchy, the new level's component in the slug should generally just be a word or two.

- -

Page titles, on the other hand, may be as long as you like, within reason, and they should be descriptive.

- -

Creating new subtrees

- -

When you need to add a number of articles about a topic or topic area, you will typically do so by creating a landing page, then adding subpages for each of the individual articles. The landing page should open with a paragraph or two describing the topic or technology, then provide a list of the subpages with descriptions of each page. You can automate the insertion of pages into the list using a number of macros we've created.

- -

For example, consider the JavaScript guide, which is structured like this:

- - - -

Try to avoid putting your article at the top of the hierarchy, which slows the site down and makes search and site navigation less effective.

- -

Sections, paragraphs, and newlines

- -

Use heading levels in decreasing order: {{HTMLElement("h2")}} then {{HTMLElement("h3")}} then {{HTMLElement("h4")}}, without skipping levels. H2 is the highest level allowed because H1 is reserved for the page title. If you need more than three or four levels of headers you should consider breaking up the article into several smaller articles with a landing page, linking them together using the {{TemplateLink("Next")}}, {{TemplateLink("Previous")}}, and {{TemplateLink("PreviousNext")}} macros.

- -

The enter (or return) key on your keyboard starts a new paragraph. To insert a newline without a space, hold down the shift key while pressing enter.

- -

Text formatting and styles

- -

Use the "Formatting Styles" drop-down list to apply predefined styles to selected content.

- -
Note: The "Note" style is used to call out important notes, like this one.
- -
Warning: Similarly, the "Warning" style creates warning boxes like this.
- -

Unless specifically instructed to do so, do not use the HTML style attribute to manually style content. If you can't do it using a predefined class, drop into {{IRCLink("mdn")}} and ask for help.

- -

Code sample style and formatting

- -

Tabs and line breaks

- -

Use two spaces per tab in all code samples. Code should be indented cleanly, with open-brace ("{") characters on the same line as the statement that opens the block. For example:

- -
if (condition) {
-  /* handle the condition */
-} else {
-  /* handle the "else" case */
-}
-
- -

Long lines shouldn't be allowed to stretch off horizontally to the extent that they require horizontal scrolling to read. Instead, break at natural breaking points. Some examples follow:

- -
if (class.CONDITION || class.OTHER_CONDITION || class.SOME_OTHER_CONDITION
-       || class.YET_ANOTHER_CONDITION ) {
-  /* something */
-}
-
-var toolkitProfileService = Components.classes["@mozilla.org/toolkit/profile-service;1"]
-                           .createInstance(Components.interfaces.nsIToolkitProfileService);
-
- -

Inline code formatting

- -

Use the "Code" button (labeled with two angle brackets "<>") to apply inline code-style formatting to function names, variable names, and method names (this uses the {{HTMLElement("code")}} element). For example, "the frenchText() function".

- -

Method names should be followed by a pair of parentheses: doSomethingUseful(). This helps to differentiate methods from other code terms.

- -

Syntax highlighting

- -

Screenshot of the "syntax highlighting" menu.Entire lines (or multiple lines) of code should be formatted using syntax highlighting rather than the {{HTMLElement("code")}} element. Click the "pre" button in the toolbar to create the preformatted content box in which you'll then write your code. Then, with the text entry cursor inside the code box, select the appropriate language from the language list button to the right of the "pre" button, as seen in the screenshot to the right. The following example shows text with JavaScript formatting:

- -
-
for (var i = 0, j = 9; i <= 9; i++, j--)
-  document.writeln("a[" + i + "][" + j + "]= " + a[i][j]);
-
- -

If no appropriate transformation is available, use the pre tag without specifying a language ("No Highlight" in the language menu).

- -
x = 42;
- -

Styling HTML element references

- -

There are various specific rules to follow when writing about HTML elements, in order to consistently describe the various components of elements, and to ensure that they're properly linked to detailed documentation.

- -
-
Element names
-
Use the {{TemplateLink("HTMLElement")}} macro, which creates a link to the page for that element. For example, writing \{{HTMLElement("title")}} produces "{{HTMLElement("title")}}". If you don't want to create a link, enclose the name in angle brackets and use "Code (inline)" style (e.g., <title>).
-
Attribute names
-
Use bold face.
-
Attribute definitions
-
Use the {{TemplateLink("htmlattrdef")}} macro (e.g., \{{htmlattrdef("type")}}) for the definition term, so that it can be linked to from other pages, then use the {{TemplateLink("htmlattrxref")}} macro (e.g., \{{htmlattrxref("attr","element")}}) to reference attribute definitions.
-
Attribute values
-
Use "Code (inline)" style, and do not use quotation marks around strings, unless needed by the syntax of a code sample. E.g.: When the type attribute of an <input> element is set to email or tel ...
-
Labeling attributes
-
Use labels like {{HTMLVersionInline(5)}} thoughtfully. For example, use them next to the bold attribute name but not for every occurrence in your body text.
-
- -

Latin abbreviations

- -

In notes and parentheses

- - - -

In running text

- - - -

Meanings and English equivalents of Latin abbreviations

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
AbbrevLatinEnglish
cf.confercompare
e.g.exempli gratiafor example
et al.et aliiand others
etc.et ceteraand so forth, and so on
i.e.id estthat is, in other words
N.B.nota benenote well
P.S.post scriptumpostscript
- -
-

Note: Always consider whether it's truly beneficial to use a Latin abbreviation. Some of these are used so rarely that many readers won't understand the meaning, and others are often confused with one another. And be sure that you use them correctly, if you choose to do so. For example, be careful not to confuse "e.g." with "i.e.", which is a common error.

-
- -

Acronyms and abbreviations

- -

Capitalization and periods

- -

Use full capitals and delete periods in all acronyms and abbreviations, including organizations such as "US" and "UN".

- - - -

Expansion

- -

On the first mention of a term on a page, expand acronyms likely to be unfamiliar to users. When in doubt, expand it, or, better, link it to the article or glossary entry describing the technology.

- - - -

Plurals of acronyms and abbreviations

- -

For plurals of acronyms or abbreviations, add s. Don't use an apostrophe. Ever. Please.

- - - -

Capitalization

- -

Use standard English capitalization rules in body text, and capitalize "World Wide Web" and "Web".

- -

Contractions

- -

Use contractions (e.g. "don't", "can't", "shouldn't") if you prefer. We're not that formal!

- -

Pluralization

- -

Use English-style plurals, not the Latin- or Greek-influenced forms.

- - - -

Hyphenation

- -

Hyphenate compounds when the last letter of the prefix is a vowel and is the same as the first letter of the root.

- - - -

Gender-neutral language

- -

It is a good idea to use gender-neutral language in any kind of writing where gender is irrelevant to the subject matter, to make the text as inclusive as possible. So for example, if you are talking about the actions of a specific man, usage of he/his would be fine, but if the subject is a person of either gender, he/his isn't really appropriate.
-
- Let's take the following example:

- -
-

A confirmation dialog appears, asking the user if he allows the web page to make use of his web cam.

-
- -
-

A confirmation dialog appears, asking the user if she allows the web page to make use of her web cam.

-
- -

Both versions in this case are gender-specific. This could be fixed by using gender-neutral pronouns:

- -
-

A confirmation dialog appears, asking the user if they allow the web page to make use of their web cam.

-
- -
-

Note: MDN allows the use of this very common syntax (which is controversial among usage authorities), in order to make up for the lack of a neutral gender in English. The use of the third-person plural as a neutral gender pronoun (that is, using "they," them", "their," and "theirs") is an accepted practice, commonly known as "singular 'they.'"

-
- -

You can use both genders:

- -
-

A confirmation dialog appears, asking the user if he or she allows the web page to make use of his/her web cam.

-
- -

making the users plural:

- -
-

A confirmation dialog appears, asking the users if they allow the web page to make use of their web cams.

-
- -

The best solution, of course, is to rewrite and eliminate the pronouns completely:

- -
-

A confirmation dialog appears, requesting the user's permission for web cam access.

-
- -
-

A confirmation dialog box appears, which asks the user for permission to use the web cam.

-
- -

The last way of dealing with the problem is arguably better, as it is not only grammatically more correct but removes some of the complexity associated with dealing with genders across different languages that may have wildly varying gender rules. This can make translation easier, both for readers reading English, then translating it into their own language as they read, and for localizers translating articles into their own language.

- -

Numbers and numerals

- -

Dates

- -

For dates (not including dates in code samples) use the format "January 1, 1990".

- - - -

Alternately, you can use the YYYY/MM/DD format.

- - - -

Decades

- -

For decades, use the format "1990s". Don't use an apostrophe.

- - - -

Plurals of numerals

- -

For plurals of numerals add "s". Don't use an apostrophe.

- - - -

Commas

- -

In running text, use commas only in five-digit and larger numbers.

- - - -

Punctuation

- -

Serial comma

- -

Use the serial comma. The serial (also known as "Oxford") comma is the comma that appears before the conjunction in a series of three or more items.

- - - -
-

Note: This is in contrast to the One Mozilla style guide, which specifies that the serial comma is not to be used. MDN is an exception to this rule.

-
- -

Spelling

- -

For words with variant spellings, always use the first entry at Answers.com. Do not use variant spellings.

- - - -

Terminology

- -

Obsolete vs. deprecated

- -

It's important to be clear on the difference between the terms obsolete and deprecated.

- -
-
Obsolete:
-
On MDN, the term obsolete marks an API or technology that is not only no longer recommended, but also no longer implemented in the browser. For Mozilla-specific technologies, the API is no longer implemented in Mozilla code; for Web standard technology, the API or feature is no longer supported by current, commonly-used browsers.
-
Deprecated:
-
On MDN, the term deprecated marks an API or technology that is no longer recommended, but is still implemented and may still work. These technologies will in theory eventually become obsolete and be removed, so you should stop using them. For Mozilla-specific technologies, the API is still supported in Mozilla code; for Web standard technology, the API or feature has been removed or replaced in a recent version of the defining standard.
-
- -

HTML elements

- -

Use "elements" to refer to HTML and XML elements, rather than "tags". In addition, they should almost always be wrapped in "<>", and should be in the {{HTMLElement("code")}} style. Also, at least the first time you reference a given element in a section should use the {{TemplateLink("HTMLElement")}} macro, to create a link to the documentation for the element (unless you're writing within that element's reference document page).

- - - -

User interface actions

- -

In task sequences, describe user interface actions using the imperative mood. Identify the user interface element by its label and type.

- - - -

Voice

- -

While the active voice is generally preferred, the passive voice is also acceptable, given the informal feel of our content. Try to be consistent, though.

- -

Wiki markup and usage

- - - -

To automatically create a link to a Bugzilla bug, use this template:

- -
\{{Bug(322603)}}
-
- -

This results in:

- -

{{Bug(322603)}}

- -

For WebKit bugs, you can use this template:

- -
\{{Webkitbug("322603")}}
-
- -

This results in:

- -

{{Webkitbug("322603")}}

- -

Page tags

- -

Tags provide meta information about a page and/or indicate that a page has specific improvements needed to its content. Every page in the wiki should have tags. You can find details on tagging in our How to properly tag pages guide.

- -

The tagging interface lives at the bottom of a page while you're in edit mode, and looks something like this:

- -

Screenshot of the UX for adding and removing tags on MDN

- -

To add a tag, click in the edit box at the end of the tag list and type the tag name you wish to add. Tags will autocomplete as you type. Press enter (or return) to submit the new tag. Each article may have as many tags as needed. For example, an article about using JavaScript in AJAX programming might have both "JavaScript" and "AJAX" as tags.

- -

To remove a tag, simply click the little "X" icon in the tag.

- -

Tagging pages that need work

- -

In addition to using tags to track information about the documentation's quality and content, we also use them to mark articles as needing specific types of work.

- -

Tagging obsolete pages

- -

Use the following tags for pages that are not current:

- - - -

SEO summary

- -

The SEO summary is a very short summary of the page. It will be reported as a summary of the article to robots crawling the site, and will then appear in search results for the page. It is also used by macros that automate the construction of landing pages inside MDN itself.

- -

By default, the first pagragraph of the page is used as the SEO summary. However you can override this behavior by marking a section with the "SEO summary" style in the WYSIWYG editor.

- -

Landing pages

- -

Landing pages are pages at the root of a topic area of the site, such as the main CSS or HTML pages. They have a standard format that consists of three areas:

- -
    -
  1. A brief (typically one paragraph) overview of what the technology is and what it's used for. See {{anch("Writing a landing page overview")}} for tips.
    2. -
  2. A two-column list of links with appropriate headings. See {{anch("Creating a page link list")}} for guidelines.
    3. -
  3. An optional "Browser compatibility" section at the bottom of the page.
    4. -
- -

Creating a page link list

- -

The link list section of an MDN landing page consists of two columns. These are created using the following HTML:

- -
<div class="row topicpage-table">
-  <div class="section">
-    ... left column contents ...
-  </div>
-  <div class="section">
-    ... right column contents ...
-  </div>
-</div>
- -

The left-hand column should be a list of articles, with an <h2> header at the top of the left column explaining that it's a list of articles about the topic (for example "Documentation and tutorials about foo"); this header should use the CSS class "Documentation". Below that is a <dl> list of articles, with each article's link in a <dt> block and a brief one-or-two sentence summary of the article in the corresponding <dd> block.

- -

The right-hand column should contain one or more of the following sections, in order:

- -
-
Getting help from the community
-
This should provide information on Matrix chat rooms and mailing lists available about the topic. The heading should use the class "Community".
-
Tools
-
A list of tools the user can look at to help with the use of the technology described in this section of MDN. The heading should use the class "Tools".
-
Related topics
-
A list of links to landing pages for other, related, technologies of relevance. The heading should use the class "Related_Topics".
-
- -

<<<finish this once we finalize the landing page standards>>>

- -

Using, inserting images

- -

It's sometimes helpful to provide an image in an article you create or modify, especially if the article is very technical. To include an image:

- -
    -
  1. Attach the desired image file to the article (at the bottom of every article in edit mode)
    2. -
  2. Create an image in the WYSIWYG editor
    3. -
  3. In the WYSIWYG editor in the drop-down list listing attachments, select the newly created attachment which is your image
    4. -
  4. Press OK.
    5. -
- -

Other References

- -

Preferred style guides

- -

If you have questions about usage and style not covered here, we recommend referring to the Economist style guide or, failing that, the Chicago Manual of Style.

- -

Preferred dictionary

- -

For questions of spelling, please refer to Answers.com. The spell-checker for this site uses American English. Please do not use variant spellings (e.g., use honor rather than honour).

- -

We will be expanding the guide over time, so if you have specific questions that aren't covered in this document, please send them to the MDC mailing list or project lead so we know what should be added.

- -

MDN-specific

- - - -

Language, grammar, spelling

- -

If you're interested in improving your writing and editing skills, you may find the following resources to be helpful.

- - diff --git a/files/pl/mdn/guidelines/writing_style_guide/index.html b/files/pl/mdn/guidelines/writing_style_guide/index.html new file mode 100644 index 0000000000..370bd6714e --- /dev/null +++ b/files/pl/mdn/guidelines/writing_style_guide/index.html @@ -0,0 +1,556 @@ +--- +title: Przewodnik po stylach dokumentacji MDN +slug: MDN/Guidelines/Style_guide +tags: + - Dokumentacja + - Dokumenty MDN + - Przewodnik + - Przewodnik stylu MDN + - Style w MDN +translation_of: MDN/Guidelines/Writing_style_guide +--- +
{{MDNSidebar}}
+ +

W celu wyświetlenia dokumentacji w zorganizowany, znormalizowany i łatwy do odczytania sposób, przewodnik stylu Mozilla Developer Network opisuje, w jaki sposób tekst powinien być zorganizowany, zapisany, sformatowany i tak dalej. Są to wytyczne, a nie surowe zasady. Jesteśmy bardziej zainteresowani treścią niż formatowaniem, nie jesteś zobowiązany do uczenia się całego przewodnika po stylach MDN przed wniesieniem wkładu. Nie bądź jednak zdenerwowany lub zaskoczony, jeśli inny tłumacz zmodyfikuje w późniejszym czasie edytowany przez ciebie artykuł, aby dostosować się go, do głównych wytycznych stawianych dokumnetacji MDN.

+ +

Jeśli szukasz informacji jak dany typ strony powinien być ustrukturyzowany, zobacz poradnik dotyczący układu stron MDN

+ +

Aspekty językowe tego przewodnika dotyczą przede wszystkim dokumentacji w języku angielskim. Inne kraje mogą mieć (i mogą tworzyć) przewodniki po stylach we własnym języku. Tłumaczenia takie powinny być opublikowane jako podstrony, na lokalnych stronach MDN, dedykowanych dla danego języka przez zespół zajmujący się tłumaczeniami tzw. zespół lokalizacyjny.

+ +

Zapoznaj się ze standardami styli stosowanych do treści witryn innych niż MDN, zobacz Przewodnik po stylach One Mozilla.

+ +

Podstawy

+ +

Tytuły stron

+ +

Tytuły stron używane są w wynikach wyszukiwania, dzięki temu łatwiej jest znaleźć stronę w wynikach organicznych wyszukiwarek. Tytuły służą również do zachowania odpowiedniej struktury strony. Dlatego wraz z menu okruszkowym lub inaczej okruszkami(z ang. breadcrumbs)  umieszczane są na górze strony, w celu zachowania odpowiedniej jej hierarchii. Tytuł,  wyświetlany na górze w oknie przeglądarki, może różnić się od tzw. slug'a, który jest elemnetem adresu URL, następującym po "<locale>/docs/".

+ +

Tytuł i wielkie litery(kapitaliki)

+ +

Tytuły stron i nagłówki sekcji(H1-H6) powinny być formatowane w taki sam sposób jak zdania. Wielka litera powinna być pisana na początku pierwszego słowa, również powinna wystąpić w nazwach własnych. Powinieneś unikać słów pisanych tzw. pismem wielbłądzim(które w anglojęzycznych krajach jest stosowane w tytułach): 

+ + + +

Mamy wiele starszych stron, które zostały napisane przed ustanowieniem tej reguły stylu. Jeśli chcesz, możesz je aktualizować w razie potrzeby. Stopniowo do nich docieramy.

+ +

Choosing titles and slugs

+ +

Page slugs should be kept short; when creating a new level of hierarchy, the new level's component in the slug should generally just be a word or two.

+ +

Page titles, on the other hand, may be as long as you like, within reason, and they should be descriptive.

+ +

Creating new subtrees

+ +

When you need to add a number of articles about a topic or topic area, you will typically do so by creating a landing page, then adding subpages for each of the individual articles. The landing page should open with a paragraph or two describing the topic or technology, then provide a list of the subpages with descriptions of each page. You can automate the insertion of pages into the list using a number of macros we've created.

+ +

For example, consider the JavaScript guide, which is structured like this:

+ + + +

Try to avoid putting your article at the top of the hierarchy, which slows the site down and makes search and site navigation less effective.

+ +

Sections, paragraphs, and newlines

+ +

Use heading levels in decreasing order: {{HTMLElement("h2")}} then {{HTMLElement("h3")}} then {{HTMLElement("h4")}}, without skipping levels. H2 is the highest level allowed because H1 is reserved for the page title. If you need more than three or four levels of headers you should consider breaking up the article into several smaller articles with a landing page, linking them together using the {{TemplateLink("Next")}}, {{TemplateLink("Previous")}}, and {{TemplateLink("PreviousNext")}} macros.

+ +

The enter (or return) key on your keyboard starts a new paragraph. To insert a newline without a space, hold down the shift key while pressing enter.

+ +

Text formatting and styles

+ +

Use the "Formatting Styles" drop-down list to apply predefined styles to selected content.

+ +
Note: The "Note" style is used to call out important notes, like this one.
+ +
Warning: Similarly, the "Warning" style creates warning boxes like this.
+ +

Unless specifically instructed to do so, do not use the HTML style attribute to manually style content. If you can't do it using a predefined class, drop into {{IRCLink("mdn")}} and ask for help.

+ +

Code sample style and formatting

+ +

Tabs and line breaks

+ +

Use two spaces per tab in all code samples. Code should be indented cleanly, with open-brace ("{") characters on the same line as the statement that opens the block. For example:

+ +
if (condition) {
+  /* handle the condition */
+} else {
+  /* handle the "else" case */
+}
+
+ +

Long lines shouldn't be allowed to stretch off horizontally to the extent that they require horizontal scrolling to read. Instead, break at natural breaking points. Some examples follow:

+ +
if (class.CONDITION || class.OTHER_CONDITION || class.SOME_OTHER_CONDITION
+       || class.YET_ANOTHER_CONDITION ) {
+  /* something */
+}
+
+var toolkitProfileService = Components.classes["@mozilla.org/toolkit/profile-service;1"]
+                           .createInstance(Components.interfaces.nsIToolkitProfileService);
+
+ +

Inline code formatting

+ +

Use the "Code" button (labeled with two angle brackets "<>") to apply inline code-style formatting to function names, variable names, and method names (this uses the {{HTMLElement("code")}} element). For example, "the frenchText() function".

+ +

Method names should be followed by a pair of parentheses: doSomethingUseful(). This helps to differentiate methods from other code terms.

+ +

Syntax highlighting

+ +

Screenshot of the "syntax highlighting" menu.Entire lines (or multiple lines) of code should be formatted using syntax highlighting rather than the {{HTMLElement("code")}} element. Click the "pre" button in the toolbar to create the preformatted content box in which you'll then write your code. Then, with the text entry cursor inside the code box, select the appropriate language from the language list button to the right of the "pre" button, as seen in the screenshot to the right. The following example shows text with JavaScript formatting:

+ +
+
for (var i = 0, j = 9; i <= 9; i++, j--)
+  document.writeln("a[" + i + "][" + j + "]= " + a[i][j]);
+
+ +

If no appropriate transformation is available, use the pre tag without specifying a language ("No Highlight" in the language menu).

+ +
x = 42;
+ +

Styling HTML element references

+ +

There are various specific rules to follow when writing about HTML elements, in order to consistently describe the various components of elements, and to ensure that they're properly linked to detailed documentation.

+ +
+
Element names
+
Use the {{TemplateLink("HTMLElement")}} macro, which creates a link to the page for that element. For example, writing \{{HTMLElement("title")}} produces "{{HTMLElement("title")}}". If you don't want to create a link, enclose the name in angle brackets and use "Code (inline)" style (e.g., <title>).
+
Attribute names
+
Use bold face.
+
Attribute definitions
+
Use the {{TemplateLink("htmlattrdef")}} macro (e.g., \{{htmlattrdef("type")}}) for the definition term, so that it can be linked to from other pages, then use the {{TemplateLink("htmlattrxref")}} macro (e.g., \{{htmlattrxref("attr","element")}}) to reference attribute definitions.
+
Attribute values
+
Use "Code (inline)" style, and do not use quotation marks around strings, unless needed by the syntax of a code sample. E.g.: When the type attribute of an <input> element is set to email or tel ...
+
Labeling attributes
+
Use labels like {{HTMLVersionInline(5)}} thoughtfully. For example, use them next to the bold attribute name but not for every occurrence in your body text.
+
+ +

Latin abbreviations

+ +

In notes and parentheses

+ + + +

In running text

+ + + +

Meanings and English equivalents of Latin abbreviations

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
AbbrevLatinEnglish
cf.confercompare
e.g.exempli gratiafor example
et al.et aliiand others
etc.et ceteraand so forth, and so on
i.e.id estthat is, in other words
N.B.nota benenote well
P.S.post scriptumpostscript
+ +
+

Note: Always consider whether it's truly beneficial to use a Latin abbreviation. Some of these are used so rarely that many readers won't understand the meaning, and others are often confused with one another. And be sure that you use them correctly, if you choose to do so. For example, be careful not to confuse "e.g." with "i.e.", which is a common error.

+
+ +

Acronyms and abbreviations

+ +

Capitalization and periods

+ +

Use full capitals and delete periods in all acronyms and abbreviations, including organizations such as "US" and "UN".

+ + + +

Expansion

+ +

On the first mention of a term on a page, expand acronyms likely to be unfamiliar to users. When in doubt, expand it, or, better, link it to the article or glossary entry describing the technology.

+ + + +

Plurals of acronyms and abbreviations

+ +

For plurals of acronyms or abbreviations, add s. Don't use an apostrophe. Ever. Please.

+ + + +

Capitalization

+ +

Use standard English capitalization rules in body text, and capitalize "World Wide Web" and "Web".

+ +

Contractions

+ +

Use contractions (e.g. "don't", "can't", "shouldn't") if you prefer. We're not that formal!

+ +

Pluralization

+ +

Use English-style plurals, not the Latin- or Greek-influenced forms.

+ + + +

Hyphenation

+ +

Hyphenate compounds when the last letter of the prefix is a vowel and is the same as the first letter of the root.

+ + + +

Gender-neutral language

+ +

It is a good idea to use gender-neutral language in any kind of writing where gender is irrelevant to the subject matter, to make the text as inclusive as possible. So for example, if you are talking about the actions of a specific man, usage of he/his would be fine, but if the subject is a person of either gender, he/his isn't really appropriate.
+
+ Let's take the following example:

+ +
+

A confirmation dialog appears, asking the user if he allows the web page to make use of his web cam.

+
+ +
+

A confirmation dialog appears, asking the user if she allows the web page to make use of her web cam.

+
+ +

Both versions in this case are gender-specific. This could be fixed by using gender-neutral pronouns:

+ +
+

A confirmation dialog appears, asking the user if they allow the web page to make use of their web cam.

+
+ +
+

Note: MDN allows the use of this very common syntax (which is controversial among usage authorities), in order to make up for the lack of a neutral gender in English. The use of the third-person plural as a neutral gender pronoun (that is, using "they," them", "their," and "theirs") is an accepted practice, commonly known as "singular 'they.'"

+
+ +

You can use both genders:

+ +
+

A confirmation dialog appears, asking the user if he or she allows the web page to make use of his/her web cam.

+
+ +

making the users plural:

+ +
+

A confirmation dialog appears, asking the users if they allow the web page to make use of their web cams.

+
+ +

The best solution, of course, is to rewrite and eliminate the pronouns completely:

+ +
+

A confirmation dialog appears, requesting the user's permission for web cam access.

+
+ +
+

A confirmation dialog box appears, which asks the user for permission to use the web cam.

+
+ +

The last way of dealing with the problem is arguably better, as it is not only grammatically more correct but removes some of the complexity associated with dealing with genders across different languages that may have wildly varying gender rules. This can make translation easier, both for readers reading English, then translating it into their own language as they read, and for localizers translating articles into their own language.

+ +

Numbers and numerals

+ +

Dates

+ +

For dates (not including dates in code samples) use the format "January 1, 1990".

+ + + +

Alternately, you can use the YYYY/MM/DD format.

+ + + +

Decades

+ +

For decades, use the format "1990s". Don't use an apostrophe.

+ + + +

Plurals of numerals

+ +

For plurals of numerals add "s". Don't use an apostrophe.

+ + + +

Commas

+ +

In running text, use commas only in five-digit and larger numbers.

+ + + +

Punctuation

+ +

Serial comma

+ +

Use the serial comma. The serial (also known as "Oxford") comma is the comma that appears before the conjunction in a series of three or more items.

+ + + +
+

Note: This is in contrast to the One Mozilla style guide, which specifies that the serial comma is not to be used. MDN is an exception to this rule.

+
+ +

Spelling

+ +

For words with variant spellings, always use the first entry at Answers.com. Do not use variant spellings.

+ + + +

Terminology

+ +

Obsolete vs. deprecated

+ +

It's important to be clear on the difference between the terms obsolete and deprecated.

+ +
+
Obsolete:
+
On MDN, the term obsolete marks an API or technology that is not only no longer recommended, but also no longer implemented in the browser. For Mozilla-specific technologies, the API is no longer implemented in Mozilla code; for Web standard technology, the API or feature is no longer supported by current, commonly-used browsers.
+
Deprecated:
+
On MDN, the term deprecated marks an API or technology that is no longer recommended, but is still implemented and may still work. These technologies will in theory eventually become obsolete and be removed, so you should stop using them. For Mozilla-specific technologies, the API is still supported in Mozilla code; for Web standard technology, the API or feature has been removed or replaced in a recent version of the defining standard.
+
+ +

HTML elements

+ +

Use "elements" to refer to HTML and XML elements, rather than "tags". In addition, they should almost always be wrapped in "<>", and should be in the {{HTMLElement("code")}} style. Also, at least the first time you reference a given element in a section should use the {{TemplateLink("HTMLElement")}} macro, to create a link to the documentation for the element (unless you're writing within that element's reference document page).

+ + + +

User interface actions

+ +

In task sequences, describe user interface actions using the imperative mood. Identify the user interface element by its label and type.

+ + + +

Voice

+ +

While the active voice is generally preferred, the passive voice is also acceptable, given the informal feel of our content. Try to be consistent, though.

+ +

Wiki markup and usage

+ + + +

To automatically create a link to a Bugzilla bug, use this template:

+ +
\{{Bug(322603)}}
+
+ +

This results in:

+ +

{{Bug(322603)}}

+ +

For WebKit bugs, you can use this template:

+ +
\{{Webkitbug("322603")}}
+
+ +

This results in:

+ +

{{Webkitbug("322603")}}

+ +

Page tags

+ +

Tags provide meta information about a page and/or indicate that a page has specific improvements needed to its content. Every page in the wiki should have tags. You can find details on tagging in our How to properly tag pages guide.

+ +

The tagging interface lives at the bottom of a page while you're in edit mode, and looks something like this:

+ +

Screenshot of the UX for adding and removing tags on MDN

+ +

To add a tag, click in the edit box at the end of the tag list and type the tag name you wish to add. Tags will autocomplete as you type. Press enter (or return) to submit the new tag. Each article may have as many tags as needed. For example, an article about using JavaScript in AJAX programming might have both "JavaScript" and "AJAX" as tags.

+ +

To remove a tag, simply click the little "X" icon in the tag.

+ +

Tagging pages that need work

+ +

In addition to using tags to track information about the documentation's quality and content, we also use them to mark articles as needing specific types of work.

+ +

Tagging obsolete pages

+ +

Use the following tags for pages that are not current:

+ + + +

SEO summary

+ +

The SEO summary is a very short summary of the page. It will be reported as a summary of the article to robots crawling the site, and will then appear in search results for the page. It is also used by macros that automate the construction of landing pages inside MDN itself.

+ +

By default, the first pagragraph of the page is used as the SEO summary. However you can override this behavior by marking a section with the "SEO summary" style in the WYSIWYG editor.

+ +

Landing pages

+ +

Landing pages are pages at the root of a topic area of the site, such as the main CSS or HTML pages. They have a standard format that consists of three areas:

+ +
    +
  1. A brief (typically one paragraph) overview of what the technology is and what it's used for. See {{anch("Writing a landing page overview")}} for tips.
    2. +
  2. A two-column list of links with appropriate headings. See {{anch("Creating a page link list")}} for guidelines.
    3. +
  3. An optional "Browser compatibility" section at the bottom of the page.
    4. +
+ +

Creating a page link list

+ +

The link list section of an MDN landing page consists of two columns. These are created using the following HTML:

+ +
<div class="row topicpage-table">
+  <div class="section">
+    ... left column contents ...
+  </div>
+  <div class="section">
+    ... right column contents ...
+  </div>
+</div>
+ +

The left-hand column should be a list of articles, with an <h2> header at the top of the left column explaining that it's a list of articles about the topic (for example "Documentation and tutorials about foo"); this header should use the CSS class "Documentation". Below that is a <dl> list of articles, with each article's link in a <dt> block and a brief one-or-two sentence summary of the article in the corresponding <dd> block.

+ +

The right-hand column should contain one or more of the following sections, in order:

+ +
+
Getting help from the community
+
This should provide information on Matrix chat rooms and mailing lists available about the topic. The heading should use the class "Community".
+
Tools
+
A list of tools the user can look at to help with the use of the technology described in this section of MDN. The heading should use the class "Tools".
+
Related topics
+
A list of links to landing pages for other, related, technologies of relevance. The heading should use the class "Related_Topics".
+
+ +

<<<finish this once we finalize the landing page standards>>>

+ +

Using, inserting images

+ +

It's sometimes helpful to provide an image in an article you create or modify, especially if the article is very technical. To include an image:

+ +
    +
  1. Attach the desired image file to the article (at the bottom of every article in edit mode)
    2. +
  2. Create an image in the WYSIWYG editor
    3. +
  3. In the WYSIWYG editor in the drop-down list listing attachments, select the newly created attachment which is your image
    4. +
  4. Press OK.
    5. +
+ +

Other References

+ +

Preferred style guides

+ +

If you have questions about usage and style not covered here, we recommend referring to the Economist style guide or, failing that, the Chicago Manual of Style.

+ +

Preferred dictionary

+ +

For questions of spelling, please refer to Answers.com. The spell-checker for this site uses American English. Please do not use variant spellings (e.g., use honor rather than honour).

+ +

We will be expanding the guide over time, so if you have specific questions that aren't covered in this document, please send them to the MDC mailing list or project lead so we know what should be added.

+ +

MDN-specific

+ + + +

Language, grammar, spelling

+ +

If you're interested in improving your writing and editing skills, you may find the following resources to be helpful.

+ + diff --git a/files/pl/mdn/kuma/index.html b/files/pl/mdn/kuma/index.html deleted file mode 100644 index 6c2be0c158..0000000000 --- a/files/pl/mdn/kuma/index.html +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: 'Kuma: MDN''s wiki platform' -slug: MDN/Kuma -tags: - - Kuma - - MDN Meta -translation_of: MDN/Kuma ---- -
{{MDNSidebar}}
- -
{{IncludeSubnav("/en-US/docs/MDN")}}
- -

Kuma jest kodem Django, który zasila MDN Web Docs.

- -

{{SubpagesWithSummaries}}

- -

Zaangażuj się Kuma

- -

Aby zaangażować się w Kuma:

- - diff --git a/files/pl/mdn/tools/index.html b/files/pl/mdn/tools/index.html new file mode 100644 index 0000000000..fd60142577 --- /dev/null +++ b/files/pl/mdn/tools/index.html @@ -0,0 +1,8 @@ +--- +title: MDN user guide +slug: MDN/User_guide +translation_of: MDN/Tools +translation_of_original: MDN/User_guide +--- +
{{MDNSidebar}}

The Mozilla Developer Network site is an advanced system for finding, reading, and contributing to documentation and sample code for Web developers (as well as for Firefox and Firefox OS developers). The MDN user guide provides articles detailing how to use MDN to find the documentation you need, and, if you wish, how to help make the material better, more expansive, and more complete.

+<> diff --git a/files/pl/mdn/user_guide/index.html b/files/pl/mdn/user_guide/index.html deleted file mode 100644 index fd60142577..0000000000 --- a/files/pl/mdn/user_guide/index.html +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: MDN user guide -slug: MDN/User_guide -translation_of: MDN/Tools -translation_of_original: MDN/User_guide ---- -
{{MDNSidebar}}

The Mozilla Developer Network site is an advanced system for finding, reading, and contributing to documentation and sample code for Web developers (as well as for Firefox and Firefox OS developers). The MDN user guide provides articles detailing how to use MDN to find the documentation you need, and, if you wish, how to help make the material better, more expansive, and more complete.

-<> diff --git a/files/pl/mdn/yari/index.html b/files/pl/mdn/yari/index.html new file mode 100644 index 0000000000..6c2be0c158 --- /dev/null +++ b/files/pl/mdn/yari/index.html @@ -0,0 +1,25 @@ +--- +title: 'Kuma: MDN''s wiki platform' +slug: MDN/Kuma +tags: + - Kuma + - MDN Meta +translation_of: MDN/Kuma +--- +
{{MDNSidebar}}
+ +
{{IncludeSubnav("/en-US/docs/MDN")}}
+ +

Kuma jest kodem Django, który zasila MDN Web Docs.

+ +

{{SubpagesWithSummaries}}

+ +

Zaangażuj się Kuma

+ +

Aby zaangażować się w Kuma:

+ + -- cgit v1.2.3-54-g00ecf