Rozwijanie SpongeDocs

Dokumentacja Sponge, zwana również „SpongeDocs” jest oficjalną dokumentacją projektu Sponge. Celem SpongeDocs jest:

  • Pomoc użytkownikom w przygotowaniu ich własnych serwerów opartych na implementacji Sponge.

  • Dostarczenie deweloperom informacji w jaki sposób mogą przyczynić się do rozwoju projektu Sponge.

  • Dostarczanie deweloperom informacji jak rozpocząć tworzenie własnych pluginów.

Zgłaszanie problemów

It may always occur that a page gets outdated, an error sneaks in or you just look at a page and think „Well, there is a better way of explaining this.” If that is the case and you are for some reason not able to provide a fix yourself, there are four ways of making us aware of the problem:

  1. Tworzenie Zgłoszenie na SpongeDocs GitHub

  2. Stworzenie Wątku na Kategoria Forum SpongeDocs

  3. Odwiedź nasz kanał #spongedocs na irc.esper.net (musisz być zarejestrowany)

  4. Visit us on our Discord Server, namely the #docs channel.

Pisanie dokumentów

Zmiany i uzupełnienia do SpongeDocs powinny być wysyłane jako Pull Request do repozytorium SpongeDocs na GitHub. Nie wymagamy perfekcji od przesyłanych dokumentów, zawsze można delikatnie poprawić w procesie przeglądu. Niekompletne wyjaśnienia są również mile widziane, jeśli istnieją pewne części, których nie rozumiesz. Zawsze będzie ktoś, kto może wypełnić luki.

The Docs are written in reStructuredText (reST), if you’re familiar with Markdown (md) the step to reST shouldn’t be too hard. If you’re having issues with it we suggest that you join our #spongedocs on irc.esper.net and ask for help there, or join our Discord Server and post on the #docs channel. Discord and IRC are linked, so you’ll get the same support irrespective of the platform you choose. Alternatively, you can post on our forums if you think it is more apropriate.

The Sponge Documentation is licensed under the Creative Commons - Share-Alike license. Art assets are held under the related Creative Commons - Non Commercial, No Derivatives license. Contributors implicitly accept this licensing.

Estetyka Pisania

Aby upewnić się, że mamy wspólny format na wszystkich stronach SpongeDocs, tutaj znajdują się wskazówki, które stworzyliśmy do pisania dokumentacji Sponge. Ta lista może się zwiększyć (lub zmniejszyć) gdy dokumenty Sponge staną się większe.

  1. Nagłówki Powinny Być Napisane Wielką Literą (<– przykład)

  2. Nagłówki stron powinny być sensowne (nagłówek pojawi się jako link).

  3. Program code should be contained in inline literals or code blocks.

  1. Staraj się nie umieszczać zbyt dużo tekstu w blokach kodowych, ponieważ nie mogą być tłumaczone. Współtwórcy są zniechęceni do zmiany z bloków kodowych na krótkie teksty. Proste symbole zastępcze mogą być konieczne w niektórych przykładach. Idealny przykład w bloku kodowy będzie krótki, a następnie wyjaśniony w tekście. Oczywiście mogą istnieć pewne pojęcia, które nie mogą być ilustrowane przez krótki przykład.

  2. Use the following code block types for particular code blocks:

  • Groovy/Gradle-Files -> groovy

  • Hocon-Config -> guess (hocon highlighting is not yet supported)

  • In-Game/Server Console Command -> none

  • Java-Code -> java

  • Json-Config -> json

  • Linux-Terminal -> bash

  • Logs -> none

  • Text -> text

  • Windows-Console -> bat

  1. Zachowaj odrębne obszary dla Użytkowników, Twórców Pluginów i Deweloperów Sponge.

  2. Należy unikać powtarzania, poprzez zapożyczanie stron, gdy jest to możliwe.

  3. Twórz łącze do zasobów zewnętrznych, zamiast ich przepisywać.

  1. Niektóre wyjątki, są tworzone do celów tłumaczeń.

  1. Twórz rozróżnienia między SpongeForge, SpongeVanilla i SpongeAPI.

  2. Jeżeli wygląda to okropnie w twoim języku, stwórz własne zasady.

  3. Sponge jest nazwą projektu i NIE powinno być tłumaczone.

  1. Niektóre języki mogą chcieć skorzystać także z tłumaczenia fonetycznego.

  1. Automated translations (e.g. Google Translate) are strongly discouraged. These often contain serious errors, and are very likely to be rejected.

  2. Tytuły i nagłówki sekcji powinne być zwykłym tekstem, unikaj bloków liter i innych formatowań.

  3. Code symbols should be capitalized in their original form and have no extra spaces (e.g. blockState (a field name) or BlockState (a class name), rather than block state). They should also be formatted as a literal using double backticks (e.g. blockState) in body text.

  4. Linie powinny mieć maksymalną długość do 120 znaków.

  5. Importy powinny być rozpisane w blokach kodowych jako pierwsze, że są one w każdym artykule ale nie powtórzone po raz pierwszy.

Informacja

Jako to, że Sponge jest nadal w stanie tworzenia, możemy się spodziewać niedoboru dokumentów, aż do oficjalnego wydania Sponge. Na pewno będą pustki w wielu dziedzinach. Niemniej jednak SpongeDocs jest żyjącym dokumentem i zawsze podlega edycji. Nigdy nie będzie doskonały, jedynie dobity do kształtu takiego jaki jest potrzebny.

Dodatki, sugestie i korekty są zawsze mile widziane.