diff --git a/docs/pl/manuals/addressing.md b/docs/pl/manuals/addressing.md
index 0fdc1e1e..9b16485b 100644
--- a/docs/pl/manuals/addressing.md
+++ b/docs/pl/manuals/addressing.md
@@ -5,11 +5,11 @@ brief: Instrukcja wyjaśnia sposób adresowania w silniku Defold.
# Adresowanie
-Kod, który kontroluje grę musi sięgać do wszystkich obiektów i komponentów, aby poruszać, skalować, animować, usuwać czy manipulować tym, co gracz widzi i słyszy. Umożliwia to mechanizm adresowania w silniku Defold.
+Kod, który steruje działającą grą, musi mieć możliwość dotarcia do każdego obiektu gry i komponentu, aby przesuwać, skalować, animować, usuwać i manipulować tym, co gracz widzi i słyszy. Mechanizm adresowania w silniku Defold sprawia, że jest to możliwe.
## Identyfikatory
-Defold wykorzystuje adresy (tzw. URL z ang. Uniform Resource Locator), aby odnosić się do obiektów i komponentów. Te adresy składają się z identyfikatorów (ID). Poniżej przedstawiono wszystkie przykłady tego, jak Defold wykorzystuje adresy. W tej instrukcji przeanalizujemy je szczegółowo:
+Defold wykorzystuje adresy (czyli URL-e, ale na razie odłóżmy tę kwestię na bok), aby odnosić się do obiektów gry i komponentów. Adresy te składają się z identyfikatorów. Poniżej znajdziesz przykłady zastosowań adresów w silniku Defold; w tej instrukcji przyjrzymy się im dokładnie:
```lua
local id = factory.create("#enemy_factory")
@@ -22,107 +22,108 @@ msg.post("#", "hello_there")
local id = go.get_id(".")
```
-Rozpocznijmy bardzo prostym przykładem. Załóżmy, że masz obiekt (game object) z pojedynczym komponentem typu sprite. Masz również pod tym obiektem komponent typu skrypt, który kontroluje ten obiekt. Taka hierarchia w edytorze powinna wyglądać tak:
+Zacznijmy od bardzo prostego przykładu. Załóżmy, że masz obiekt gry zawierający pojedynczy komponent typu sprite. Pod tym obiektem znajduje się komponent typu skrypt, który go kontroluje. Taki układ w edytorze wygląda mniej więcej tak:
-Załóżmy, że chcesz wyłączyć komponent typu sprite zaraz, gdy gra się uruchomi, aby pokazać go później. Można to z łatwością zrobić przez umieszczenie poniższego kodu w pliku *"controller.script"*:
+Chcesz wyłączyć sprite na starcie gry, żeby potem pokazać go ponownie. Wystarczy umieścić poniższy kod w pliku "controller.script":
```lua
function init(self)
msg.post("#body", "disable") -- <1>
end
```
-1. Nie przejmuj się na tę chwilę znakiem '#'. Powrócimy do tego.
-Zadziała to tak, jak oczekiwaliśmy. Gdy gra się uruchomi, skrypt *adresując* komponent typu sprite poprzez jego identyfikator "body" użyje tego adresu, aby wysłać do niego specjalną *wiadomość* o treści "disable" (ang. wyłącz). Efektem tej specjalnej wiadomości silnika jest to, że w komponencie sprite zostanie ukryty/wyłączony. Wygląda to następująco:
+1. Nie przejmuj się na razie znakiem '#'. Wrócimy do tego za moment.
+
+Działa to zgodnie z oczekiwaniami. Gdy gra startuje, komponent skryptowy adresuje komponent sprite po identyfikatorze "body" i używa tego adresu, aby wysłać do niego wiadomość "disable". Efektem tej specjalnej wiadomości silnika jest to, że komponent sprite ukrywa grafikę. Schematycznie sytuacja wygląda następująco:
-Identyfkatory w takim ustawieniu są arbitralne. Tutaj, to my zdecydowaliśmy, aby nadać obiektowi identyfikator "bean" (ang. fasola), a jego komponentowi typu sprite - identyfikator "body" (ang. ciało). Skrypt kontrolujący postać został nazwany "controller".
+Identyfikatory w tym ustawieniu są dowolne. Tutaj zdecydowaliśmy się nadać obiektowi gry identyfikator "bean", jego komponentowi sprite identyfikator "body", a skrypt kontrolujący postać nazwaliśmy "controller".
::: sidenote
-Jeśli sam nie wybierzesz identyfikatora, edytor zrobi to za Ciebie. Kiedy tworzysz nowy obiekt lub komponent w edytorze, zostaje mu z góry przydzielony unikalny *Id*.
+Jeśli nie wybierzesz własnego identyfikatora, edytor zrobi to za Ciebie. Kiedy tworzysz nowy obiekt gry lub komponent, automatycznie ustawiane jest unikalne *Id*.
-- Obiekty (ang. game objects) mają z góry przypisane Id "go" z numerem ("go2", "go3" itd.).
-- Komponenty dostają Id odpowiadające typowi ("sprite", "sprite2", "label", "sound" itp.).
+- Obiekty gry (ang. game objects) otrzymują domyślnie identyfikator "go" z kolejnym numerem ("go2", "go3" itd.).
+- Komponenty dostają identyfikator odpowiadający typowi ("sprite", "sprite2", "label", "sound" itd.).
-Oczywiście możesz pozostać przy tak wygenerowanych nazwach, ale zachęcamy do ich zmiany na dobre, opisowe i znaczące nazwy.
+Możesz pozostać przy tych automatycznie przypisanych nazwach, ale zachęcamy do zmiany ich na opisowe, celowe identyfikatory.
:::
-Teraz dodajmy kolejny komponent typu sprite dając postaci tarczę:
+Teraz dodajmy kolejny komponent sprite i wyposażmy fasolkę w tarczę:
-Nowy komponent musi mieć unikalną nazwę w obrębie danego obiektu. Jeśli spróbujesz ponownie nazwać komponent "body", będzie to niejednoznaczne i skrypt nie będzie "wiedział", do którego "body" ma wysłać wiadomość "disable". Dlatego wybieramy nową, znaczącą i unikalną nazwę "shield" (ang. tarcza). Teraz można dowolnie włączać i wyłączać sprite'y "body" i "shield".
+Nowy komponent musi mieć unikatowy identyfikator w obrębie obiektu gry. Gdybyś ponownie nazwał go "body", kod byłby niejednoznaczny – nie wiadomo, do którego sprite'a wysłać wiadomość "disable". Dlatego wybieramy unikalny, opisowy identyfikator "shield". W ten sposób możemy włączać i wyłączać sprite'y "body" i "shield" niezależnie.
::: sidenote
-Jeśli spróbujesz nadać nieunikalną nazwę, edytor i tak zasygnalizuje błąd, więc w praktyce to nigdy nie jest problem nie do zauważenia:
+Jeśli spróbujesz użyć tego samego identyfikatora dwa razy, edytor zgłosi błąd, więc w praktyce nigdy nie ma z tym problemu:
:::
-Zobaczmy teraz co się stanie, gdy dodamy więcej obiektów. Załóżmy, że chcesz stworzyć małą drużynę "fasolek". Nazwaliśmy jeden z obiektów "bean", to drugi nazwijmy "buddy" (ang. kolega). Ponadto, kiedy "bean" będzie przez chwilę bezczynny, chcemy, żeby powiedział on swojemu koledze "buddy", aby zaczął tańczyć. Można to zrobić przez wysłanie niestandradowej wiadomości o treści "dance" (ang. tańcz) ze skryptu "controller" obiektu "bean" do skryptu "controller" obiektu "buddy":
+Przyjrzyjmy się teraz, co się stanie, gdy dodasz kolejne obiekty. Załóżmy, że chcesz połączyć dwie fasolki w mały zespół. Nazwijmy jeden obiekt "bean", a drugiemu nadajmy nazwę "buddy". Chcemy też, żeby gdy "bean" przez chwilę stoi w miejscu, powiedział "buddy", żeby zaczął tańczyć. Robimy to wysyłając niestandardową wiadomość "dance" ze skryptu "controller" obiektu "bean" do skryptu "controller" obiektu "buddy":
::: sidenote
-Są tutaj dwa komponenty typu skrypt nazwane "controller", ale każdy w osobnym obiekcie, więc jest to całkowicie dozwolone, ponieważ ich całkowite nazwy (adresy) uwzględniające identyfikatory obiektów są od siebie różne. Nowy obiekt tworzy więc tzw. nowy kontekst nazewniczy.
+Widzimy tu dwa komponenty skryptowe o nazwie "controller", ale każdy w innym obiekcie gry, więc jest to całkowicie legalne. Dla każdego obiektu tworzy się nowy kontekst nazewniczy.
:::
-Ponieważ wysyłamy wiadomość do komponentu poza naszym obiektem ("bean"), w kodzie musimy dookreślić, do którego komponentu "controller" nasza wiadomość powinna być wysłana. Musimy więc w tym przypadku określić zarówno identyfikator obiektu (game object id) i komponentu (component id). Pełny adres komponentu "controller" z obiektu "buddy" brzmi więc: `"buddy#controller"` i adres ten składa się z dwóch części.
+Ponieważ adresat wiadomości znajduje się poza obiektem wysyłającym ("bean"), kod musi określić, który komponent "controller" powinien ją otrzymać. Trzeba więc podać zarówno identyfikator (Id) obiektu gry, jak i identyfikator komponentu. Pełny adres komponentu to `"buddy#controller"` i składa się z dwóch części.
-- Najpierw określamy identyfikator obiektu ("buddy"),
-- następnie wstawiamy wspomniany już znak oddzielenia id obiektu od komponentu ("#"),
-- i na końcu dodajemy identyfikator komponentu ("controller").
+- Najpierw określamy identyfikator obiektu gry ("buddy"),
+- następnie wstawiamy znak oddzielający obiekt i komponent ("#"),
+- a na końcu podajemy identyfikator komponentu ("controller").
-Wracając do poprzedniego przykładu z jednym obiektem (game object) widzimy, że zostawiając identyfikator obiektu pusty w adresie (brak id przed "#") jest automatycznie wnioskowany komponent z tego samego obiektu co skrypt, który wysyła taką wiadomość - kod adresuje więc komponenty z *własnego obiektu*.
+Wracając do poprzedniego przykładu z jednym obiektem gry, widzimy, że pomijając część identyfikującą obiekt (czyli nie wpisując nic przed "#"), kod odwołuje się do komponentów we *własnym obiekcie*.
-Przykładowo, `"#body"` oznacza, że adresujemy komponent "body" we własnym obiekcie. Jest to bardzo przydatne uproszczenie, ponieważ można dzięki temu stworzyć generyczny kod, który będzie działał jako skrypt dla *dowolnego* obiektu, jeśli tylko posiada on komponent "body".
+Na przykład `"#body"` to adres komponentu "body" wewnątrz tego samego obiektu gry. To bardzo wygodne uproszczenie, ponieważ pozwala pisać generyczny kod, który będzie działał dla *dowolnego* obiektu, jeśli tylko zawiera komponent "body".
## Kolekcje
-Kolekce (ang. collections) umożliwiają tworzenie grup i hierarchi obiektów (game objects) i wykorzystywania ich w kontrolowany sposób. Używa się plików typu kolekcja jak szablonów (tzw. "prototypów" czy "prefabów") w edytorze kiedy chcesz umieścić w grze obiekty.
+Kolekcje (ang. collections) pozwalają tworzyć grupy lub hierarchie obiektów gry i korzystać z nich wielokrotnie w kontrolowany sposób. W edytorze używa się plików kolekcji jako szablonów (czyli "prototypów" albo "prefabów") przy dodawaniu zawartości do gry.
-Załóżmy, że chcesz utworzyć grupę "fasolek" jak powyżej, ale do ogólnego użytku. Dobrym sposobem na to jest stworzenie szablonu w nowym pliku *collection file* (nazwij go "team.collection"). Umieść obiekty w tym pliku (w taki sam sposób jak tworzyłeś grupę powyżej w głównej kolekcji (main bootstrap collection)) i zapisz go. Następnie utwórz instancję tej kolekcji (tego pliku) w głównej kolekcji gry i nadaj mu identyfikator "team_1":
+Załóżmy, że chcesz wygenerować dużą liczbę duetów bean/buddy. Dobrym sposobem jest stworzenie nowego pliku kolekcji (nazwa "team.collection"), zbudowanie w nim obiektów i zapisanie go. Następnie umieść instancję tego pliku w głównej kolekcji bootstrapowej i nadaj instancji identyfikator, na przykład "team_1":
-Z taką strukturą obiekt "bean" może wciąż odnosić się do komponentu "controller" w skrypcie obiektu "buddy" poprzez adres `"buddy#controller"`.
+Dzięki takiej strukturze obiekt "bean" nadal może odwoływać się do komponentu "controller" obiektu "buddy" za pomocą adresu `"buddy#controller"`.
-I jeśli dodasz kolejną instancję kolekcji "team.collection" (nazwij ją "team_2"), kod uruchomiony wewnątrz kolekcji "team_2" również będzie działał. Obiekt "bean" z instancji kolekcji "team_2" może wciąż wysyłać wiadomości do skryptu "controller" w obiekcie "buddy" poprzez adres `"buddy#controller"`. Dzieje się tak z tego samego powodu, z którego mogliśmy to doprowadzić do działania w przypadku dwóch obiektów:
+Jeśli dodasz drugą instancję "team.collection" (nazwij ją "team_2"), kod działający wewnątrz komponentów skryptowych tej instancji zadziała dokładnie tak samo. Obiekt "bean" z instancji "team_2" dalej może wysyłać wiadomości do komponentu "controller" obiektu "buddy" przez adres `"buddy#controller"`.
## Adresowanie relatywne
-Adres `"buddy#controller"` działa dla obiektów z obu kolekcji, ponieważ jest *relatywny* czy też względny. Każda z instancji kolekcji "team_1" i "team_2" tworzy nowy kotekst nazweniczy (czy też "namespace"). Defold omija więc duplikowanie nazw przez używanie zarówno identyfikatorów komponentów i obiektów jak i kolekcji w celu tworzenia adresu:
+Adres `"buddy#controller"` działa dla obiektów z obu kolekcji, ponieważ jest *relatywny*. Każda instancja kolekcji "team_1" i "team_2" tworzy własny kontekst nazewniczy, czyli przestrzeń nazw. Defold unika kolizji nazw, uwzględniając ten kontekst przy adresowaniu:
-- W obrębie kontekstu nazewniczego kolekcji "team_1", obiekty "bean" i "buddy" mają unikalne adresy.
-- Analogicznie, w obrębie kontekstu nazewniczego kolekcji "team_2", obiekty "bean" i "buddy" mają również unikalne adresy.
+- W ramach kontekstu nazewniczego kolekcji "team_1" obiekty "bean" i "buddy" mają unikalne identyfikatory.
+- W analogiczny sposób w kontekście kolekcji "team_2" identyfikatory "bean" i "buddy" również są unikatowe.
-Adresowanie relatywne (względne) działa dzięki automatycznemu używaniu identyfikatora własnej, obecnej kolekcji (czy też własnego kontekstu nazewniczego) przy tworzeniu adresu każdego komponentu. Jest to również niezwykle przydatne, ponieważ możesz tworzyć grupy obiektów z tym samym kodem dla każdego z nich i wykorzystywać je wielokrotnie w grze.
+Adresowanie relatywne działa dzięki temu, że podczas rozwiązywania adresu Defold automatycznie dopisuje aktualny kontekst nazewniczy. To bardzo praktyczne, ponieważ pozwala tworzyć grupy obiektów z taką samą logiką i wielokrotnie wykorzystywać je w grze.
### Skróty
-Defold pozwala na używanie dwóch przydatnych skrótów przy tworzeniu adresu, bez określania konkretnego adresu URL komponentu ("#") czy obiektu ("."):
+Defold udostępnia dwa przydatne skróty, które pozwalają wysyłać wiadomości bez określania pełnego URL:
:[Shorthands](../shared/url-shorthands.md)
## Ścieżki do obiektów
-Aby poprawnie zrozumieć mechanizm adresowania, spójrzmy co się stanie, gdy zbudujesz i uruchomisz projekt:
+Aby zrozumieć mechanizm nazewnictwa, spójrzmy, co się dzieje po zbudowaniu i uruchomieniu projektu:
-1. Edytor początkowo wczytuje kolekcję główną (bootstrap main collection) ("main.collection") i całą jej zawartość (obiekty i inne kolekcje wewnątrz).
-2. Dla każdego obiektu statycznego (którego instancja już istnieje), kompilator tworzy identyfikator (adres). Te są zbudowane korzystając ze "ścieżek" startując od źródła kolekcji bootstrapowej (root), w dół hierarchi aż do danego obiektu. Znak '/' jest dodawany przy każdym zejściu poziomu hierarchi.
+1. Edytor wczytuje kolekcję bootstrapową ("main.collection") i całą zawartość (obiekty gry i inne kolekcje).
+2. Dla każdego statycznego obiektu gry kompilator tworzy identyfikator. Tworzy się ścieżka, która zaczyna się w "źródle" (ang. root - korzeń) kolekcji bootstrapowej i schodzi przez kolejne kolekcje aż do obiektu. Na każdym poziomie hierarchii dokleja się znak '/'.
-Dla przykładu powyżej, gra uruchomi się startując z 4 obiektami:
+W naszym przykładzie gra uruchomi się z czterema obiektami:
- /team_1/bean
- /team_1/buddy
@@ -130,24 +131,24 @@ Dla przykładu powyżej, gra uruchomi się startując z 4 obiektami:
- /team_2/buddy
::: sidenote
-Adresy komponentów są przechowywane jako "posiekane" lub "skrócone" (ang. hashed - i może lepiej jako programista używać angielskiej nazwy (hash)[https://pl.wikipedia.org/wiki/Funkcja_skrótu]- przyp. tłumacza) wartości. W czasie działania program przechowuje adresy również jako "shaszowane" dla każdej instancji w kolekcji, która jest w użyciu, aby zachować ciągłość nazwy adresu absolutnego (bezwzględnego).
+Identyfikatory są przechowywane jako wartości hashowane (ang. hashed - od nazwy (funkcji skrótu -hash)[https://pl.wikipedia.org/wiki/Funkcja_skrótu]). Runtime przechowuje również stan hashowania dla każdej kolekcji, co pozwala kontynuować przeliczanie relatywnych ciągów na identyfikatory absolutne.
:::
-W czasie działania programu, grupowanie kolekcji nie istnieje. Nie ma sposobu na sprawdzenie do jakiej kolekcji przynależy dany obiekt przed kompilacją. Nie jest też możliwe manipulowanie wszystkimi obiektami w kolekcji naraz. Jeśli jednak potrzebujesz wykorzystywać takie operacje możesz z łatwością śledzić adres w kodzie. Każdy identyfikator obiektu jest statyczny, jest więc gwarantowane, że zostanie stały przez cały cykl życia obiektu. Oznacza to, że można bezpiecznie przechować id obiektu i używać go później.
+W czasie działania grupowanie kolekcji znika. Nie da się ustalić, do której kolekcji należał dany obiekt przed kompilacją. Nie można też w prosty sposób manipulować wszystkimi obiektami z kolekcji naraz. Jeśli potrzebujesz takich operacji, samodzielnie je śledź w kodzie. Identyfikator każdego obiektu jest stały przez cały czas życia obiektu. Oznacza to, że bezpiecznie można go przechować i użyć później.
## Adresowanie absolutne
-Jest oczywiście możliwe używanie bezwzględnych (absolutnych) adresów komponentów podczas adresowania. W wielu przypadkach adresowanie relatywne jest prefereowane z powodu możliwości wielokrotnego wykorzystania kodu, ale są przypadki, gdzie wymagane jest adresowanie absolutne.
+Można też używać pełnych identyfikatorów opisanych powyżej. W większości przypadków preferuje się adresowanie relatywne, bo umożliwia ponowne użycie zawartości, ale zdarzają się sytuacje, gdy konieczne jest adresowanie absolutne.
-Na przykład, załóżmy, że chcesz stworzyć jeden manager AI, który będzie śledził stan wszytkich obiektów "fasolek". Chcesz, żeby "fasolki" raportowały swój status do managera, a manager podejmował taktyczne decyzje i wydawał rozkazy każdej "fasolce" bazując na jej stanie. W tym przypadku jest całkowicie sensowne użycie absolutnego adresowania do wysyłania wiadomości do managera, którego jedną instancję utworzysz w głównej kolekcji bootstrapowej obok wielu instancji "fasolek".
+Na przykład wyobraź sobie menedżera AI, który śledzi stan każdej fasolki. Chcesz, żeby fasolki raportowały swój status do menedżera, a on na podstawie tych informacji podejmował decyzje i wydawał rozkazy. W takim przypadku sensowne jest stworzenie jednego obiektu gry z komponentem skryptowym i umieszczenie go w głównej kolekcji bootstrapowej obok instancji zespołów.
-Każda "fasolka" jest odpowiedzialna za wysyłanie wiadomości ze statusem do managera AI: "contact", jeśli zauważy wroga lub "ouch!", gdy otrzyma obrażenia. Aby to działało, skrypt obiektu "fasolki" może użyć absolutnego adresu skryptu "controller" managera AI nazwanego pragmatycznie "manager".
+Każda "fasolka" odpowiada za wysyłanie wiadomości statusowych do menedżera: "contact" gdy zauważy wroga lub "ouch!" gdy dostanie obrażenia. Żeby to zadziałało, skrypt obiektu fasolki wykorzystuje absolutny adres, aby wysłać wiadomość do komponentu "controller" obiektu "manager".
-Każdy adres, który rozpoczyna się znakiem '/' będzie właśnie rozkodowywany od źródła kolekcji (root). W tym przypadku odpowiada to "rootowi" *kolekcji bootstrapowej*, która jest wczytywana wraz ze startem gry.
+Każdy adres rozpoczynający się od '/' jest rozwiązywany względem korzenia świata gry. Odpowiada to korzeniowi *kolekcji bootstrapowej*, która ładuje się przy starcie gry.
-Adres absolutny skryptu managera to `"/manager#controller"` i będzie on zawsze opisywał ten skrypt, niezależnie od tego, skąd wiadomość zostanie wysłana.
+Absolutnym adresem skryptu menedżera jest `"/manager#controller"` i niezależnie od miejsca użycia zawsze wskaże właściwy komponent.
@@ -155,9 +156,9 @@ Adres absolutny skryptu managera to `"/manager#controller"` i będzie on zawsze
## Identyfikatory haszowane (skrócone)
-Silnik Defold przechowuje wszystkie identyfikatory jako "shaszowane" wartości. Wszystkie funkcje, które przyjmują jako argument komponent lub obiekt (game object) akceptują "obiekty" typu string, hash lub URL. Powyżej używaliśmy tylko stringów do adresowania.
+Silnik przechowuje wszystkie identyfikatory jako wartości haszowane. Wszystkie funkcje przyjmujące jako argument komponent lub obiekt gry akceptują string, hash lub obiekt URL. Powyżej pokazywaliśmy adresowanie z użyciem stringów.
-Kiedy pobierasz identyfikator obiektu, silnik Defold zawsze zwróci ścieżkę absolutną identyfkatora, która jest haszowana:
+Kiedy pobierasz identyfikator obiektu, silnik Defold zawsze zwraca haszowaną ścieżkę absolutną:
```lua
local my_id = go.get_id()
@@ -167,10 +168,10 @@ local spawned_id = factory.create("#some_factory")
print(spawned_id) --> hash: [/instance42]
```
-Możesz użyć takiego identyfikatora zamiast adresu w postaci stringa lub skonstruować go samemu. Pamiętaj jednak, że shaszowany identyfikator odpowiada adresowi utworzonemu ze ścieżki do obiektu, czyli adresowi absolutnemu:
+Możesz użyć takiego identyfikatora zamiast stringa albo samodzielnie go skonstruować. Pamiętaj jednak, że haszowany identyfikator odpowiada ścieżce do obiektu, czyli adresowi absolutnemu:
::: sidenote
-Powodem, dla którego musimy podać stringi do stworzenia adresu relatywnego jest tworzenie przez silnik Defold na nowo haszowanego id bazującego na haszowanym stanie danego kontekstu nazewniczego (kolekcji) z podanym stringiem dodanym do hasza.
+Powodem, dla którego adresy relatywne muszą być podawane jako stringi, jest fakt, że silnik buduje nowy identyfikator haszowany na podstawie stanu haszowania aktualnego kontekstu nazewniczego (kolekcji) z dopisanym ciągiem tekstowym.
:::
```lua
@@ -188,30 +189,30 @@ go.set_position(pos, relative_id)
## URL
-Aby dopełnić obraz adresowania, spójrzmy na pełny format adresu w silniku Defold: adres URL.
+Żeby dopełnić obraz, spójrzmy na pełny format adresu w silniku Defold: URL.
-URL jest obiektem, zazwyczaj zapisywany jako specjalnie sformatowany string. Ogólny URL w Defoldzie składa się z trzech części:
+URL to obiekt, zwykle zapisywany jako specjalnie sformatowany string. Ogólny format URL-a wygląda tak:
`[socket:][path][#fragment]`
socket
-: Identyfikuje świat, w którym obiekt istnieje (instancję kolekcji). Jest to ważne podczas pracy z [Pełnomocnikami Kolekcji (Collection Proxy)](/manuals/collection-proxy) i jest później wykorzystywane do _dynamicznie załadowanej kolekcji_.
+: Identyfikuje świat gry, do którego należy cel (instancję kolekcji). Jest to istotne podczas pracy z [Pełnomocnikami kolekcji (Collection Proxy)](/manuals/collection-proxy) i służy do określenia _dynamicznie załadowanej kolekcji_.
path
-: Część adresu URL zawierająca pełne id danego obiektu (game object).
+: Ta część adresu URL zawiera pełny identyfikator docelowego obiektu gry.
fragment
-: Identyfkator danego komponentu pod danym obiektem.
+: Identyfikator komponentu znajdującego się pod wskazanym obiektem gry.
-Tak jak wcześniej, możesz zostawić niektóre pola puste pozwalając silnikowi na wydedukowanie, o jaki element chodzi zakładając domyślne wartości jak powyżej. Bardzo rzadko jest potrzeba określania gniazda (socket), za to często musisz określić ścieżkę (path). W przypadkach, gdy chcesz się odnieść do obiektu z innego świata (kolekcji) niż obecna, będziesz podawać socket. Przykładowo, pełny URL skryptu "controller" obiektu "manager" wygląda następująco:
+Jak widzieliśmy wcześniej, w większości przypadków można pominąć niektóre fragmenty adresu. Zwykle nie trzeba podawać socketu, a czasami nie trzeba też podawać ścieżki. Gdy jednak chcesz odwołać się do świata innego niż aktualny, musisz określić socket. Przykładowo pełny string URL-a skryptu "controller" obiektu "manager" to:
`"main:/manager#controller"`
-a skrypt "controller" obiektu "buddy" w kolekcji "team_2" to:
+a kontroler kolegi z "team_2" to:
`"main:/team_2/buddy#controller"`
-Możemy do nich wysłać wiadomości:
+Możemy wysyłać wiadomości do tych komponentów:
```lua
-- Send "hello" to the manager script and team buddy bean
@@ -221,7 +222,7 @@ msg.post("main:/team_2/buddy#controller", "hello_buddy")
## Konstruowanie obiektów URL
-Obiekty URL mogą być również kontruowane w kodzie:
+Obiekty URL można także tworzyć programowo w kodzie Lua:
```lua
-- Construct URL object from a string:
@@ -243,4 +244,4 @@ my_url.fragment = "controller" -- specify as string or hash
-- Post to target specified by URL
msg.post(my_url, "hello_manager!")
-```
\ No newline at end of file
+```
diff --git a/docs/pl/manuals/application-lifecycle.md b/docs/pl/manuals/application-lifecycle.md
index 2157c8c4..b0b28341 100644
--- a/docs/pl/manuals/application-lifecycle.md
+++ b/docs/pl/manuals/application-lifecycle.md
@@ -1,44 +1,63 @@
---
title: Cykl życia aplikacji w silniku Defold
-brief: Instrukcja opisuje cykl życia aplikacji na silniku Defold i jego szczegóły.
+brief: Przewodnik wyjaśnia cykl życia aplikacji zbudowanej w silniku Defold od uruchomienia do zamknięcia.
---
# Cykl życia aplikacji
-Cykl życia aplikacji czy gry w silniku Defold jest w ogólności prosty. Silnik przechodzi przez 3 etapy:
-* inicjalizacja (initialization),
-* aktualizacja w pętli (update loop),
-* finalizacja (finalization).
+Cykl życia aplikacji lub gry w silniku Defold jest zasadniczo prosty. Silnik przechodzi przez trzy główne fazy: inicjalizację, pętlę aktualizacyjną (gdzie aplikacja spędza większość czasu) oraz finalizację.
-
+::: sidenote
+Instrukcja odnosi się do wersji Defold 1.12.0. W tej wersji wprowadzono zmiany w procesie cyklu życia oraz nową funkcję `late_update()`.
+:::
+
+
+
+W wielu przypadkach wystarczy ogólna wiedza o tym, jak działa silnik Defold. Jednak czasem trzeba poznać dokładną kolejność wykonywanych operacji. Ten dokument opisuje przebieg działania silnika od startu do zakończenia aplikacji.
-W wielu przypadkach nie jest w ogóle wymagana dogłębna wiedza o wewnętrznych procesach silnika Defold. Możesz jednak potrzebować kontrolować lub zbadać pewne skrajne przypadki, wyjątkowe sytuacje, w których potrzebna jest wiedza o kolejności wykonywanych operacji. Dokument ten opisuje jak silnik Defold obsługuje aplikację od początku do końca.
+Aplikacja zaczyna się od przygotowania wszystkiego, co jest potrzebne do działania silnika. Główna kolekcja zostaje załadowana, a silnik Defold wywołuje [`init()`](/ref/go#init) dla wszystkich załadowanych komponentów, które posiadają tę funkcję (zarówno w skryptach obiektów, jak i skryptach GUI). Dzięki temu można przeprowadzić własną inicjalizację.
-Aplikacja startuje poprzez zainicjalizowanie wszystkiego, co jest potrzebne do pracy silnika. Defold wczytuje główną kolekcję bootstrapową i wywołuje funkcje [`init()`](/ref/go#init) **wszystkich** załadowanych komponentów. Funkcja `init()` może być napisana w języku Lua w skryptach obiektów i GUI, co pozwala na własną inicjalizację.
+Następnie aplikacja wchodzi w pętlę aktualizacyjną, w której spędza większość swojego czasu. Każda klatka aktualizuje obiekty gry i komponenty. Wywoływane są funkcje [`update()`](/ref/go#update) zarówno w skryptach, jak i w skryptach GUI. Podczas tej fazy wiadomości są rozsyłane do odbiorców, odtwarzane są dźwięki, a wszystkie elementy graficzne są renderowane.
-Aplikacja przechodzi następnie do pętli aktualizacyjnej, która trwa przez większość jej czasu działania, aż do zakończenia programu i przejścia do fazy finalizacyjnej. Każda klatka wyświetlana na ekranie, obiekty i komponenty aplikacji są aktualizowane. Dla każdego skryptu i skryptu GUI specjalna funkcja [`update()`](/ref/go#update) jest wywoływana. Podczas aktualizacji wiadomości są rozsyłane do odbiorców, dźwięki są odtwarzane, a cała grafika jest renderowana i wyświetlana.
+W pewnym momencie cykl życia dobiega końca. Zanim aplikacja się zakończy, silnik wychodzi z pętli aktualizacyjnej i przechodzi do fazy finalizacyjnej. Przygotowuje wszystkie obiekty gry do usunięcia. Funkcje [`final()`](/ref/go#final) każdego komponentu są uruchamiane, co pozwala na własne procedury sprzątania. Potem obiekty są usuwane, a główna kolekcja zostaje zwolniona.
-W pewnym momencie cykl życia aplikacji dobiega końca. Jeszcze przed tym, zanim aplikacja zamknie się, silnik wyjdzie z pętli aktualizacyjnej i przejdzie do fazy finalizacyjnej. Defold przygotuje wtedy wszystkie załadowane obiekty i kolekcje do usunięcia. Specjalna funkcja [`final()`](/ref/go#final) każdego z komponentów zostanie wywołana, co pozwola na własne procedury finalizacji. Następnie obiekty są usuwane i główna kolekcja jest opuszczana.
+Wszystkie kroki zawarte w przejściu „dispatch messages” są pokazane osobno na końcu tego podręcznika, a na diagramach oznaczone ikoną koperty ze strzałką 📩.
## Faza inicjalizacyjna
-Diagram poniżej zawiera szczegółowe rozplanowanie kroków inicjalizacji. Kroki we fragmencie rozsyłania wiadomości (ang. "dispatch messages") tuż przed tworzeniem instancji obiektów dynamicznych (ang. "spawn dynamic objects") zostały opisane szczegółowo w osobnym bloku gwoli przejrzystości.
+To tutaj zaczyna się gra, i jest to pierwszy etap uruchomienia. Można go podzielić na trzy podfazy:
+
+
+
+### Przedinicjalizacja (Preinitialization)
+
+W fazie `Preinitialization` silnik wykonuje wiele działań zanim załaduje główną (bootstrapową) kolekcję. Konfigurowany jest profiler pamięci, gniazda, grafika, wejścia (HID), dźwięk, fizyka i wiele innych subsystemów. Wczytywany jest także plik konfiguracyjny (*game.project*).
-
+
-Silnik w zasadzie podejmuje więcej kroków podczas inicjalizacji, jeszcze przed załadowaniem głównej kolekcji. Inicjalizowane są: profiler pamięci (memory profiler), gniazda (sockets), grafika, urządzenia wejścia (HID), dźwięk, fizyka i wiele innych modułów. Plik konfiguracyjny (*game.project*) jest wtedy również wczytywany i wykorzystywany.
+Pierwszym punktem, w którym użytkownik kontroluje przepływ, jest wywołanie `init()` aktualnego render scriptu.
-Pierwszym punktem wejściowym, w którym użytkownik przejmuje kontrolę, już na samym końcu fazy inicjalizacji, jest funkcja `init()` specjalnego skryptu do renderowania (ang. render script).
+Główna kolekcja zostaje wtedy załadowana i zainicjalizowana.
-Główna kolekcja jest następnie załadowywana i inicjalizowana. Wszystkie obiekty (game objects) w tej kolekcji są wtedy tworzone i przypisywana jest im oraz ich dzieciom pozycja, orientacja i skala (całościowo po ang. transform - macierz transformacji). Funkcje `init()` wszystkich załadowanych komponentów są wywoływane, jeśli istnieją.
+### Inicjalizacja kolekcji (Collection Init)
+
+Podczas fazy `Collection Init` wszystkie obiekty gry w kolekcji przypisują transformacje – przesunięcie, obrót i skalowanie – swoim dzieciom. Następnie wywoływane są funkcje `init()` wszystkich komponentów, które ją udostępniają.
+
+
::: sidenote
-Kolejność w jakiej funkcje `init()` komponentów są wywoływane jest nieokreślona. Nie można zakładać, że silnik zainicjalizuje obiekty zawsze w tej samej kolejności.
+Kolejność wywołań funkcji `init()` komponentów obiektów gry nie jest określona. Nie należy zakładać konkretnej kolejności inicjalizacji w obrębie tej samej kolekcji.
:::
-Ponieważ w funkcji `init()` możesz już wysyłać wiadomości, tworzyć nowe obiekty przy użyciu fabryk (factory), przeznaczać obiekty do usunięcia i wiele innych rzeczy, silnik Defold wykonuje zaraz po inicjalizacji jedno przejście "post-update". W przejściu tym rozsyłane są otrzymywane są wysłane wiadomości oraz tworzone i usuwane obiekty. Przejście to zawiera więc również funkcję rozsyłania wiadomości ("dispatch messages"), gdzie nie tylko zakolejkowane wiadomości są wysyłane, ale także obsługiwane są wiadomości do pełnomocników kolekcji (collection proxies). Każda kolejna aktualizacja tych pełnomocników (aktywowanie, dezaktywowanie, wczytywanie i oznaczanie jako gotowe do zwolnienia) są wykonywane w tych krokach.
+### Post Update podczas inicjalizacji
+
+Po inicjalizacji silnik wykonuje pełne przejście `Post Update` – to samo, które odbywa się po każdym kroku pętli `Update Loop`. Szczególnie ważne jest to, że w tej fazie można zainicjalizować nowo tworzone obiekty, wysłać wiadomości, oznaczyć obiekty do usunięcia itd.
-Analizując diagram powyżej dostrzegamy możliwość załadowania pełnomocnika kolekcji [(collection proxy)](/manuals/collection-proxy) w funckji `init()`, zainicjalizowania jej obiektów, a następnie zwolnienia kolekcji - wszystko to jeszcze przed pierwszym wywołaniem funkcji `update()` pierwszego komponentu, czyli przed wyjściem z fazy inicjalizacyjnej do pętli aktualizacyjnej:
+
+
+Ten etap zajmuje się dostarczeniem wiadomości, tworzeniem nowych obiektów przez fabryki oraz usuwaniem obiektów. Przejście `Post Update` zawiera sekwencję „dispatch messages”, która nie tylko rozsyła zakolejkowane wiadomości, ale także obsługuje wiadomości skierowane do pełnomocników kolekcji (collection proxies). W kolejnych krokach aktualizowane są stany proxy (enable, disable, init, final, loading, mark for unloading).
+
+Możliwe jest załadowanie [collection proxy](/manuals/collection-proxy) w trakcie `init()`, zainicjalizowanie jego obiektów, a następnie zwolnienie kolekcji – i to wszystko jeszcze zanim zostanie wywołana pierwsza funkcja `update()` komponentu, czyli zanim silnik opuści fazę inicjalizacji i wejdzie w pętlę aktualizacyjną:
```lua
function init(self)
@@ -63,60 +82,158 @@ function on_message(self, message_id, message, sender)
end
```
-## Faza aktualizacyjna - pętla
+## Pętla aktualizacyjna (Update Loop)
+
+Pętla aktualizacyjna przebiega według określonej sekwencji w każdej klatce. Jej przebieg podzielony jest na pięć głównych faz:
+
+
+
+1. Input (odczyt i obsługa)
+2. Update (obejmuje Fixed, Regular, Late oraz aktualizacje komponentów silnika)
+3. Render Update
+4. Post Update (zwalnianie kolekcji, tworzenie i usuwanie obiektów)
+5. Frame Render (ostatnie renderowanie grafiki)
+
+### Faza wejść (Input Phase)
+
+Wejścia są odczytywane z dostępnych urządzeń, mapowane zgodnie z [input bindings](/manuals/input) i rozsyłane dalej. Każdy obiekt gry, który zdobył `acquire_input_focus`, otrzymuje wejścia w funkcje `on_input()` wszystkich swoich komponentów. Jeżeli obiekt posiada zarówno skrypt komponentu, jak i komponent GUI, oba dostaną wejścia, pod warunkiem że oba mają przechwytywanie wejścia.
+
+
+
+Jeżeli obiekt gry, który ma fokus wejścia, zawiera pełnomocników kolekcji, wejścia są przekazywane do komponentów wewnątrz tych proxy. Proces ten rekurencyjnie działa dla wszystkich włączonych proxy w obrębie włączonych proxy.
+
+### Faza aktualizacji (Update Phase)
+
+Faza `Update` zaczyna się dla głównej kolekcji, a następnie jest wywoływana rekurencyjnie dla każdego włączonego collection proxy.
+
+W obrębie kolekcji silnik Defold przetwarza callbacki według typu komponentu: dla każdego typu iteruje po wszystkich instancjach, które implementują daną fazę, wywołuje funkcję Lua, opróżnia wiadomości, a potem przechodzi do następnego typu.
+
+Wysoki poziom kolejności callbacków Lua w komponentach typu *script* wygląda następująco:
+
+1. `fixed_update()` – wywoływane `0..N` razy na klatkę (gdy używany jest stały krok czasu)
+2. `update()` – wywoływane raz na klatkę
+3. `late_update()` – wywoływane raz na klatkę
+
+
+
+Każdy komponent obiektu gry w głównej kolekcji jest odwiedzany. Jeśli którykolwiek komponent posiada `fixed_update()`/`update()`/`late_update()`, to są one uruchamiane. Jeżeli komponent jest collection proxy, wszystkie komponenty tej kolekcji proxy są aktualizowane rekurencyjnie we wszystkich krokach fazy `Update`.
-Pętla aktualizacyjna (update loop) przez cały czas trwania aplikacji jest wykonywana w każdej klatce. Sekwencja aktualizacji przedstawiona na diagramie poniżej jest podzielona na logiczne sekcje gwoli przejrzystości. Rozsyłanie wiadomości (ang. "dispatch messages") jest ponadto dodatkowo podzielona z tego samego powodu:
+::: sidenote
+Kolejność wywołań funkcji `update()` komponentów nie jest określona. Nie należy zakładać konkretnego porządku aktualizacji obiektów należących do tej samej kolekcji. To samo dotyczy `fixed_update()` i `late_update()` (od wersji 1.12.0).
+:::
+
+#### Fizyka
+
+Dla komponentów collision object wiadomości fizyki (kolizje, wyzwalacze, odpowiedzi ray cast itd.) są rozsyłane do wszystkich komponentów, które implementują `on_message()` w obrębie danego obiektu gry.
-
+Jeżeli do symulacji fizyki używany jest [fixed timestep](/manuals/physics/#physics-updates), to funkcje `fixed_update()` są wywoływane we wszystkich komponentach skryptowych. Ta funkcja jest przydatna do stabilnego sterowania obiektami fizycznymi.
-## Wejścia
+#### Transformaty
-Wejścia są odczytywane ze wspieranego urządzenia, na którym działa aplikacja i mapowane zgodnie z zasadami umieszczonymi w opisie wiązania wejść [(ang. input bindings)](/manuals/input), a następnie rozsyłane. Każdy obiekt (game object), który zadeklarował przechwytywanie wejść (ang. acquired input focus) otrzymuje wejścia wysłane do funkcji `on_input()` jego wszystkich komponentów, w tym oczywiście skryptów i skryptów GUI komponentów GUI. Jeśli obiekt posiada oba, do wszystkich zostaną wysłane wejścia, zakładając oczywiście, że zadeklarowały przechwytywanie wejść.
+Przed każdą aktualizacją typu komponentu, wielokrotnie w trakcie `Update Loop`, jeśli jest to potrzebne, aktualizowane są transformaty – przesunięcie, obrót i skala obiektów, ich komponentów i obiektów potomnych.
-Każdy obiekt, który zadeklarował przechwytywanie wejść i posiada jednego lub więcej pełnomocników kolekcji przesyła wejścia do komponentów wewnątrz tych pełnomocników. Proces ten działa rekursywnie dla każdych obiektów wewnątrz aktywnych pełnomocników, itd.
+Na końcu `Update Loop` wykonywana jest jeszcze jedna finalna aktualizacja transformacji, jeśli jest to wymagane.
-## Aktualizacja komponentów
+#### Faza silnika bez fixed update
-Silnik przechodzi przez każdy obiekt w głównej kolekcji i jeśli którykolwiek z komponentów posiada funkcję `update()` będzie ona wywołana. Jeśli komponentem jest pełnomocnik kolekcji, każdy komponent takiego pełnomocnika jest sprawdzany rekursywnie w dół i aktualizowany zgodnie z wszystkimi krokami opisanymi powyżej.
+Poniższe tabele opisują aktualizacje na poziomie silnika. Pomijają dokładną kolejność priorytetów komponentów (to szczegół implementacji), ale oddają gwarancje ważne dla skryptów:
+
+- `fixed_update()` działa przed `update()`
+- `late_update()` działa po `update()`
+- wiadomości są rozsyłane między aktualizacjami typu komponentu oraz między etapami callbacków skryptowych
+
+Gdy `Use Fixed Timestep` jest ustawione na `false` i/lub `Fixed Update Frequency` wynosi `0`, na początku faza przygotowuje `dt`, a następnie przebieg jest następujący:
::: sidenote
-Kolejność w jakiej funkcje `update()` komponentów są wywoływane jest nieokreślona. Nie można zakładać, że silnik zaktualizuje obiekty zawsze w tej samej kolejności.
+Po każdej aktualizacji typu komponentu wszystkie wiadomości są rozsyłane – w tabelach nie pokazano tego dla przejrzystości.
:::
-W następnej kolejności wszystkie wiadomości są rozsyłane. A ponieważ każdy z komponentów, który otrzymuje wiadomość, w funkcji `on_message()` może wysyłać dodatkowo następne wiadomości, więc ten sam mechanizm rozsyłania wiadomości (ang. message dispatcher) działa dopóki kolejka wiadomości nie zostanie opróżniona. Istnieje jednak limit takich iteracji przejścia przez kolejkę wiadomości. Szczegóły znajdziesz w opisie [przesyłania wiadomości](/manuals/message-passing) w sekcji "Zaawansowane" (ang. "Advanced topics").
+| Krok | Faza silnika | Callback Lua | Komentarz |
+|-|-|-|-|
+| 1 | **Update** | `update()` | Wywoływane raz na klatkę dla każdego typu komponentu implementującego Update według wewnętrznego priorytetu. Animacje właściwości GO zaczęte przez `go.animate()` działają tu jako oddzielny typ komponentu. Aktualizowane są również komponenty fizyki. Dla każdego włączonego collection proxy cała faza `Update` jest wykonywana rekurencyjnie od kroku 1. |
+| 2 | **Late Update** | `late_update()` | Wywoływane raz na klatkę dla każdego typu komponentu implementującego Late Update zgodnie z priorytetem. |
+| 3 | **Transforms** | | Na końcu przeprowadzana jest dodatkowa aktualizacja transformacji dla każdego komponentu, jeśli jest to potrzebne. |
+
+#### Faza silnika z fixed timestep
+
+Gdy `Use Fixed Timestep` ma wartość `true`, a `Fixed Update Frequency` jest różna od zera, na początku faza przygotowuje `dt`, `fixed_dt` oraz `num_fixed_steps` (`0..N`) – czyli ile razy zostanie wywołana funkcja fixed update, określone przez czas od ostatniej aktualizacji, aby zachować stałą liczbę kroków.
+
+::: sidenote
+Po każdej aktualizacji typu komponentu wszystkie wiadomości są rozsyłane – tabelki tego nie pokazują dla przejrzystości.
+:::
+
+Potem faza przebiega w pętli:
+
+| Krok | Faza silnika | Callback Lua | Komentarz |
+|-|-|-|-|
+| 1 | **Fixed Update** | `fixed_update()` | Wywoływana `0..N` razy na klatkę dla każdego typu komponentu implementującego Fixed Update według priorytetu. Zawiera również Fixed Update komponentów fizyki. |
+| 2 | **Update** | `update()` | Wywoływana raz na klatkę dla każdego typu komponentu implementującego Update według priorytetu. Animacje właściwości GO uruchomione przez `go.animate()` działają tu jako oddzielny typ komponentu. Dla każdego włączonego collection proxy faza `Update` jest wykonywana rekurencyjnie, zaczynając od kroku 1. |
+| 3 | **Late Update** | `late_update()` | Wywoływana raz na klatkę dla każdego typu komponentu implementującego Late Update według priorytetu. |
+| 4 | **Transforms** | | Na końcu przeprowadzana jest dodatkowa aktualizacja transformacji dla każdego komponentu, jeśli jest to potrzebne. |
-Jeśli chodzi o wiadomości do obiektów kolizji (ang. collision object) i wiadomości dotyczących silnika fizycznego (odpowiedzi kolizji, przełączników (ang. triggers), promieni (ang. ray_cast), itp.) są one rozsyłane podczas obsługi każdego z obiektów do wszystkich komponentów, które posiadają funkcję `on_message()`.
+W razie potrzeby więcej informacji o wewnętrznym działaniu fazy Update można znaleźć w kodzie [`gameobject.cpp`](https://github.com/defold/defold/blob/dev/engine/gameobject/src/gameobject/gameobject.cpp).
-Macierze transformacji (ang. transforms) są później tworzone i aplikowane do obiektów, ich komponentów i kolejnych obiektów-dzieci- zmieniana jest ich pozycja, orientacja i skala.
+### Faza renderowania (Render Update Phase)
-## Aktualizacja renderowania
+W bloku `Render Update` najpierw przetwarzane są wszystkie wiadomości wysłane na gniazdo `@render` (np. wiadomości `set_view_projection`, `set_clear_color` itd.). Następnie wywoływana jest funkcja `update()` skryptu renderującego.
-Sekcja aktualizacji renderowania rozsyła i obsługuje wiadomości przesłane do specjalnego gniazda (ang. socket) `@render` (np. wiadomości `set_view_projection` dla kamery, ustawianie koloru czyszczenia ekranu `set_clear_color`, itp.). Następnie wywoływana jest funkcja `update()` skryptu renderowania (ang. render script).
+
-## Post-aktualizacja
+### Faza post-aktualizacji (Post update Phase)
-Po aktualizacji uruchamiana jest sekwencja tzw. post-aktualizacji. Zwalnia ona z pamięci pełnomocników kolekcji, którzy zostali do takiego zwolnienia oznaczeni (zdezaktywowani podczas rozsyłania wiadomości - sekwencji "dispatch messages"). Każdy obiekt, który jest przeznaczony do usunięcia wywołuje funkcję `final()` we wszystkich komponentach, jeśli istnieje. Kod w funkcji `final()` może również wysyłać wiadomości, więc dodatkowe przejście przez kolejkę wiadomości jest uruchamiane na końcu.
+Po aktualizacjach uruchamiana jest sekwencja post-aktualizacji. Z pamięci są zwalniani collection proxy oznaczeni do wyładowania (co następuje podczas sekwencji `dispatch messages`). Wszystkie obiekty oznaczone do usunięcia wywołują `final()` we wszystkich komponentach je posiadających. Kod w tych funkcjach może wysyłać kolejne wiadomości, stąd po `final()` ponownie uruchamiana jest sekwencja rozsyłania wiadomości.
-Każdy komponent typu fabryka (ang. factory), który został oznaczony jako gotowy do utworzenia obiektu, w tym momencie utworzy taki obiekt. Na końcu obiekty, które są przeznaczone do usunięcia zostają usunięte.
+
-Ostatnim krokiem pętli aktualizacyjnej jest obsługa wiadomości kolejnego, specjalnego gniazda `@system` (wiadomości `exit`, `reboot`, przełączanie profilera, startowanie i zatrzymywanie przechwytywania video, itp.). Następnie renderowana jest grafika. Podczas renderowania grafiki, tworzone jest przychwytywanie video, tak samo jak i wizualizacja profilera (zobacz [dokumentację do debugowania](/manuals/debugging).)
+Następnie komponenty fabryki, które miały zostać uruchomione, tworzą obiekty. Na końcu obiekty oznaczone do usunięcia są faktycznie usuwane.
-## Klatki na sekundę i krok czasowy kolekcji
+### Faza renderowania (Render Phase)
-Liczba klatek na sekundę (równa liczbie pętli aktualizacyjnych na sekundę) może być ustawiona w pliku konfiguracyjnym projektu (*game.project*) lub dynamicznie przez wysłanie wiadomości `set_update_frequency` do specjalnego gniazda `@system`. Dodatkowo, możliwe jest ustawienie kroku czasowego (ang. _time step_) dla pełnomocników kolekcji indywidualnie poprzez wysłanie wiadomości `set_time_step`. Zmiana czasu kroku kolekcji nie wpływa na liczbę klatek na sekundę - jedynie na aktualizację fizyki oraz wartość `dt` przekazywaną do funkcji `update().` Zauważ również, że zmiana kroku czasowego nie zmienia samej liczby wywołań funkcji `update()`, które są wywoływane w każdej klatce - a ta nie ulega zmianie.
+Ostatnim krokiem pętli aktualizacyjnej jest obsłużenie wiadomości wysyłanych do gniazda `@system` (`exit`, `reboot`, przełączanie profilera, uruchamianie i zatrzymywanie nagrywania wideo itd.).
-(Szczegóły znajdziesz w [Instrukcji do pełnomocników kolekcji](/manuals/collection-proxy) i [`set_time_step`](/ref/collectionproxy#set-time-step))
+
+
+Następnie grafika jest renderowana, w tym wizualizacja profilera (zobacz [dokumentację debugowania](/manuals/debugging)). Zaraz po renderowaniu następuje przechwytywanie wideo.
+
+#### Liczba klatek i krok czasowy kolekcji
+
+Liczba klatek na sekundę (odpowiednio liczba przebiegów pętli aktualizacyjnej) jest ustawiana w ustawieniach projektu albo dynamicznie przez wysłanie wiadomości `set_update_frequency` do gniazda `@system`. Można też ustawić _time step_ dla każdego collection proxy przez `set_time_step`. Zmiana kroku kolekcji nie wpływa na liczbę klatek (czyli ilość wywołań `update()` w każdej klatce), ale zmienia czas kroków fizyki oraz wartość `dt` przekazywaną do `update()`.
+
+(Zobacz [Instrukcję pełnomocników kolekcji](/manuals/collection-proxy) i [`set_time_step`](/ref/collectionproxy#set-time-step) po więcej szczegółów)
+
+#### Ograniczanie pracy silnika
+
+W Defold 1.12.0 dodano API ograniczające pracę silnika, które może pominąć aktualizacje i renderowanie, jednocześnie wykrywając wejście. Każde wejście budzi silnik i po okresie chłodzenia można ponownie wejść w ograniczoną pracę.
+
+Zobacz `sys.set_engine_throttle()` dla szczegółów i przykładów użycia.
## Faza finalizacyjna
-Kiedy aplikacja jest zamykana, najpierw kończona jest ostatnia pętla aktualizacyjna, która zwolni wszystkich pełnomocników kolekcji: finalizując i usuwając wszystkie obiekty w każdym z nich.
+Gdy aplikacja kończy pracę, najpierw dokańcza ostatnią sekwencję pętli aktualizacyjnej, która zwalnia collection proxy – finalizując i usuwając obiekty wewnątrz nich.
+
+Po tym silnik przechodzi do samej finalizacji, która dotyczy głównej kolekcji i jej obiektów:
+
+
+
+Na początku wywoływane są funkcje `final()` wszystkich komponentów. Później uruchamiana jest sekwencja rozsyłania wiadomości. Na końcu wszystkie obiekty są usuwane, a główna kolekcja zostaje zwolniona.
+
+Silnik dalej kończy pracę wewnętrznych subsystemów, np. usuwa konfigurację projektu, zatrzymuje profiler pamięci itd.
+
+Aplikacja jest wtedy całkowicie zamknięta.
+
+## Rozsyłanie wiadomości (Dispatching Messages)
-Kiedy to się zakończy silnik przejdzie do sekwencji finalizacyjnej, która zamknie główną kolekcję i jej obiekty:
+`Dispatching Messages` to specjalne przejście wykonywane po **każdej** aktualizacji typu komponentu (np. aktualizacji sprite’a, skryptów itp.). W tym kroku wszystkie zgromadzone wiadomości są rozsyłane. Diagram oznacza te działania ikoną koperty ze strzałką 📩.
-
+
-Funkcje `final()` wszystkich komponentów zostaną najpierw wywołane. Jeśli w kodzie tych funkcji wysyłane są jeszcze jakieś wiadomości, zostaną one wysłane i obsłużone. Ostatecznie, wszystkie obiekty zostaną usunięte i główna kolekcja zostanie zwolniona.
+Po tym, jak wszystkie **wiadomości użytkownika** zostaną dostarczone przez wywołanie `on_message()`, silnik obsługuje specjalne wiadomości Defold w następującej kolejności (przy każdym collection proxy):
-Silnik będzie kontynuował jeszcze finalizację i zwalnianie elementów wewnętrznych, takich jak: konfiguracja projektu, profiler pamięci, itd.
+1. `load` – ładuje pełnomocniki oznaczone do wczytania, wysyła z powrotem `proxy_loaded`.
+2. `unload` – zwalnia pełnomocniki oznaczone do zwolnienia, wysyła `proxy_unloaded`.
+3. `init` – wywołuje fazę `Collection Init` dla proxy zaznaczonych do inicjalizacji.
+4. `final` – wywołuje `final()` dla wszystkich komponentów proxy oznaczonych do zamknięcia.
+5. `enable` – aktywuje collection proxy, żeby w następnej klatce wykonać dla niego `Update Loop`; to też uruchamia `init()` dla składników proxy.
+6. `disable` – dezaktywuje collection proxy, więc pętla aktualizacyjna nie będzie dla niego wykonywana.
-Aplikacja jest na końcu zamknięta.
\ No newline at end of file
+Ponieważ kod odbiorców `on_message()` może publikować kolejne wiadomości, dispatcher kontynuuje przetwarzanie kolejki aż do jej opróżnienia. Jednak dispatcher ma limit liczby przejść przez kolejkę. Więcej informacji znaleźć można w rozdziale [Message Chains](/manuals/message-passing).
diff --git a/docs/pl/manuals/getting-help.md b/docs/pl/manuals/getting-help.md
index 9006e400..7279e77a 100644
--- a/docs/pl/manuals/getting-help.md
+++ b/docs/pl/manuals/getting-help.md
@@ -1,92 +1,95 @@
---
-title: Jak uzyskać pomoc?
-brief: Instrukcja opisuje jak efektywnie i szybko uzyskać pomoc, jeśli napotkasz jakiekolwiek problemy z Defoldem.
+title: Jak uzyskać pomoc
+brief: Ta instrukcja opisuje, jak uzyskać pomoc, gdy napotkasz problem podczas korzystania z silnika Defold.
---
-# Jak uzyskać pomoc?
+# Jak uzyskać pomoc
-Jeśli napotkasz jakiekolwiek problemy z Defoldem, służymy pomocą! Postaramy się naprawić błędy i rozwiązać problemy lub pomóc Ci znaleźć inne rozwiązanie! Jest kilka sposobów na zgłoszenie i przedystkutowanie problemów. Wybierz takim który jest dla Ciebie najwygodniejszy:
+Jeśli napotkasz problem podczas korzystania z silnika Defold, chcemy o tym wiedzieć, żeby móc go naprawić lub pomóc Ci znaleźć obejście. Istnieje kilka sposobów, aby omówić lub zgłosić problem. Wybierz ten, który najbardziej Ci odpowiada:
## Zgłoś problem na forum
-Dobrym sposobem na przedyskutowanie problemu jest zadanie pytania na naszym [forum](https://forum.defold.com). Zadaj pytanie w ogólnej kategorii: [Questions](https://forum.defold.com/c/questions) lub opisz błąd w kategorii: [Bugs](https://forum.defold.com/c/bugs). Pamiętaj też, że zawsze możesz spróbować przeszukać forum: [search](https://forum.defold.com/search) w poszukiwaniu odpowiedzi na nurtujące Cię pytania lub rozwiązania problemu, na który ktoś mógł już natrafić. (Forum jest anglojęzyczne, ale przykładowo na Discordzie Defolda możesz znaleźć polskojęzyczny kanał - przyp.tłum.)
+Dobrym sposobem na omówienie problemu i uzyskanie pomocy jest zadanie pytania na naszym [forum](https://forum.defold.com). Zamieść post w [Questions](https://forum.defold.com/c/questions) albo w [Bugs](https://forum.defold.com/c/bugs), w zależności od rodzaju problemu. Pamiętaj, żeby [wyszukać](https://forum.defold.com/search) swoje pytanie/zgłoszenie zanim zapytasz – być może ktoś już znalazł rozwiązanie.
-Jeśli masz więcej niż jedno pytanie, utwórz dla każdego z nich osobny post dla zachowania porządku.
+Jeśli masz kilka pytań, utwórz oddzielne posty. Nie zadawaj niezwiązanych pytań w tym samym wątku.
### Wymagane informacje
-Nie będziemy mogli udzielić Ci pomocy jeśli nie podasz paru ważnych informacji:
+Nie będziemy mogli udzielić pomocy, jeśli nie przekażesz potrzebnych informacji:
**Tytuł**
-Post musi mieć krótki i opisujący problem tytuł. Dobrymi przykładami są "How do I move a game object in the direction it is rotated?" lub "How do I fade out a sprite?". Złymi przykładami natomiast są "I need some help using Defold!" albo "My game is not working!".
+Użyj krótkiego i konkretnie opisującego problem tytułu. Dobry tytuł to np. „How do I move a game object in the direction it is rotated?” albo „How do I fade out a sprite?”. Zły tytuł to „I need some help using Defold!” albo „My game is not working!”.
-**Opisz problem (WYMAGANE)**
-Jasny i dokładny opis problemu.
+**Opisz błąd (WYMAGANE)**
+Jasny i zwięzły opis tego, co jest nie tak.
**Odtworzenie problemu (WYMAGANE)**
-Kroki, które trzeba wykonać, aby zreprodukować problem, np:
- 1. Przejdź do '...'
- 2. Kliknij na '...'
- 3. Przewiń do '...'
- 4. Zobaczysz błąd
-
-(Oczywiście po angielsku np:
- 1. Go to '...'
- 2. Click on '....'
- 3. Scroll down to '....'
- 4. See error
-)
+Kroki prowadzące do odtworzenia zachowania (raportuj najlepiej w języku angielskim):
+1. Go to '...'
+2. Click '....'
+3. Scroll down to '....'
+4. See error
**Oczekiwane zachowanie (WYMAGANE)**
-Jasny i zwięzły opis czego oczekujesz po prawidłowym zachowaniu silnika/gry.
+Jasny opis tego, co powinno się wydarzyć.
-**Wersja Defolda (WYMAGANE):**
- - np: [Version 1.2.155]
+**Wersja Defold (WYMAGANE):**
+ - Version [e.g. 1.2.155]
**Sprzęt i system operacyjny (WYMAGANE):**
- - Platforms: [np. iOS, Android, Windows, macOS, Linux, HTML5]
- - OS: [np. iOS8.1, Windows 10, High Sierra]
- - Device: [np. iPhone6]
+ - Platforms: [e.g. iOS, Android, Windows, macOS, Linux, HTML5]
+ - OS: [e.g. iOS8.1, Windows 10, High Sierra]
+ - Device: [e.g. iPhone6]
-**Repro case - mały projekt z reprodukcją błędu (OPCJONALNIE):**
-Możesz dołączyć mały, zrobiony na szybko projekt Defold, w którym podstawowe elementy są odtworzone w taki sposób, jak w Twoim głównym projekcie, przez co pojawia się ten sam błąd. Załączenie takiego projektu z pewnością znacząco ułatwi i przyspieszy jego rozwiązanie.
+**Minimal reproduction case project (OPCJONALNIE):**
+Dołącz minimalny projekt, który odtwarza błąd. Ułatwia to diagnozę i naprawę.
**Logi (OPCJONALNIE):**
-Dołącz proszę ważne logi silnika, edytora lub serwera do budowania, które pojawiają się w konsoli lub są zapisywane do pliku: [tutaj](#log-files).
+Dodaj istotne logi z silnika, edytora lub serwera budowania. Dowiedz się, gdzie się znajdują, [tutaj](#log-files).
-**Workaround - obejście problemu (OPCJONALNIE):**
-Jeśli znasz jakikolwiek sposób na poradzenie sobie z problemem w inny, sprytny sposób, opisz go proszę w poście.
+**Workaround (OPCJONALNIE):**
+Jeśli znasz tymczasowe obejście, opisz je w poście.
-**Screenshots - zrzuty ekranu (OPCJONALNIE):**
-Jeśli zdjęcia jasno pokazują problem, możesz śmiało zamieścić je w poście.
+**Screenshots (OPCJONALNIE):**
+Jeśli obrazy pomagają wyjaśnić problem, dołącz je.
-**Dodatkowy kontekst (OPCJONALNIE):**
-Jeśli są jeszcze jakiekolwiek inne kwestie warte poruszenia, śmiało dopisz je.
+**Additional context (OPCJONALNIE):**
+Dodaj dowolny inny kontekst dotyczący problemu.
-## Zgłoś problem z poziomu Edytora Defold
+### Udostępnianie kodu
+Kiedy dzielisz się kodem, lepiej zamieścić go jako tekst zamiast zrzutu ekranu. Dzięki temu można go przeszukać, łatwiej wskazać błędy i zaproponować poprawki. Umieść kod wewnątrz potrójnych backticków (```) albo wcięciu o 4 spacje.
-Edytor umożliwia w łatwy sposób zgłosić problem. Wybierz Help->Report Issue.
+Przykład:
+
+print("Hello code!")
+
+Efekt:
+
+```
+print("Hello code!")
+```
+
+## Zgłoś problem z poziomu Edytora
+
+Edytor umożliwia wygodne zgłoszenie problemu. Wybierz Help->Report Issue z poziomu edytora, aby zgłosić błąd.
-Wybranie tej opcji przeniesie Cię do strony ze śledzeniem zgłoszeń błędów na GitHubie. Dodaj [plik z logami](#log-files), informacje o Twoim sprzęcie i systemie operacyjnym, opisz kroki, które trzeba wykonać, aby zreprodukować problem, możliwe obejście itd.
+Wybranie tej opcji przeniesie Cię do strony zgłoszeń na GitHubie. Dołącz [pliki z logami](#log-files), informacje o systemie operacyjnym, kroki odtwarzające problem, możliwe obejście itd.
::: sidenote
Musisz mieć konto na GitHubie, żeby zgłosić problem w ten sposób.
:::
-## Przedysktuj problem na Discord
+## Przedyskutuj problem na Discord
-W razie problemów możesz również zadać pytanie na oficjalnym [Discord](https://www.defold.com/discord/), jednak pamiętaj, że zalecamy, aby skomplikowane kwestie i dogłębne dyskusje prowadzić na forum. Pamiętaj też, że nie przyjmujemy zgłoszeń bugów, problemów przez Discord.
+Jeśli napotkasz problem podczas korzystania z silnika Defold, możesz spróbować zadać pytanie na [Discord](https://www.defold.com/discord/). Zalecamy jednak, żeby złożone pytania i głębsze dyskusje prowadzić na forum. Nie przyjmujemy zgłoszeń błędów przesyłanych przez Discord.
-# Logi
+# Log files
-Silnik, Edytor i serwer do budowania Defolda generują logi (informacje), które mogą być bardzo przydatne podczas rozwiązywania problemów. Zawsze dodawaj pliki z logami do zgłaszanego problemu, których lokalizację możesz sprawdzić poniżej:
+Silnik, edytor i serwer budowania generują logi, które bardzo pomagają przy zgłaszaniu i rozwiązywaniu problemów. Zawsze dołącz pliki z logami, gdy zgłaszasz problem:
-* [Logi Silnika](/manuals/debugging-game-and-system-logs)
-* Logi Edytora
- * Windows: `C:\Users\ **Your Username** \AppData\Local\Defold`
- * macOS: `/Users/ **Your Username** /Library/Application Support/` or `~/Library/Application Support/Defold`
- * Linux: `~/.Defold`
-* [Logi serwera do budowania](/manuals/extensions#build-server-logs)
+* [Engine logs](/manuals/debugging-game-and-system-logs)
+* [Editor logs](/manuals/editor#editor-logs)
+* [Build server logs](/manuals/extensions#build-server-logs)
diff --git a/docs/pl/manuals/glossary.md b/docs/pl/manuals/glossary.md
index d3d7025f..b6f3da56 100644
--- a/docs/pl/manuals/glossary.md
+++ b/docs/pl/manuals/glossary.md
@@ -1,180 +1,172 @@
---
title: Słowniczek Defold
-brief: Słowniczek ten zawiera wszystkie terminy używane w środowisku Defold z krótkimi opisami.
+brief: Ten słowniczek zawiera terminy Defold z krótkimi objaśnieniami.
---
# Słowniczek Defold
-Słowniczek ten zawiera krótkie opisy i wyjaśnienia wszystkich terminów jakie spotkasz w środowisku Defold. W większości przypadków znajdziesz też linki do bardziej szczegółowych opisów. (Pozostawiam nazwy pojęć w oryginale, natomiast w nawiasie przedstawiam polskie tłumaczenie - przyp. tłum.)
+Ten słowniczek udziela krótkich wyjaśnień dla terminów, które napotkasz podczas pracy z silnikiem Defold. W większości przypadków zamieszczamy też odnośniki do obszerniejszych opisów.
## Animation set (Zestaw do animowania)
-{.left} Zestaw do animowania zawiera listę plików .dae lub innych .animationset, z których odczytywać można animacje. Dodawnia jednego pliku .animationset do drugiego jest wygodne przy udostępnianiu części animacji wielu modelom. Więcej szczegółów znajdziesz w [instrukcji do grafiki 3D](/manuals/graphics/).
+{.left} Zestaw do animowania zawiera listę plików `.dae` lub innych plików `.animationset`, z których odczytywane są animacje. Dodawanie jednego pliku `.animationset` do drugiego jest przydatne, gdy chcesz udostępnić fragmenty animacji kilku modelom. Szczegóły znajdziesz w [instrukcji do animacji modeli 3D](/manuals/model-animation/).
## Atlas (Galeria obrazów)
-{.left} Atlas (Galeria) jest zestawem zawierającym oddzielne obrazy/sprite'y, które są skomponowane w jeden większy arkusz z powodów wydajności i zarządzania pamięcią. Mogą zawierać statyczne obrazki lub klatki animacji poklatkowej (typu flip-book). Zestawy te są używane zarówno w systemie GUI, do komponentów typu sprite, spine model czy particleFX. Więcej szczegółów znajdziesz w [dokumentacji do Atlasów](/manuals/atlas).
+{.left} Atlas to zbiór osobnych obrazów skompilowanych w większy arkusz, co poprawia wydajność i oszczędza pamięć. Atlasy mogą zawierać statyczne grafiki lub zestawy klatek animacji poklatkowej. Różne komponenty korzystają z atlasów, aby współdzielić zasoby graficzne. Więcej w [dokumentacji do Atlasów](/manuals/atlas).
## Builtins (Wbudowane elementy)
-{.left} Folder builtins Twojego projektu zawiera użyteczne, domyślne zasoby, możliwe tylko do odczytu. Znajdziesz tutaj domyślny renderer i skrypt do renderowania (tworzenia i wyświetlania grafiki), materiały i wiele więcej. Jeśli chcesz przeprowadzić modyfikacje takich zasobów, po prostu skopiuj je do swojej lokalizacji i edytuj wedle uznania.
+{.left} Folder `builtins` w projekcie zawiera domyślne, tylko do odczytu zasoby. Znajdziesz tam domyślny renderer, skrypt renderujący, materiały i inne elementy. Jeśli potrzebujesz zmodyfikować któryś z tych zasobów, skopiuj go do projektu i edytuj według potrzeb.
## Camera (Kamera)
-{.left} Komponent typu kamera pomaga decydować, które fragmenty świata gry zostaną wyświetlone i w jaki sposób. Jednym z częstszych zastosowań kamery jest przyeczepienie jej to obiektu gracza, lub osobnego obiektu podążającego za obiektem gracza, aby podążąć widokiem za jego ruchem, np. z dodatkowym algorytmem wygładzającym ruch. Więcej szczegółów znajdziesz w [dokumentacji do Kamery](/manuals/camera).
+{.left} Komponent kamery decyduje, która część świata gry ma być widoczna i jak ma być rzutowana. Powszechną praktyką jest przypinać kamerę do obiektu gracza albo tworzyć osobny obiekt, który podąża za graczem z dodatkowym wygładzaniem. Więcej w [dokumentacji do Kamery](/manuals/camera).
-## Collision object (Obiekty kolizji)
+## Collision object (Obiekt kolizji)
-{.left} Obiekty kolizji są komponentami umożliwiającymi zdefiniowanie właściwości fizycznych obiektów (takich jak kształt kolizji, wagę, współczynnik tarcia czy tłumienia). Właściwości te określają jak obiekty kolizji powinny reagować na zderzenie z innymi obiektami. Najpopularniejszym typem kolizji są kolizje obiektów kineamtycznych, dynamicznych or triggery (przełączniki/aktywatory). Obiekt kinematyczny daje szczegółowe informacje Tobie w wiadomości zwrotnej po kolizji i możesz je wykorzystać w dowolny sposób. Natomiast obiekt dynamiczny automatycznie jest rozwiązywany przez silnik fizyczny w zgodzie z prawami Newtonowskiej fizyki klasycznej. Triggery (przełączniki) są prostymi obiektami, które informują Cię jedynie czy w danej chwili weszły w kolizję z innymi obiektami, bądź z takiej kolizji wyszły. Więcej szczegółów znajdziesz w [dokumentacji do Fizyki](/manuals/physics).
+{.left} Obiekty kolizji rozszerzają obiekty gry o właściwości fizyczne, takie jak kształt przestrzenny, masa, tarcie i tłumienie. To one decydują, jak dany obiekt reaguje na kontakt z innymi. Najczęściej spotykane typy to obiekty kinematyczne, dynamiczne i wyzwalacze. Kinematyczny obiekt dostarcza szczegółowe informacje o kolizji, które możesz obsłużyć ręcznie, dynamiczny obiekt jest symulowany przez silnik fizyki zgodnie z prawami Newtona, a wyzwalacze wykrywają tylko wejście lub wyjście innych kształtów. Szczegóły w [dokumentacji do Fizyki](/manuals/physics).
## Component (Komponent)
-Komponenty pozwalają nadać obiektowi gry specyficzne właściwości lub funkcjonalności, jak na przykład reprezentację graficzną, tekstową, dźwiękową czy skrypt definiujący zachowanie obiektu. Muszą być częścią innego obiektu, nie mogą zostać utworzone w grze same, za to mogą być w ramach danego obiektu aktywowane i dezaktywowane. W silniku Defold jest wiele różnych typów komponentów - ich listę i opisy znajdziesz w [instrukcji do Komponentów](/manuals/building-blocks).
+Komponenty nadają obiektom gry konkretną ekspresję lub funkcjonalność, na przykład grafikę, animację, zachowanie zdefiniowane skryptem czy dźwięk. Nie żyją osobno — muszą należeć do obiektów gry. W silniku Defold dostępnych jest wiele rodzajów komponentów, opisanych w [instrukcji o blokach budujących](/manuals/building-blocks).
## Collection (Kolekcja)
-{.left} Kolekcje są mechanizmem w Defoldzie na tworzenie szablonów ("blueprintów" czy też "prefabów", jak w innych silnikach), w ramach których można wykorzystywać daną hierarchię obiektów gry. Kolekcję są plikami ze strukturą drzewa przetrzymującą w sobie obiekty gry i inne kolekcje. Są umieszczane w grzze statycznie, na poziomie edytora lub dynamicznie przez fabrykę kolekcji. Więcej szczegółów znajdziesz w [instrukcji do Komponentów](/manuals/building-blocks).
+{.left} Kolekcje to mechanizm pozwalający tworzyć szablony (prefaby) zawierające hierarchie obiektów gry. Są strukturami drzewa przechowującymi obiekty gry i inne kolekcje. Kolekcje przechowywane są jako pliki i wprowadza się je do gry statycznie przez edytor lub dynamicznie przez generowanie. Więcej w [instrukcji o blokach budujących](/manuals/building-blocks).
## Collection factory (Fabryka kolekcji)
-{.left} Fabryka kolekcji jest używana do utworzenia dynamicznie instancji obiektów gry zgodnie z opisaną w kolekcji hierarchią. Więcej szczegółów znajdziesz w [instrukcji do Fabryki kolekcji](/manuals/collection-factory).
+{.left} Fabryka kolekcji pozwala dynamicznie tworzyć hierarchie obiektów gry zgodne z opisem w kolekcji. Szczegóły w [instrukcji do Fabryki kolekcji](/manuals/collection-factory).
## Collection proxy (Pełnomocnik kolekcji)
-{.left} Pełnomocnik kolekcji jest używany do wczytywania i aktywowania kolekcji dynamicznie w zależności od potrzeby w czasie działania programu. Przykładem najczęstszego wykorzystania jest użycie pełnomocników do wczytywania poziomów gry. Więcej szczegółów znajdziesz w [dokumentacji do Pełnomocnika kolekcji](/manuals/collection-proxy).
+{.left} Pełnomocnik kolekcji służy do ładowania i aktywowania kolekcji w trakcie działania aplikacji. Najczęściej używa się go do wczytywania kolejnych poziomów. Zobacz [dokumentację do Pełnomocników kolekcji](/manuals/collection-proxy).
## Cubemap (Tekstura sześcienna)
-{.left} Tekstura sześcienna (cubemap) jest specjalną teksturą składającą się z 6 różnych tekstur, które po "złożeniu" mogą utworzyć sześcian (siatka sześcianu). Jest używana do tworzenia tzw. skybox'ów, czyli nieba w grach 3D lub w różnych mapowaniach odbić i odblasków.
+{.left} Tekstura sześcienna (cubemap) to specjalny typ tekstury złożony z sześciu osobnych obrazów mapowanych na ściany sześcianu. Przydatna do renderowania skyboxów oraz map odbić i oświetlenia.
## Debugging (Debugowanie)
-Kiedy Twoja gra w pewnym momencie zachowuje się w nieoczekiwany sposób, musisz zrozumieć co się dokładnie dzieje i co jest tego przyczyną. Nauczenie się jak debugować jest sztuką, a Defold ułatwia debugowanie dostarczając zestaw gotowych narzędzi - wbudowany debugger. Więcej szczegółów znajdziesz w [instrukcji do Debugowania](/manuals/debugging).
+Kiedy gra zaczyna zachowywać się nieoczekiwanie, musisz odnaleźć przyczynę. Nauka debugowania jest sztuką, a Defold oferuje wbudowany debugger, który ułatwia to zadanie. Więcej w [instrukcji do Debugowania](/manuals/debugging).
## Display profiles (Profile wyświetlania)
-{.left} Profile wyświetlania określają zależności orientacji, współczynnika proporcji czy modelu i ułożenia elementów systemu interfejsu graficznego użytkownika (GUI). Pomaga to zaadaptować Twój interfejs do każdego urządzenia. Więcej szczegółów znajdziesz w [instrukcji do Layout'ów](/manuals/gui-layouts).
+{.left} Plik profilu wyświetlania pozwala określić układy GUI zależne od orientacji, proporcji obrazu lub modelu urządzenia. Dzięki temu można dostosować interfejs do różnorodnych ekranów. Więcej w [instrukcji do Układów](/manuals/gui-layouts).
## Factory (Fabryka)
-{.left} W pewnych przypadkach nie chcesz umieszczać wszystkich elementów w grze statycznie, tylko chcesz stworzyć je w trakcie działania proramu, dynamicznie. Na przykład, gracz może strzelać pociskami, z których każdy powinien być dynamicznie stworzony w momencie wystrzelenia. Do utworzenia obiektu gry dynamicznie (z pre-alokowanej puli obiektów) możesz użyć właśnie Fabryki. Więcej szczegółów znajdziesz w [instrukcji do Fabryki](/manuals/factory).
+{.left} Czasem nie chcesz tworzyć wszystkich obiektów gry ręcznie w kolekcji — potrzebujesz ich w czasie działania gry. Fabryka umożliwia dynamiczne tworzenie takich obiektów z wcześniej przygotowanej puli. Zobacz [instrukcję do Fabryki](/manuals/factory).
## Font (Czcionka)
-{.left} Plik Font jest budowany na podstawie plików TrueType lub OpenType i służy do określania wyświetlania w programie czcionki oraz dodatkowych efektów (obrysowanie, cienie) do celów renderowania tekstu. Fonty są używane przez komponenty typu GUI i Label (Etykieta). Więcej szczegółów znajdziesz w [instrukcji do Fontów](/manuals/font/).
+{.left} Zasób typu Font powstaje na podstawie pliku TrueType lub OpenType i określa rozmiar oraz dekoracje (np. obrys, cień) renderowanej czcionki. Fonty wykorzystują komponenty GUI i Label. Więcej w [instrukcji do Fontów](/manuals/font/).
## Fragment shader (Shader fragmentu)
-{.left} Shader to specjalny program, który jest uruchamiany na karcie graficznej dla każdego rysowanego piksela (fragmentu) w wielokącie (polygon) w momencie rysowania go na ekranie. The purpose of the fragment shader is to decide the color of each resulting fragment. This is done by calculation, texture lookups (one or several) or a combination of lookups and computations. Więcej szczegółów znajdziesz w [instrukcji do Shader'ów](/manuals/shader).
+{.left} Shader fragmentu to program uruchamiany na procesorze graficznym dla każdego piksela (fragmentu) rysowanego wielokąta. Określa kolor wynikowego fragmentu, wykonując obliczenia, odczyty tekstur lub ich kombinacje. Szczegóły w [instrukcji do Shaderów](/manuals/shader).
-## Gamepads (Kontroler)
+## Gamepads (Kontrolery)
-{.left} Plik Gamepads określa w jaki sposób wejścia określonych kontrolerów są mapowane na wejścia na daną platformę. Więcej szczegółów znajdziesz w [instrukcji do Wejść](/manuals/input).
+{.left} Plik Gamepads definiuje sposób mapowania wejść ze konkretnych kontrolerów na wyzwalacze wejścia dostępne dla danej platformy. Więcej w [instrukcji do Wejść](/manuals/input).
## Game object (Obiekt gry)
-{.left} Obiekt gry to najprostszy i podstawowy obiekt w Defoldzie, który ma osobny czas życia w trakcie wykonywanego programu i określone właściwości co do pozycji, orientacji i skali. Obiekt gry jest kontenerem mogącym posiadać innego komponenty (wizualne czy dźwiękowe) lub logikę (skrypt). Możesz tworzyć obiektu gry w edytorze, umieszczając ich instancje bezpośrednio w kolekcjach lub tworzyć je dynamicznie w trakcie działania programu pporzez fabryki. Więcej szczegółów znajdziesz w [instrukcji do Podstawowych elementów](/manuals/building-blocks).
+{.left} Obiekty gry to kontenery ze swoim cyklem życia podczas działania gry. Zazwyczaj zawierają komponenty wizualne albo dźwiękowe oraz mogą mieć zachowanie opisane skryptem. Tworzy się je w edytorze, umieszczając w kolekcjach, albo dynamicznie przez fabryki. Szczegóły w [instrukcji o blokach budujących](/manuals/building-blocks).
## GUI (Interfejs graficzny użytkownika)
-{.left} Interfejs graficzny użytkownika (ang. Graphical User Interface) jest komponentem używanym do skonstruowania elementów interfejsu w grze lub aplikacji: tekstu, przycisków, pasków, indykatorów i innych oteksturwanych bloków. Mogą one być zorganiozwane w hierarchii, oskryptowane i animowane. Komponenty GUI są typowo wykorzystywane do tworzenia HUD (ang. Head-up display), menu i innych informacji wyświetlanych na ekranie (np. paski życia, minimapy, opisy celów, itd.). Są kontrolowane przez specjalne skrypty GUI, które definiują ich zachowanie i odpowiadają na interakcję użytkownika z nimi. Więcej szczegółów znajdziesz w [dokumentacji do GUI](/manuals/gui).
+{.left} Komponent GUI zawiera elementy interfejsu: tekst, kolorowe lub teksturowane bloki. Elementy można organizować hierarchicznie, skryptować i animować. GUI służy do HUD, menu i powiadomień. Steruje nim skrypt GUI, który opisuje zachowanie i interakcje użytkownika. Więcej w [dokumentacji do GUI](/manuals/gui).
-## GUI script (skrypt GUI)
+## GUI script (Skrypt GUI)
-{.left} Skrypty interfejsu graficznego użytkownika są używane do kontrolowania zachowania komponentów GUI. Mogą przykładowo kontrolować animację tekstur na danych węzłach/elementach lub sposób w jaki użytkownik dokonuje interakcji z elementami. Więcej szczegółów znajdziesz w [instrukcji do skryptów w Defoldzie pisanych w języku Lua](/manuals/lua).
+{.left} Skrypty GUI kontrolują zachowanie komponentów GUI — animacje, reakcje na wejścia i inne interakcje. Zobacz [instrukcję o Lua w silniku Defold](/manuals/lua), aby dowiedzieć się, jak są wykorzystywane.
## Hot reload (Szybkie przeładowanie)
-Edytor Defold pozwala na szybkie zaktualizowanie już uruchomionej gry na pulpicie komputera lub ekranie smartfona bez przebudowywania całości. Taka opcja znacząco ułatwia proces tworzenia gier i aplikacji. Więcej szczegółów znajdziesz w [instrukcji do Hot reload](/manuals/hot-reload).
+Edytor Defold pozwala aktualizować zawartość w uruchomionym programie na desktopie i urządzeniach mobilnych. Ta funkcja przyspiesza pracę przy rozwoju gry. Więcej w [instrukcji do Hot reload](/manuals/hot-reload).
## Input binding (Wiązania wejść)
-{.left} Pliki z wiązaniami wejść określają w jaki sposób gra powinna interpretować wejścia sprzętowe (myszki, klawiatury, wejścia z ekranów dotykowych czy gamepadów). Plik ten wiąże wejścia sprzętowe z wysokopoziomowymi _akcjami_ takimi jak np. "skok" and "ruch_naprzód". W skryptach, które nasłuchują wejść można takie wydarzenia obsłużyć i wykonać wtedy dane akcje. Więcej szczegółów znajdziesz w [dokumentacji do Wejść](/manuals/input).
+{.left} Pliki wiązań wejść określają, jak interpretować sygnały z myszy, klawiatury, ekranu dotykowego czy gamepada. Wiążą sprzętowe wejścia z wysokopoziomowymi akcjami, takimi jak `jump` czy `move_forward`. Skrypty nasłuchujące wejść reagują na te akcje w sposób określony przez twórcę. Więcej w [instrukcji do Wejść](/manuals/input).
## Label (Etykieta)
-{.left} Komponent typu Etykieta umożliwia przypisanie tekstowego elementu do danego obiektu gry. Wyświetla on tekst w określonym foncie (czcionce) w przestrzeni gry (nie GUI). Więcej szczegółów znajdziesz w [instrukcji do Etykiet](/manuals/label).
+{.left} Komponent Label umożliwia przypisanie tekstu do obiektu gry. Renderuje go przy użyciu wybranego fontu, w przestrzeni gry (nie GUI). Więcej w [instrukcji do Etykiet](/manuals/label).
## Library (Biblioteka)
-{.left} Defold pozwala w łatwy sposób udostępnić zasoby i dane pomiędzy projektami poprzez mechanizm bibliotek. Możesz go używać do uzyskania dostępu do współdzielonych pomiędzy różnymi projektami bibliotek dla siebie lub członków Twojego zespołu. Więcej szczegółów znajdziesz w [dokumentacji do Bibliotek](/manuals/libraries).
+{.left} Defold pozwala współdzielić dane między projektami za pomocą bibliotek. Możesz z nich korzystać w wielu projektach, dla siebie lub zespołu. Szczegóły w [dokumentacji do Bibliotek](/manuals/libraries).
-## Lua language (język Lua)
+## Lua language (Język Lua)
-Lua jest językiem programowania wykorzystywanym przez Defold do tworzenia logiki gry. To potężny, wydajny i bardzo lekki język skryptowy. Wspiera programowanie proceduralne, funkcyjne, zorientowane obiektowo i na danych (data-driven) oraz opis danych. Więcej szczegółów na temat Lua znajdziesz na oficjalnej stronie języka: https://www.lua.org/ oraz w [instrukcji do skryptów w Defoldzie pisanych w języku Lua](/manuals/lua).
+Lua to język skryptowy wykorzystywany do tworzenia logiki gry w silniku Defold. Jest mały, wydajny i wspiera programowanie proceduralne, obiektowe, funkcyjne oraz data-driven. Więcej na oficjalnej stronie https://www.lua.org/ oraz w [instrukcji do Lua](/manuals/lua).
## Lua module (Moduł Lua)
-{.left} Moduły Lua pozwalają na stworzenie bibliotek, których można używać wielokrotnie i tym samym zdefiniowanie przejrzystej struktury projektu. Więcej szczegółów znajdziesz w [instrukcji do modułów Lua](/manuals/modules/)
+{.left} Moduły Lua pozwalają tworzyć struktury wielokrotnego użytku i czytelnie organizować kod. Więcej w [instrukcji do modułów Lua](/manuals/modules/).
## Material (Materiał)
-{.left} Materiały definiują jak obiekt ma być renderowany i wyświetlany poprzez wykorzystanie właściwości i odpowiednich programów wykonywanych na karcie graficznej - shaderów. . Więcej szczegółów znajdziesz w [instrukcji do Materiałów](/manuals/material).
+{.left} Materiały opisują sposób renderowania obiektów przez przypisanie shaderów i ich właściwości. Więcej w [instrukcji do Materiałów](/manuals/material).
## Message (Wiadomość)
-Komponenty komunikują się ze sobą poprzez wbudowany w Defolda system wiadomości. Komponenty mogą również automatycznie odpowiadać na pewne specjalne wiadomości, które mogą je aktywować/dezaktywować grafikę albo kolizje, uruchomić/zatrzymać animację, efekt cząsteczkowy czy dźwięk i wiele innych rzeczy. Silnik wykorzystuje wiadomości również do informowania komponentów o wydarzeniach (np. kolizacj silnika fizyki). System wiadomości musi znać odbiorcę danej wiadomości, aby ją do niego przesłać. Dlatego wszystko w czasie działania programu ma swój unikalny adres. Aby umożliwić komunikację między obiektami, Defold poszerza Lua o przesyłanie wiadomości i oddaje w ręce użytkowników zestaw potrzebnych funkcji.
+Komponenty komunikują się poprzez przesyłanie wiadomości silnika Defold. Mogą też automatycznie reagować na określone wiadomości, np. włączać/wyłączać grafikę, kolizje, animacje, efekty cząsteczkowe lub dźwięk. Silnik używa wiadomości do informowania o zdarzeniach, jak kolizje. System wiadomości potrzebuje odbiorcy, więc wszystko w grze ma unikalny adres. Aby ułatwić komunikację, Defold rozszerza Lua o mechanizm przechwytywania i wysyłania wiadomości oraz dostarcza przydatne funkcje.
-Na przykład, kod do ukrycia reprezentacji graficznej broni gracza (sprite "weapon") wygląda w Lua tak:
+Przykładowo, aby ukryć sprite `weapon`, wystarczy:
```lua
msg.post("#weapon", "disable")
```
-Gdzie, `"#weapon"` jest adresem komponentu obecnego obiektu (z którego wysłana jest ta wiadomość). `"disable"` jest właśnie treścią specjalnej wiadomości silnika, na którą odpowie sprite. Więcej szczegółów znajdziesz w [dokumentacji do przesyłania wiadomości](/manuals/message-passing).
+`"#weapon"` to adres komponentu, z którego wysyłana jest wiadomość, a `"disable"` to nazwa wiadomości, na którą reaguje sprite. Więcej w [dokumentacji do przesyłania wiadomości](/manuals/message-passing).
-## Model
+## Model (Model)
-{.left} Model jest rozwiązaniem do stworzenia obiektu 3D w Defoldzie z siatką Collada, szkieletem, teksturami i animacją. Więcej szczegółów znajdziesz w [instrukcji do Modeli](/manuals/model/).
+{.left} Komponent Model umożliwia import siatek, szkielety i animacje z formatu glTF do gry. Więcej w [instrukcji do Modeli](/manuals/model/).
## ParticleFX (Efekt cząsteczkowy)
-{.left} Efekty cząsteczkowe są szczególnymi efektami wizualnymi, które wykorzystują wiele elementów (cząsteczek) do stworzenia określonych efektów (np. dym, kurz, mgła, błyski, iskry, deszcz, plusk, ogień, spadające liście, gwiazdy, itd.). Defold zawiera potężny edytor efektów cząsteczkowych, który pozwala zbudować przeróżne efekty i dopasować je nawet podczas działania programu. Więcej szczegółów znajdziesz w [dokumentacji do ParticleFX](/manuals/particlefx).
+{.left} Efekty cząsteczkowe pomagają tworzyć wizualne efekty, takie jak mgła, ogień, deszcz czy spadające liście. Defold wyposażono w edytor ParticleFX, który pozwala budować i dopasowywać efekty w czasie rzeczywistym. Więcej w [dokumentacji do ParticleFX](/manuals/particlefx).
## Profiling (Profilowanie)
-Wysoka wydajność jest kluczowa w grach, więc dla deweloperów jest niezwykle ważne, żeby móc monitorować wydajność i pamięć Twojej gry i zidentyfikować wąskie gardła i problemy z pamięcią, które wymagają naprawy. Defold oddaje więc w ręce twórców zestaw narzędzi do profilowania. Więcej szczegółów znajdziesz w [instrukcji do Profilowania](/manuals/profiling).
+Dobra wydajność jest kluczowa, dlatego warto mierzyć wydajność i pamięć gry, aby wykryć wąskie gardła. Defold udostępnia narzędzia do profilowania. Szczegóły w [instrukcji do Profilowania](/manuals/profiling).
-## Render
+## Render (Render)
-{.left} Pliki typu Render zawierają ustawienia używane podczas renderowania i wyświetlania grafiki w Twojej grze. Definiują one, który skrypt do renderowania i jakie materiały będą wykorzystywane. Więcej szczegółów znajdziesz w [instrukcji do Renderowania](/manuals/render/).
+{.left} Pliki Render zawierają ustawienia używane podczas renderowania gry — określają, który render script i materiały mają być użyte. Więcej w [instrukcji do Renderowania](/manuals/render/).
-## Render script (skrypt do renderowania)
+## Render script (Skrypt do renderowania)
-{.left} Skrypt do renderowania jest specjalnym skryptem w języku Lua kontrolującym jak gra lub aplikacja jest renderowana i wyświetlana na ekranie urządzenia. Domyślnie projekt używa domyślnego skryptu renderowania, ale nic nie stoi na przeszkodzie, żeby używać innego lub własnego skryptu, wspierającego przykładowo oświetlenie czy inne efekty wizualne. Więcej szczegółów znajdziesz w [instrukcji do Renderowania](/manuals/render/) oraz w [instrukcji do skryptów w Defoldzie pisanych w języku Lua](/manuals/lua) for details on how Lua scripts are used in Defold.
+{.left} Skrypt do renderowania to skrypt Lua sterujący tym, jak gra jest renderowana na ekranie. Domyślny skrypt pokrywa większość scenariuszy, ale możesz napisać własny, jeśli potrzebujesz niestandardowych efektów lub oświetlenia. Więcej w [instrukcji do Renderowania](/manuals/render/) oraz w [instrukcji do Lua](/manuals/lua).
## Script (Skrypt)
-{.left} Skrypt jest komponentem zawierającym w sobie program (kod w języku Lua), który definiuje zachowanie obiektu. Dzięki skryptom można określić zasady gry, sztucznej inteligencji, odpowiedzieć na interakcję użytkownika lub z innymi obiektami albo zaktualizować stan świata gry. Żeby sprawnie pracować z silnikiem Defold, Ty lub ktokolwiek z Twojego zespołu musi zaznajomić się z programowaniem w Lua. Więcej szczegółów znajdziesz w [instrukcji do skryptów w Defoldzie pisanych w języku Lua](/manuals/lua).
+{.left} Skrypt to komponent zawierający kod, który definiuje zachowanie obiektu gry. Dzięki skryptom ustalasz reguły gry, reagujesz na interakcje i aktualizujesz stan świata. Wszystkie skrypty pisze się w Lua — aby pracować z silnikiem Defold, ty lub ktoś z zespołu musi poznać ten język. Więcej w [instrukcji do Lua](/manuals/lua).
## Sound (Dźwięk)
-{.left} Komponent dźwiękowy jest odpowiedzialny za odtwarzanie określonego pliku dźwiękowego. Obecnie Defold wspiera formaty WAV i OGG Vorbis. Więcej szczegółów znajdziesz w [instrukcji do Dźwięków](/manuals/sound).
-
-## Spine model (Model szkieletowy)
-
-{.left} Model szkieletowy wykorzystuje animację szkieletową Spine do tworzenia animacji w Defoldzie. Więcej szczegółów znajdziesz w [instrukcji do modeli Spine](/manuals/spinemodel).
-
-## Spine scene (Scena Spine)
-
-{.left} Scena Spine to specjalnyu zasób, który wiąże format Spine JSON i Defoldowy plik Atlas (galerię obrazów), aby zapełnić kości szkieletu animacji odpowiednimi grafikami. Więcej szczegółów znajdziesz w [instrukcji do animacji szkieletowej Spine](/manuals/spine).
+{.left} Komponent dźwiękowy odtwarza określony plik audio. Defold wspiera formaty WAV i Ogg Vorbis. Więcej w [instrukcji do Dźwięków](/manuals/sound).
## Sprite (Obraz)
-{.left} Sprite nadaje obiektowi gry reprezentację wizualną z wykorzystaniem pojedynczej (animowanej) grafiki. Wyświetla obraz albo z pliku Tile source albo z pliku Atlas. Sprite'y mają wbudowane wsparcie dla animacji poklatkowych (flip-book) i szkieletowych. Są najczęściej używane do przedstawienia postaci i obiektów w grach 2D.
+{.left} Sprite to komponent graficzny, który wyświetla obraz z Tile source lub Atlasu. Obsługuje animacje poklatkowe i oparte na kościach. Sprite’y najczęściej reprezentują postacie i przedmioty w grach 2D.
## Texture profiles (Profile teksturowania)
-{.left} Profile teksturowania używane są podczas procesu pakowania (bundling), aby automatycznie dostosować i skompresować obrazy (w Atlasach, źródłach kafelków (Tile sources), siatkach sześcianowych (Cubemaps) i pojedynczych teksturach używanych do modeli czy GUI, etc). Więcej szczegółów znajdziesz w [instrukcji do Profili teksturowania](/manuals/texture-profiles).
+{.left} Profile teksturowania używane są podczas bundlingu, aby automatycznie przetwarzać i kompresować dane obrazowe (w atlasach, Tile sources, cubemapach i osobnych teksturach używanych w modelach czy GUI). Więcej w [instrukcji do Profili teksturowania](/manuals/texture-profiles).
## Tile map (Mapa kafelków)
-{.left} Mapa kafelków wyświetla obrazy z określonego źródła kafelków (tile source) na jednej lub więcej siatkach. Są najczęściej używane do tworzenia środowisk w grach: poziomów, ścian, budynków, przeszkód, jaskiń, etc. Tile map może wyświetlać kilka warstw, jedna nad drugą, w określony sposób (blend mode). Jest to przydatne, żeby np. umieścić liście czy trawę nad kafelkami w tle. Jest również możliwa dynamiczna podmiana obrazka każdego kafelka osobno, co umożliwia, przykładowo, zniszczenie mostu, zastępując odpowiednie kafelki mostu ich zniszczonymi wersjami oraz podmienienie kształtu fizycznych kolizji (stworzenie przerwy w moście). Więcej szczegółów znajdziesz w [dokumentacji do Tile map](/manuals/tilemap).
+{.left} Mapa kafelków wyświetla obrazy z Tile source na jednej lub kilku warstwach siatki. Można używać jej do tworzenia poziomów, ścian, budynków, przeszkód czy jaskiń. Obsługuje wiele warstw w różnych trybach mieszania i pozwala na dynamiczną podmianę pojedynczych kafelków (np. żeby zniszczyć most i zmienić kolizje). Więcej w [dokumentacji do Tile map](/manuals/tilemap).
-## Tile source (Galeria kafelków)
+## Tile source (Źródło kafelków)
-{.left} Źródło/galeria kafelków podobnie jak Atlas opisuje teksturę stworzoną z wielu mniejszych obrazów o tych samych wymiarach, tzw. kafelków (ang. tiles). Można zdefiniować tutaj animacje poklatkowe (flip-book) z sekwencji występujących po sobie kolejno obrazków/kafelków. Galerie kafelków pomagają również automatycznie tworzyć kształty kolizji na podstawie danego obrazka, co znacznie ułatwia tworzenie poziomów w grach i od razu stworzenie kształtu kolizji całego poziomu. Galerie kafelków są używane w Mapach kafelków (Tile Map), ale również mogą być użyte jako tekstura do Sprite'ów i efektów cząsteczkowych (ParticleFX). Więcej szczegółów znajdziesz w [dokumentacji do Tile map](/manuals/tilemap).
+{.left} Tile source to tekstura składająca się z wielu mniejszych obrazów tej samej wielkości, czyli kafelków. Można z niej tworzyć animacje poklatkowe, a także automatycznie generować kształty kolizji. Tile source używa się w Tile mapach, ale też jako teksturę do sprite’ów i efektów cząsteczkowych. Więcej w [dokumentacji do Tile map](/manuals/tilemap).
## Vertex shader (Shader wierzchołków)
-{.left} Shader wierzchołków to specjlany program wykonywany na karcie graficznej, którego zadaniem jest przetwarzanie trójwymiarowej geometrii elementarnych kształtów - wielokątów (ang. polygon) na ekran urządzenia. Dla każego elementu wizualnego (sprite, model Spine czy 3D) kształt jest reprezentowant przez zestaw wielokątów z określonymi pozycjami wierzchołków w przestrzeni. Shader wierzchołków przetwarza każdy z wierzchołków w przestrzeni i oblicza wynikowe współrzędne na ekranie. Więcej szczegółów znajdziesz w [instrukcji do Shader'ów](/manuals/shader).
+{.left} Shader wierzchołków to program uruchamiany na GPU, który przetwarza geometrię siatek (wielokąty) i oblicza końcowe pozycje wierzchołków na ekranie. Więcej w [instrukcji do Shaderów](/manuals/shader).
diff --git a/docs/pl/manuals/introduction.md b/docs/pl/manuals/introduction.md
index f6a611ec..2bdf9ba4 100644
--- a/docs/pl/manuals/introduction.md
+++ b/docs/pl/manuals/introduction.md
@@ -1,36 +1,36 @@
---
-title: Defold - Wprowadzenie
-brief: Krótki wstęp do Defolda
+title: Wprowadzenie do silnika Defold
+brief: Krótki wstęp do silnika Defold.
---
-# Witamy w Defoldzie!
+# Witamy w Defold
-Defold jest gotową platformą przeznaczoną do profesjonalnej produkcji gier, ułatwiającą zespołom deweloperów projektować, budować i _wydawać_ gry na wspierane platformy. Defold skupia się na stworzeniu ogólnego środowiska, oddając Ci w ręce wszystkie podstawowe elementy, bez wprowadzania zbędnych, skomplikowanych obiektów. Wierzymy, że siłą Defolda jest danie użytkownikom zestawu prostych, ale potężnych narzędzi, które umożliwiają wspólną pracę nad grą. Listę oferowanych możliwości silnika znajdziesz tutaj: [Product Overview](/product).
-Spędziliśmy mnóstwo czasu nad udoskonaleniem komponentów silnika i uproszczeniem procesu tworzenia gier, co nas wyróżnia. Zobacz [dlaczego uważamy, że warto używać Defolda](/why)
+Defold to kompletne rozwiązanie, które oddaje w ręce twórców gry wszystkie potrzebne narzędzia, od projektowania po wdrożenie. Pełna lista możliwości platformy jest dostępna na stronie [przeglądu możliwości silnika Defold](/product).
-## Gdzie rozpocząć?
+Spędziliśmy dużo czasu na uproszczeniu kluczowych elementów procesu tworzenia gier, tak aby praca w silniku Defold była możliwie sprawna. Uważamy, że właśnie to wyróżnia Defold, dlatego zachęcamy do zapoznania się z powodami, dla których uznajemy go za dobry wybór. Szczegóły znajdziesz na stronie [dlaczego uważamy, że warto używać silnika Defold](/why).
-Zachęcamy do eksperymentowania i podążania za tutorialami, czytania instrukcji i dokumentacji API oraz do aktywności na naszym forum, gdzie użytkownicy i twórcy silnika pomogą Ci z każdym zagadnieniem dotyczącym silnika. Defold jest rozwijany nieustannie i co miesiąc wypuszczana jest nowa wersja, która jest kompatybilna wstecz, więc aktualizacja nie powinna powodować błędów w Twoim obecnym projekcie.
-Na stronach Defolda znajdziesz mnóstwo dokumentacji, instrukcji, przykładów i tutoriali. Jeśli nie wiesz od czego zacząć, poniżej przedstawiamy szybką listę:
+## Od czego zacząć?
-#### Edytor Defold
-{.left} [Instrukcja do edytora Defold](/manuals/editor/) opisuje edytor i pozwala Ci szybko zacząć swobodne poruszanie się w środowisku, używać narzędzi wizualnych i pisać kod. Jeśli jesteś zaznajomiony z innymi IDE lub programami do modelowania 3D część rzeczy może Cię zaskoczyć, ale zazwyczaj jest tak właśnie, że wygląd i funkcje różnią się między programami.
+Zachęcamy do eksperymentowania, korzystania z tutoriali, czytania podręczników i dokumentacji API oraz do udziału w forum, by uczyć się od innych użytkowników i śledzić rozwój silnika Defold. Na stronie znajduje się sporo materiałów: podręczniki, referencje API, przykłady i przeglądy technologii. Jeśli czujesz się zagubiony, poniżej znajdziesz kilka wskazówek, od czego zacząć:
+
+#### Edytor
+{.left} [Przegląd edytora](/manuals/editor/) przedstawia podstawy korzystania z edytora, pomoże Ci rozpoznać elementy interfejsu, obsługiwać narzędzia wizualne i pisać kod. Jeżeli znasz inne środowiska programistyczne lub aplikacje do modelowania 3D, większość rzeczy będzie Ci znajoma, choć pewne detale mogą wyglądać inaczej.
#### Proste przykłady
-{.left} [Nasz zestaw prostych przykładów](/examples/) to dobre miejsce na start i zrozumienie jak składać małe elementy razem w coś, co działa. Znajdziesz tam funkcje i operacje w Defoldzie w minimaljnej formie.
+{.left} [Nasz zbiór prostych przykładów](/examples/) pokazuje, jak łączyć elementy silnika Defold w działające rozwiązania. Znajdziesz tam minimalne przykłady popularnych mechanik, dzięki którym łatwiej zrozumiesz, jak pracować z poszczególnymi komponentami.
#### Język Lua
-{.left} [Defold wykorzystuje język Lua](/manuals/lua/) do tworzenia logiki gry. Silnik jest natomiast napisany w języku C++ i zoptymalizowany do szybkiego wykonywania zadań. Jeśli programowałeś już w Pythonie, Javascripcie lub innym wysoko poziomowym języku, Lua powinna być dla Ciebie prosta do zrozumienia i nauczenia się i bez problemu powinieneś móc przejść do tutoriali dotyczących bezpośrednio Defolda. W innym przypadku, warto najpierw przeczytać instrukcję języka Lua.
+{.left} [Defold używa języka Lua](/manuals/lua/) do implementacji logiki. Silnik jest napisany w C++, ale sterujesz nim z poziomu Lua. Jeśli programowałeś już w Pythonie, JavaScripcie lub innym języku wysokiego poziomu, nauka Lua powinna być prosta i szybko poradzisz sobie z kolejnymi tutorialami. W przeciwnym razie warto zacząć od podręcznika do Lua.
#### Tutoriale gier
-{.left} Wierzymy, że najlepiej uczy się przez tworzenie. Przygotowaliśmy więc zbiór tutoriali na różnych poziomach zaawansowania, dostępnych bezpośrednio z poziomu [edytora](/manuals/editor/). Uruchom je i podążaj za instrukcjami, aby szybko nauczyć się jak budować rzeczy i jak działa Defold.
+{.left} Uczysz się najlepiej, robiąc coś samodzielnie. Dlatego w [edytorze](/manuals/editor/) znajdziesz zestaw tutoriali o różnym poziomie trudności. Uruchom jeden z nich i przechodź kolejne kroki, aby zobaczyć, jak budować projekty i jak działa Defold.
-#### Podstawowe elementy
-{.left} [Defold wykorzystuje kilka podstawowych elementów do budowania aplikacji](/manuals/building-blocks/), niektóre z nich mogą Ci się wydać już znajome lub analogiczne do elementów z innych silników. Jest kilka decyzji związanych z architekturą silnika Defold, które sprawiają, że te elementy mają specyficzny charakter, więc może zająć chwilę, aby czuć się z nimi komfortowo i używać ich w naturalny sposób. Służy to jednak zoptymalizowaniu tworzenia gier na silniku Defold. Nasza instrukcja dotycząca tych bloków to dobre miejsce, aby zacząć rozumieć koncepty Defolda i dowiedzieć się jak to dokładnie działa.
+#### Podstawowe elementy silnika Defold
+{.left} [Gry w silniku Defold buduje się przez składanie prostych elementów](/manuals/building-blocks/), a niektóre pojawiają się też w innych silnikach. Istnieją jednak decyzje architektoniczne, które nadają naszym blokom specyficzny charakter, więc może minąć chwilę, zanim poczujesz się z nimi swobodnie. Instrukcja dotycząca podstawowych elementów to dobry punkt wyjścia, jeśli chcesz zrozumieć, jak działa silnik Defold.
#### Forum
-{.left} [Uczenie się od innych użytkowników](//forum.defold.com/) jest również często najlepszym sposobem na naukę. Nasza społeczność jest bardzo przyjazna, otwarta i wie dużo na temat tworzenia gier w ogólności, a także w szczególności na silniku Defold. Jeśli kiedykolwiek utkniesz, nie wahaj się, aby zapytać o rozwiązanie Twojego problemu na forum. (Będziesz musiał kontaktować się w języku angielskim, ale na forum, discordzie czy slacku możesz znaleźć kogoś, kto zna język polski w razie problemów - przyp. tłumacza)
+{.left} [Uczenie się od innych](//forum.defold.com/) często jest najskuteczniejszym sposobem na naukę. Nasza społeczność jest przyjazna i zna się na tworzeniu gier w ogóle, a szczególnie na pracy z Defold. Jeśli utkniesz, śmiało zajrzyj na forum i poproś o pomoc.
-Pamiętaj, że niezależnie od Twojego podejścia do nauki Defolda możesz zawsze wrócić tutaj i poszukać na stronie szczegółów dotyczące różnych operacji i konceptów. Nie wahaj się wskazywać nam rzeczy, któych nie jesteś w stanie zrozumieć lub uważasz, że nie są prawidłowe. Wszystkie te instrukcje są dla Ciebie i będziemy pracować nad tym, żeby dopasować je do Twoich potrzeb.
+Pamiętaj, że bez względu na to, jaką ścieżkę wybierzesz, zawsze możesz wrócić do tego podręcznika po dokładniejsze wyjaśnienia dotyczące funkcji i konceptów silnika Defold. Nie wahaj się zgłaszać, kiedy coś wydaje się niejasne lub nieprawidłowe — te strony są dla Ciebie i chcemy, żeby były jak najbardziej pomocne.
-Mamy nadzieję, że będziesz się cieszyć tworząc Twoją wymarzoną grę w Defoldzie!
+Mamy nadzieję, że tworzenie kolejnej świetnej gry w silniku Defold sprawi Ci satysfakcję!
diff --git a/docs/pl/manuals/libraries.md b/docs/pl/manuals/libraries.md
index 9dd048c3..ab3cd35b 100644
--- a/docs/pl/manuals/libraries.md
+++ b/docs/pl/manuals/libraries.md
@@ -1,60 +1,128 @@
---
-title: Praca z bibliotekami w Defoldzie
-brief: Biblioteki pozwalają na dzielenie zasobów między projektami. Ta instrukcja opisuje jak działają.
+title: Praca z bibliotekami w Defold
+brief: Funkcja bibliotek pozwala dzielić zasoby między projektami. Ten podręcznik wyjaśnia, jak to działa.
---
-# Biblioteki
+# Biblioteki (Libraries)
-Biblioteki pozwalają na dzielenie zasobów między projektami. To proste, ale i potężne narzędzie, które możesz używać na wiele sposobów.
+Funkcja Bibliotek pozwala dzielić zasoby między projektami. To proste, ale bardzo potężne narzędzie, które możesz wykorzystać na wiele sposobów.
-Biblioteki są przydatne, kiedy chcesz:
+Biblioteki są przydatne w następujących sytuacjach:
-* skopiować zasoby z jednego projektu do innego. Przykładowo, gdy tworzysz sequel swojej wcześniejszej gry, to bardzo łatwo jest przenieść sprawdzone funkcjonalności do nowego projektu.
-* zbudować bibliotekę szablonów, którą następnie możesz skopiować do dowolnego projektu i dostosować albo wyspecjalizować do niego.
-* zbudować jedną lub więcej bibliotek gotowych obiektów lub skryptów, z których możesz bezpośrednio korzystać. Przydatne do przetrzymywania często używanych skryptów lub do zbudowania wspólnych zasobów graficznych lub dźwiękowych.
+* aby skopiować zasoby z gotowego projektu do nowego. Jeśli tworzysz sequel swojej wcześniejszej gry, to łatwy sposób, aby szybko ruszyć z pracą.
+* aby stworzyć bibliotekę szablonów, które można kopiować do projektów i potem dostosowywać albo specjalizować.
+* aby zbudować jedną lub więcej bibliotek gotowych obiektów lub skryptów, do których można się odwołać bezpośrednio. To wygodne przy przechowywaniu wspólnych modułów skryptowych albo wspólnych zasobów graficznych, dźwiękowych i animacyjnych.
## Ustawianie udostępniania biblioteki
-Załóżmy, że chcesz zbudować bibliotekę zawierającą sprite'y i źródła kafelków (tile sources). Rozpoczynasz przez [utworzenie nowego projektu](/manuals/project-setup/). Zdecyduj, które foldery z danego projektu chcesz udostępnić i dołącz ich ścieżki do *include_dirs* w ustawieniach projektu w pliku *game.project*. Jeśli chcesz dodać więcej niż jedną lokalizację, oddziel je spacjami:
+Załóżmy, że chcesz zbudować bibliotekę zawierającą wspólne sprite’y oraz źródła kafelków (tile sources). Rozpocznij od [utworzenia nowego projektu](/manuals/project-setup/). Zdecyduj, które foldery chcesz udostępnić z projektu, i dopisz ich nazwy do właściwości *`include_dirs`* w ustawieniach projektu (w pliku *game.project*). Jeśli chcesz wymienić więcej niż jedną lokalizację, oddziel nazwy spacjami:
-
+
-Zanim będziemy mogli dodać bibliotekę do innego projektu, musimy określić w nim, gdzie szukać bibliotek:
+Zanim dodasz tę bibliotekę do innego projektu, musisz podać sposób na jej znalezienie.
## URL biblioteki
-Biblioteki mają standardowy URL. Dla projektu umieszczonego na GitHubie może to być URL do projektu:
+Biblioteki odwołują się przez standardowy adres URL. Dla projektu hostowanego na GitHubie będzie to adres URL do wydania projektu:
::: important
-Zalecane jest, żeby zawsze polegać na konretnej wersji (release) biblioteki zamiast wersji z gałęzi głównej (master). W ten sposób to Ty decydujesz kiedy podpiąć do Twojego projektu nowszą wersję, która później może zostać wydana przez twórcę biblioteki na bazie zmian z mastera, aby uniknąć zmian w bibliotece, które mogłyby coś zepsuć w Twoim projekcie.
+Zalecane jest, żeby zawsze opierać się na konkretnym wydaniu (release) projektu biblioteki zamiast na gałęzi głównej (master). Dzięki temu to Ty decydujesz, kiedy wprowadzić zmiany z biblioteki do swojego projektu, zamiast automatycznie pobierać najnowsze (i potencjalnie łamiące) zmiany z gałęzi master.
:::
::: important
-Zauważ, że musisz mieć prawa odczytu do lokalizacji biblioteki. Dla projektów na GitHubie oznacza to, że projekt musi być publiczny albo musisz mieć wyenerowany token dostępu do niego.
+Zaleca się zawsze przejrzeć biblioteki stron trzecich przed ich użyciem. Dowiedz się więcej o [bezpieczeństwie przy korzystaniu z bibliotek stron trzecich](https://defold.com/manuals/application-security/#securing-your-use-of-third-party-software).
:::
-## Ustawienie zależności do biblioteki
+### Podstawowe uwierzytelnianie
-Otwórz projekt, w którym chcesz mieć dostęp do danej biblioteki. W ustawieniach projektu dodaj URL bibliotekido polae *dependencies*. Możesz określić tutaj wiele zależności. Dodaje się przez kliknięcie pzycisku `+`, a usuwa przez klinięcie przycisku `-`:
+Do adresu URL biblioteki możesz dodać nazwę użytkownika i hasło/token, aby wykonać podstawowe uwierzytelnianie, gdy biblioteka nie jest publicznie dostępna:
+
+```
+https://username:password@github.com/defold/private/archive/main.zip
+```
+
+Pola `username` i `password` zostaną wyciągnięte i dodane jako nagłówek żądania `Authorization`. Takie rozwiązanie działa na każdym serwerze obsługującym podstawowe uwierzytelnianie.
+
+::: important
+Uważaj, żeby nie udostępniać swojego tokena dostępu ani hasła, żeby nie doszło do wycieku, ponieważ w niepowołanych rękach może to mieć poważne konsekwencje.
+:::
+
+Aby nie trzymać poświadczeń w jawnej postaci w adresie URL, możesz użyć wzorca do zamiany ciągu i przechowywać dane jako zmienne środowiskowe:
+
+```
+https://__PRIVATE_USERNAME__:__PRIVATE_TOKEN__@github.com/defold/private/archive/main.zip
+```
+
+W powyższym przykładzie nazwa użytkownika i token zostaną pobrane ze zmiennych środowiskowych `PRIVATE_USERNAME` i `PRIVATE_TOKEN`.
+
+#### Uwierzytelnianie GitHub
+
+Aby pobrać zawartość prywatnego repozytorium na GitHubie, musisz [wygenerować token dostępu osobistego](https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-github/creating-a-personal-access-token) i użyć go jako hasła.
+
+```
+https://github-username:personal-access-token@github.com/defold/private/archive/main.zip
+```
+
+#### Uwierzytelnianie GitLab
+
+Aby pobrać zawartość prywatnego repozytorium na GitLabie, musisz [wygenerować token dostępu osobistego](https://docs.gitlab.com/ee/security/token_overview.html) i przekazać go jako parametr w adresie URL.
+
+```
+https://gitlab.com/defold/private/-/archive/main/test-main.zip?private_token=personal-access-token
+```
+
+### Zaawansowane uwierzytelnianie
+
+Podczas korzystania z podstawowego uwierzytelniania token i nazwa użytkownika są współdzielone ze wszystkimi repozytoriami używanymi przez projekt. W większym zespole może to stanowić problem. Rozwiązaniem jest użycie użytkownika „tylko do odczytu”, który ma dostęp do biblioteki, ale nie może jej edytować. Na GitHubie wymaga to organizacji, zespołu i użytkownika tylko do odczytu.
+
+Kroki na GitHubie:
+* [Utwórz organizację](https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/creating-a-new-organization-from-scratch)
+* [Utwórz zespół w ramach organizacji](https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/creating-a-team)
+* [Przenieś wybrane prywatne repozytorium do organizacji](https://docs.github.com/en/github/administering-a-repository/transferring-a-repository)
+* [Nadaj zespołowi dostęp „tylko do odczytu” do repozytorium](https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/managing-team-access-to-an-organization-repository)
+* [Dodaj lub wybierz użytkownika, który dołączy do zespołu](https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/organizing-members-into-teams)
+* Użyj powyższego sposobu podstawowego uwierzytelniania, aby wygenerować token dla tego użytkownika
+
+W tym momencie dane uwierzytelniające nowego użytkownika można zatwierdzić i wypchnąć do repozytorium. Każda osoba pracująca z prywatnym repozytorium może pobierać je jako bibliotekę, nie mając jednocześnie praw do edycji.
+
+::: important
+Token użytkownika tylko do odczytu jest w pełni dostępny dla każdego, kto ma dostęp do repozytorium gry korzystającej z biblioteki.
+:::
+
+Rozwiązanie to zostało opisane na forum Defold i [przedyskutowane w tym wątku](https://forum.defold.com/t/private-github-for-library-solved/67240).
+
+## Ustawianie zależności do biblioteki
+
+Otwórz projekt, w którym chcesz korzystać z biblioteki. W ustawieniach projektu dodaj adres URL biblioteki do właściwości *dependencies*. Możesz wskazać wiele projektów zależnych, dodając je jeden po drugim za pomocą przycisku `+` i usuwając przyciskiem `-`:
-Teraz, kliknij Project ▸ Fetch Libraries, żeby zaktualizować zależności do bibliotek. Dzieję się to też automatycznie podczas otwierania projektu, więc będziesz musieć do zrobić tylko w przypadku, gdy chcesz odświeżyć bilbioteki bez otwierania projektu ponownie, np. gdy dodajesz lub usuwasz bibliotekę lub któraś z bibiliotek jest zmieniana przez kogoś innego.
+Potem wybierz Project ▸ Fetch Libraries, aby zaktualizować zależności biblioteczne. Odbywa się to automatycznie przy otwieraniu projektu, więc będziesz musiał wykonać tę operację tylko wtedy, gdy chcesz odświeżyć zależności bez ponownego otwierania projektu — np. gdy dodasz lub usuniesz bibliotekę albo gdy ktoś zsynchronizuje zmiany w jednej z bibliotek.
-Folder, który udostępniłeś pojawi się w panelu *Assets* i będziesz mógł używać wszystkiego co jest tam udostępnione. Każda zsynchronizowana zmiana biblioteki będzie dostępna w Twoim projekcie.
+Teraz foldery, które udostępniłeś, pojawią się w panelu *Assets* i możesz korzystać z wszystkich zawartych tam zasobów. Wszelkie zsynchronizowane zmiany w projekcie biblioteki będą dostępne w Twoim projekcie.
+## Edytowanie plików w zależnościach bibliotek
+
+Pliki z bibliotek nie mogą być zapisane. Możesz wprowadzać zmiany, a edytor uwzględni je podczas budowania, co jest przydatne do testów. Sam plik pozostanie jednak niezmieniony, a wszystkie modyfikacje zostaną odrzucone po jego zamknięciu.
+
+Jeśli chcesz zmienić pliki biblioteki, utwórz własnego forka i wprowadź zmiany tam. Inną opcją jest skopiowanie całego katalogu biblioteki do katalogu projektu i korzystanie z lokalnej kopii. W takim przypadku lokalny folder zasłoni oryginalną zależność, więc usuń wpis w `game.project` z listy zależności (nie zapomnij potem wybrać Project ▸ Fetch Libraries).
+
+`builtins` to też biblioteka dostarczana przez silnik. Jeśli chcesz edytować jej pliki, skopiuj je do projektu i korzystaj z lokalnych kopii zamiast oryginalnych plików `builtins`. Na przykład, aby zmodyfikować `default.render_script`, skopiuj zarówno `/builtins/render/default.render`, jak i `/builtins/render/default.render_script` do katalogu projektu jako `my_custom.render` i `my_custom.render_script`. Następnie edytuj lokalny `my_custom.render`, by odnosił się do `my_custom.render_script` zamiast domyślnego, a w ustawieniach Render w `game.project` ustaw swój `my_custom.render`.
+
+Jeśli kopiujesz materiał i chcesz używać go we wszystkich komponentach pewnego typu, przydatne może być użycie [szablonów projektowych `per-project templates`](/manuals/editor/#creating-new-project-files).
+
## Zepsute zależności
-Udostępnianie bibliotek działa tylko dla plików, które znajdują się w udostępnionym folderze. Jeśli utworzysz w nim coś, co zawiera referencję do innego pliku z innego folderu, ścieżka referencji będzie nieprawidłowa.
+Udostępnianie bibliotek obejmuje tylko pliki znajdujące się w udostępnionych folderach. Jeśli stworzysz coś, co odwołuje się do zasobu spoza tej struktury, ścieżki referencji zostaną zerwane.
## Kolizja nazw
-Ponieważ możesz dołączać wiele projektów w polu *dependencies* ustawień projektu możesz napotkać sytuację kolizji nazw. Zdarza się to, gdy dwa lub więcej plików w udostępnionych folderach posiada taką samą nazwę folderu w polu *include_dirs* ustawień projektu.
+Ponieważ możesz podać wiele adresów URL projektów w polu *dependencies* ustawień projektu, może pojawić się kolizja nazw. Dzieje się tak wtedy, gdy dwie lub więcej zależnych bibliotek zawierają folder o tej samej nazwie w ustawieniu *`include_dirs`*.
-Defold rozwiązuje kolizje nazw ignorując wszystko poza ostatnią referencją do folderu o takiej samej nazwie w kolejności podawania zależności w liście *dependencies* ustawień projektu. Na przykład, jeśli wskażesz 3 biblioteki, które będą zawierać folder nazwany *items*, to tylko jeden folder *items* będzie dostępny --- ten należący do projektu, który jest dołączony jako ostatni na liście zależności.
+Defold rozwiązuje kolizje nazw, ignorując wszystko poza ostatnią referencją do folderu o danej nazwie w kolejności, w jakiej podano adresy URL w liście *dependencies*. Na przykład, jeżeli dodasz trzy biblioteki posiadające folder *items* w `include_dirs`, tylko jeden folder *items* będzie dostępny — ten z projektu będącego ostatnim na liście zależności.
diff --git a/docs/pl/manuals/message-passing.md b/docs/pl/manuals/message-passing.md
index 48158ac6..ae8f3b45 100644
--- a/docs/pl/manuals/message-passing.md
+++ b/docs/pl/manuals/message-passing.md
@@ -1,43 +1,42 @@
---
-title: Przekazywanie wiadomości
-brief: Przekazywanie wiadomości (ang. message passing) w Defoldzie jest mechanizmem umożliwiającym komunikację luźnie połączonym ze sobą obiektom. Ta instrukcja dokładnie opisuje przekazywanie wiadomości.
+title: Przekazywanie wiadomości w silniku Defold
+brief: Przekazywanie wiadomości to mechanizm używany przez Defold, aby umożliwić komunikację luźno powiązanych obiektów. Ta instrukcja opisuje ten mechanizm dogłębnie.
---
# Przekazywanie wiadomości
-Przekazywanie wiadomości to mechanizm umożliwiający obiektom gry (ang. game objects) w Defoldzie komunikację. Ten materiał wymaga uprzedniego zaznajomienia się z [mechanizmem adresowania](/manuals/addressing) i [podstawowymi elementami Defolda](/manuals/building-blocks).
-
-Defold nie jest zorientowany obiektowo w tym sensie, że aplikację zdefiniować można poprzez utworzenie hierarchii klas z dziedziczeniem i metodami w obiektach (jak np. w Javie, C++ czy C#). Zamiast tego, Defold rozszerza możliwości języka Lua o prosty i potężny mechanizm obiektowy, gdzie stan obiektów jest przetrzymywany wewnątrz skryptów (ang. script) dostępny przez referencję do siebie, tzw. `self`. Obiekty mogą być ponadto całkowicie odseparowane od mechanizmu przekazywania asynchronicznych wiadomości Objects can furthermore be fully decoupled with asynchronous message passing jako środka komunikacji między nimi.
+Przekazywanie wiadomości to mechanizm pozwalający obiektom gry w silniku Defold komunikować się między sobą. Ten materiał zakłada, że znasz podstawy [mechanizmu adresowania](/manuals/addressing) w silniku Defold oraz [podstawowych elementów budujących grę](/manuals/building-blocks).
+Defold nie realizuje programowania obiektowego w tym sensie, że definiujesz aplikację przez tworzenie hierarchii klas ze zdziedziczeniem i metodami członkowskimi w obiektach (jak w Javie, C++ czy C#). Zamiast tego Defold rozszerza Luę o prosty i skuteczny model obiektowy, w którym stan obiektów przechowywany jest wewnętrznie w komponentach skryptowych, dostępnym przez referencję `self`. Obiekty mogą być ponadto całkowicie odseparowane i komunikować się za pomocą asynchronicznego przekazywania wiadomości.
## Przykłady użycia
-Spójrzmy najpierw na kilka przykładów przekazywania wiadomości. Załóżmy, że budujesz grę, w której znajduje się:
+Najpierw przyjrzyjmy się kilku prostym przykładom. Załóżmy, że tworzysz grę składającą się z:
-1. Głowna kolekcja nazwana "main" z jednym obiektem gry z komponentem typu GUI nazwanym "interface" (z minimapą i licznikiem zdobytych punktów).
-2. Druga kolekcja nazwana "level" z dwoma obiektami gry: jednym dla postaci bohatera/gracza ("hero"), a drugim dla postaci przeciwnika ("enemy").
+1. Głównej kolekcji bootstrap zawierającej obiekt gry z komponentem GUI (GUI składa się z minimapy i licznika punktów). Znajduje się tam także kolekcja o identyfikatorze "level".
+2. Kolekcja nazwana "level" zawiera dwa obiekty gry: bohatera i przeciwnika.
-
+
::: sidenote
-Zawartość tego przykładu jest podzielona na dwa dwa osobne pliki - jeden dla kolekcji głównej "main" oraz drugi dla kolekcji "level". Pamiętaj jednak, że same nazwy plików _nie mają znaczenia_ w Defoldzie. Znaczenie ma identyfikator (id) przypisany do instancji.
+Treść tego przykładu mieści się w dwóch oddzielnych plikach. Jeden plik odpowiada głównej kolekcji bootstrap, drugi kolekcji o identyfikatorze "level". W silniku Defold nazwy plików _nie mają znaczenia_. Liczy się tożsamość, jaką nadajesz instancjom.
:::
-Gra składa się z kilku prostych zasad, które wymagają komunikacji między obiektami:
+W grze występuje kilka prostych mechanik wymagających komunikacji między obiektami:
-
+
-① Bohater trafia przeciwnika
-: Dla tej funkcjonalności, wiadomość o nazwie `"punch"` (z ang. cios) jest wysłana ze skryptu obiektu gracza "hero" do skryptu obiektu przeciwnika "enemy". Ponieważ obydwa obiekty są w hierarchi tej samej kolekcji, można użyć adresowania pośredniego (bez nazwy kolekcji):
+① Bohater uderza przeciwnika
+: W ramach tej mechaniki komponent skryptowy bohatera wysyła wiadomość `"punch"` do komponentu skryptowego przeciwnika. Ponieważ oba obiekty żyją w tej samej gałęzi hierarchii kolekcji, preferowane jest adresowanie względne:
```lua
-- Send "punch" from the "hero" script to "enemy" script
msg.post("enemy#controller", "punch")
```
- W grze jest tylko jeden rodzaj ruchu ataku, więc wiadomość nie musi zawierać żadnych innych informacji oprócz samej nazwy "punch".
+ W grze jest tylko jeden ruch zadający silny cios, więc wiadomość nie musi zawierać żadnych dodatkowych danych poza nazwą `"punch"`.
- W skrypcie obiektu przeciwnika, utwórz funkcję do obsługi przysłanej wiadomości:
+ W komponencie skryptowym przeciwnika tworzysz funkcję odbierającą wiadomość:
```lua
function on_message(self, message_id, message, sender)
@@ -47,10 +46,10 @@ Gra składa się z kilku prostych zasad, które wymagają komunikacji między ob
end
```
- W tym przypadku kod sprawdza nazwę wiadomości (wysłanej jak skrócony hash string w polu "message_id"). Kod nie bierze pod uwagę ani danych zawartych w wiadomości, ani kto był nadawcą - więc *każdy* wysyłający wiadomość "punch" spowoduje, że biedny przeciwnik otrzyma obrażenia.
+ W tym przypadku kod patrzy tylko na nazwę wiadomości (przekazywaną jako hashowany ciąg w parametrze `message_id`). Kod nie interesuje się danymi ani nadawcą — *każdy*, kto wyśle wiadomość `"punch"`, zada obrażenia biednemu przeciwnikowi.
② Bohater zdobywa punkty
-: Kiedy bohater pokona przeciwnika, licznik jego punktów wzrasta. Wiadomość nazwana `"update_score"` (z ang. zaktualizuj wynik) jest wysła ze skryptu obiektu gracza "hero" do komponentu "gui" obiektu "interface".
+: Kiedy gracz pokonuje przeciwnika, wynik gracza rośnie. Wiadomość `"update_score"` jest wysyłana z komponentu skryptowego obiektu gry bohatera do komponentu GUI w obiekcie gry "interface".
```lua
-- Enemy defeated. Increase score counter by 100.
@@ -58,9 +57,9 @@ Gra składa się z kilku prostych zasad, które wymagają komunikacji między ob
msg.post("/interface#gui", "update_score", { score = self.score })
```
- W tym przypadku nie jest możliwe użycie pośredniego adresu, ponieważ obiekt "interface" jest w hierarchi w innej kolekcji, niż obiekt gracza "hero". Wiadomość zostaje wysłana do komponentu GUI, który ma dołączony do siebie skrypt GUI, więc w tym skrypcie możemy zareagować na otrzymaną wiadomość. Wiadomości możemy wysyłać dowolnie między wszystkimi trzema typami skyptów: skryptami, skryptami GUI oraz skryptami do renderowania (render script).
+ W tym przypadku nie da się użyć adresowania względnego, bo "interface" znajduje się w korzeniu hierarchii nazw, a "hero" nie. Wiadomość wysyłana jest do komponentu GUI, do którego dołączony jest skrypt, aby mógł odpowiednio zareagować. Wiadomości można wysyłać swobodnie między skryptami, skryptami GUI i skryptami renderującymi.
- The message `"update_score"` is coupled with score data. The data is passed as a Lua table in the `message` parameter:
+ Wiadomość `"update_score"` zawiera dane o wyniku. Dane przesyłane są jako tabela Lua w parametrze `message`:
```lua
function on_message(self, message_id, message, sender)
@@ -72,8 +71,8 @@ Gra składa się z kilku prostych zasad, które wymagają komunikacji między ob
end
```
-③ Pozycja przeciwnika jest aktualizowana na minimapie.
-: Gracz patrząc na minmapę z pozycjami przeciwników może łatwiej ich zlokalizować i śledzić ruchy. Każdy przeciwniki sygnalizuje więc swoją pozycję, wysyłając wiadomość nazwaną `"update_minimap"` (z ang. zaktualizuj minimapę) do komponentu "gui" obiektu "interface":
+③ Pozycja przeciwnika na minimapie
+: Gracz ma na ekranie minimapę, która pomaga lokalizować i śledzić przeciwników. Każdy przeciwnik odpowiada za przekazywanie swojej pozycji, wysyłając wiadomość `"update_minimap"` do komponentu GUI w obiekcie gry "interface":
```lua
-- Send the current position to update the interface minimap
@@ -81,7 +80,7 @@ Gra składa się z kilku prostych zasad, które wymagają komunikacji między ob
msg.post("/interface#gui", "update_minimap", { position = pos })
```
- Skrypt GUI musi śledzić pozycję każdego przeciwnika, a jeśli przeciwnik wyśle aktualizację swojej pozycji, to jego ostatnia pozycja musi być zaktualizowana. Nazwa nadawcy wiadomości (przekazana w polu `sender`) może być użyta jako klucz w tablicy Lua z pozycjami:
+ Skrypt GUI musi śledzić pozycje wszystkich przeciwników, a jeśli ten sam przeciwnik przekaże nową pozycję, starsza powinna zostać zastąpiona. Nadawca wiadomości (przekazany w parametrze `sender`) może posłużyć jako klucz tabeli Lua przechowującej pozycje:
```lua
function init(self)
@@ -110,11 +109,11 @@ Gra składa się z kilku prostych zasad, które wymagają komunikacji między ob
## Wysyłanie wiadomości
-Mechanizm wysyłania wiadomości, jak w przykładach powyżej, jest bardzo prosty. Wywołujesz funkcję `msg.post()`, która przekierowuje wiadomość do kolejki wiadomości. Następnie, w każdej ramce, silnik Defold przegląda tę kolejkę i dostarcza każdą z wiadomości do odbiorców. Dla niektórych wiadomości systemowych (jak `"enable"`, `"disable"`, `"set_parent"` itd.) silnik sam odpowiada w odpowiedni sposób na taką wiadomość. Silnik tworzy również wiadomości systemowe (jak `"collision_response"` w przypadku kolizji fizycznych), które są rozsyłane do odpowiednich obiektów gry. W przypadku wiadomości użytkownika wysyłanych do skryptów silnik wywołuje specjalną funkcję `on_message()`.
+Mechanika wysyłania wiadomości jest, jak już widzieliśmy, bardzo prosta. Wywołujesz funkcję `msg.post()`, która umieszcza wiadomość w kolejce wiadomości. Następnie co klatkę silnik przetwarza kolejkę i doręcza każdą wiadomość do wskazanego adresata. W przypadku niektórych wiadomości systemowych (jak `"enable"`, `"disable"`, `"set_parent"` itp.) kod silnika obsługuje wiadomość. Silnik również generuje wiadomości systemowe (np. `"collision_response"` przy kolizjach fizycznych), które trafiają do twoich obiektów. W przypadku wiadomości użytkownika wysyłanych do komponentów skryptowych silnik po prostu wywołuje specjalną funkcję w języku Lua o nazwie `on_message()`.
-Możesz wysyłać dowolne wiadomości do istniejących obiektów lub komponentów, a już decyzja, czy i jak zareagować na daną wiadomość zależy od kodu funkcji. Jeśli wyślesz wiadomość do skryptu, a skrypt zignoruje ją, jest to w porządku. Odpowiedzialność za obsługę wiadomości leży w całości po stronie odbiorcy.
+Możesz wysłać dowolną wiadomość do istniejącego obiektu lub komponentu i to kod po stronie odbiorcy decyduje, jak na nią zareagować. Jeśli wiadomość trafi do komponentu skryptowego, który ją zignoruje, nic się nie stanie — obsługa komunikatów należy do odbiorcy.
-Silnik sprawdza docelowy adres wiadomości. Jeśli próbujesz wysłać wiadomość do nieznanego lub nieistniejącego odbiorcy, Defold powiadomi Cię o tym stosowną informacją z błędem w konsoli:
+Silnik sprawdza adresat wiadomości. Jeśli spróbujesz wysłać wiadomość do nieznanego odbiorcy, Defold zgłosi błąd w konsoli:
```lua
-- Try to post to a non existing object
@@ -125,18 +124,18 @@ msg.post("dont_exist#script", "hello")
ERROR:GAMEOBJECT: Instance '/dont_exists' could not be found when dispatching message 'hello' sent from main:/my_object#script
```
-Kompletna sygnatura dla funkcji `msg.post()` to:
+Pełna sygnatura wywołania `msg.post()` to:
`msg.post(receiver, message_id, [message])`
receiver
-: Odbiorca, id komponentu lub obiektu gry, do którego wiadomość ma być wysłana. Uwaga! Jeśli wiadomość jest wysłana do obiektu gry, a nie pojedynczego komponentu (np. skryptu), to każdy komponent w hierarchii ooiektu otrzymuje tę samą wiadomość.
+: Id celowego komponentu lub obiektu gry. Zwróć uwagę, że gdy adresatem jest obiekt gry, wiadomość zostanie rozesłana do wszystkich komponentów tego obiektu.
message_id
-: Nazwa wiadomości, identyfikator będący skróconym ciągiem znaków (hash string).
+: Ciąg znaków lub hashowany ciąg z nazwą wiadomości.
[message]
-: Opcjonalna tablica Lua z parami klucz-wartość zawierającymi dane. Niemal każdy typ danych może być załączony w tablicy Lua - możesz dołączyć liczby, string, boolean, adresy URL, hashe czy zagnieżdżone tablice Lua. Nie można dołączyć funkcji.
+: Opcjonalna tabela Lua zawierająca pary klucz-wartość z danymi wiadomości. W tabeli można przekazać niemal każdy typ danych: liczby, ciągi znaków, wartości logiczne, adresy URL, hashe i zagnieżdżone tabele. Nie można przekazać funkcji.
```lua
-- Send table data containing a nested table
@@ -146,33 +145,32 @@ message_id
```
::: sidenote
-Istnieje konkretny i niezmienialny limit na wielkość danych przesyłanych jako tablica Lua w polu w wiadomości `message` i wynosi 2 kilobajty. Nie istnieje obecnie prosty sposób na sprawdzenie zajętej pamięci przez tablicę w Lua, ale można przykładowo porównać wartość zwracaną przez funkcję `collectgarbage("count")` z momentu przed dodaniem danych do tablicy oraz po ich umieszczeniu, aby monitorować użycie pamięci.
+Istnieje twardy limit rozmiaru tabeli przekazywanej jako parametr `message`. Limit wynosi 2 kilobajty. Obecnie nie ma prostego sposobu określenia, ile dokładnie pamięci zajmuje tabela, ale możesz użyć `collectgarbage("count")` przed i po dodaniu tabeli, aby monitorować zużycie pamięci.
:::
### Skróty
-Defold wprowadza dwa przydatne skróty, których można używać, zamiast określania konretnego adresu (co pozwala na stworzenie bardziej ogólnej funkcji w jednym skrypcie, której można użyć np. w wielu, różnych obiektach):
-
-:[Shorthands](../shared/url-shorthands.md)
+Defold udostępnia dwa wygodne skróty, dzięki którym możesz wysyłać wiadomości bez podawania pełnego adresu URL:
+:[Skróty](../shared/url-shorthands.md)
## Odbieranie wiadomości
-Odbieranie wiadomości polega jedynie na zapewnieniu obsługi wiadomości w skrypcie przy użyciu specjalnej funkcji `on_message()`. Funkcja ta przyjmuje 4 parametry:
+Odbieranie wiadomości sprowadza się do zapewnienia, że docelowy komponent skryptowy zawiera funkcję `on_message()`. Funkcja przyjmuje cztery parametry:
`function on_message(self, message_id, message, sender)`
`self`
-: Referencja do własnej instancji skryptu, tablica unikalna dla każdego stworzonego skryptu.
+: Referencja do komponentu skryptowego.
`message_id`
-: Nazwa wiadomości, unikalny _skrócony_ (hash) identyfikator.
+: Zawiera nazwę wiadomości. Nazwa jest _hashowana_.
`message`
-: Zawiera dane wiadomości, tablicę Lua. Jeśli nie ma żadnych danych przekazanych w wiadomości, tablica jest, ale pusta.
+: Zawiera dane wiadomości. To tabela Lua. Jeśli brak danych, tabela jest pusta.
`sender`
-: Zawiera pełny adres URL nadawcy.
+: Zawiera pełny URL nadawcy.
```lua
function on_message(self, message_id, message, sender)
@@ -187,25 +185,26 @@ function on_message(self, message_id, message, sender)
end
```
-## Wysyłanie wiadomości między światami gry (game worlds)
+## Wysyłanie wiadomości między światami gry
-Jeśli używasz pełnomocników kolekcji (collection proxy) to wczytywania nowych światów gry dynamicznie, możesz chcieć przesyłać do utworzonych światów wiadomości. Załóżmy, że wczytano kolekcję o nazwie "level" przy użyciu pełnomocnika kolekcji:
+Jeśli używasz komponentu pełnomocnika kolekcji (`collection proxy`), aby załadować nowy świat gry do runtime, będziesz chciał wymieniać wiadomości między światami gry. Załóżmy, że załadowałeś kolekcję przez pełnomocnika, a kolekcja ma ustawioną właściwość *Name* na "level":
-
+
-Kiedy tylko kolekcja zostanie wczytana, zainijcjalizowana i aktywowana, możesz wysyłać wiadomości do każdego z jej komponentów lub obiektów gry w tym nowym świecie poprzez określenie w adresie pola "socket":
+Gdy tylko kolekcja zostanie załadowana, zainicjowana i włączona, możesz wysyłać wiadomości do dowolnego komponentu lub obiektu w nowym świecie gry, podając nazwę świata gry w polu adresata `socket`:
```lua
-- Send a message to the player in the new game world
msg.post("level:/player#controller", "wake_up")
```
-Więcej szczegółów na temat działania pełnomocników kolekcji znajdziesz w tej [instrukcji do pełnomocników](/manuals/collection-proxy).
+
+Szczegółowy opis działania pełnomocników kolekcji znajdziesz w instrukcji [Collection Proxies](/manuals/collection-proxy).
## Łańcuchy wiadomości
-Kiedy wiadomość zostaje wysłana, może być odczytana przez jednego z odbiorców w wywołaniu funkcji `on_message()`. Możliwe i często stosowane jest przesłanie kolejnej wiadomości do kolejki wiadomości w odpowiedzi na odebraną wiadomość.
+Gdy wiadomość zostanie wrzucona do kolejki i ostatecznie doręczona, wywoływana jest funkcja `on_message()` odbiorcy. Często kod obsługujący wiadomość przesyła nowe wiadomości, które trafiają na koniec kolejki.
-Kiedy silnik rozpoczyna rozładowywanie kolejki wiadomości w danej ramce, dla każdej z nich wywoła funkcję `on_message()` nadawcy i tak do momentu, aż kolejka będzie pusta. Jeśli obecnie rozsyłana wiadomość doda nową wiadomość do kolejki, silnik będzie rozsyłał wiadomości z kolejki ponownie. Jest jednak stały, określony limit określający ile razy kolejka może być przez silnik rozładowywana, czego skutkiem jest również limit długości łańcucha wiadomości na ramkę. Możesz sprawdzić jak wiele wiadomości w łańcuchu silnik jest w stanie rozładować między kolejnymi wywołaniami funkcji `update()`, czyli w ciągu trwania jednej ramki, używajać poniższego skryptu:
+Gdy silnik zaczyna przetwarzać kolejkę, przechodzi po niej i wywołuje funkcję `on_message()` każdego odbiorcy, kontynuując tak długo, aż kolejka zostanie opróżniona. Jeśli podczas tego przejścia dodane zostaną nowe wiadomości, silnik wykona kolejne przejście. Istnieje jednak twardy limit liczby prób opróżnienia kolejki w jednej klatce, co skutkuje ograniczeniem długości łańcuchów wiadomości, które można spodziewać się, że zostaną w pełni przetworzone w ramach jednej klatki. Możesz łatwo sprawdzić, ile przejść po kolejce wykonuje silnik między kolejnymi wywołaniami `update()` przy pomocy poniższego skryptu:
```lua
function init(self)
@@ -234,7 +233,7 @@ function on_message(self, message_id, message, sender)
end
```
-Uruchomienie skryptu powinno spowodować wypisanie podobnych informacji:
+Uruchomienie tego skryptu wypisze coś w rodzaju:
```txt
DEBUG:SCRIPT: INIT
@@ -251,4 +250,4 @@ DEBUG:SCRIPT: UPDATE 5
DEBUG:SCRIPT: 75 dispatch passes before this update.
```
-Widzimy, że ta wersja silnika Defold jest w stanie wykonać 10 przejść rozładowywania kolejki wiadomości między wywołaniem funkcji `init()` oraz pierwszym wywołaniem funkcji `update()`. Następnie jest w stanie wykonać 75 przejść kolejki w każdej ramce.
+Widzimy, że ta wersja silnika Defold wykonuje 10 przejść po kolejce wiadomości między `init()` a pierwszym wywołaniem `update()`. W kolejnych pętlach `update` liczba przejść wynosi 75.
diff --git a/docs/pl/manuals/model-animation.md b/docs/pl/manuals/model-animation.md
index b68b44f2..2be635cb 100644
--- a/docs/pl/manuals/model-animation.md
+++ b/docs/pl/manuals/model-animation.md
@@ -1,69 +1,67 @@
---
-title: Animacja modeli 3D
-brief: Ta instrukcja opisuje wsparcie dla animacji modeli 3D w silniku Defold.
+title: Animacja modeli 3D w silniku Defold
+brief: Ta instrukcja opisuje, jak używać animacji modeli 3D w silniku Defold.
---
-# Animacja modeli 3D
+# Animacja szkieletowa 3D
-Animacja szkieletowa trójwymiarowych modeli jest podobna do animacji typu Spine, z tym, że działa również w trójwymiarze. Animacja szkieletowa modeli 3D wykorzystuje "kości" (ang. bones) modelu do deformacji wierzchołków (ang. vertices) w modelu. Model 3D nie jest jednak podzielony na osobne części związane ze sobą w łańcuch kinematyczny, a w zamian tego, ruch "kości" deformuje siatkę wierzchołków reprezentującą obiekt 3D, a Ty masz kontrolę nad tym, w jaki sposób kości wpływają na taką deformację.
+Animacja szkieletowa modeli 3D wykorzystuje kości (ang. bones) modelu do deformowania wierzchołków (ang. vertices) w siatce, która tworzy obiekt 3D.
- Szczegóły dotyczące importowania danych 3D do komponentu typu "Model" dla animacji znajdziesz tutaj: [Instrukcja Modeli 3D](/manuals/model).
+Szczegóły dotyczące importowania danych 3D do komponentu *Model* dla potrzeb animacji znajdziesz w [instrukcji modeli 3D](/manuals/model).
- {.inline srcset="images/animation/blender_animation@2x.png 2x"}
- {.inline}
+
+
## Odtwarzanie animacji
-Modele są animowane za pomocą funkcji [`model.play_anim()`](/ref/model#model.play_anim):
+Modele animuje się za pomocą funkcji [`model.play_anim()`](/ref/model#model.play_anim):
```lua
function init(self)
- -- Rozpocznij animację "wiggle" w tę i z powrotem komponentu #model
+ -- Uruchom animację "wiggle" w tę i z powrotem na komponencie #model
model.play_anim("#model", "wiggle", go.PLAYBACK_LOOP_PINGPONG)
end
```
::: important
-W chwili obecnej Defold obsługuje tylko tzw. animacje wypieczone (baked animations). Animacje muszą zawierać macierze dla każdej animowanej kości na każdej klatce kluczowej, a nie pozycje, rotacje i skale jako osobne klucze.
+Silnik Defold aktualnie obsługuje tylko animacje wypieczone (baked animations). Animacje muszą zawierać macierze dla każdej animowanej kości na każdej klatce kluczowej, zamiast osobnych kluczy pozycji, rotacji i skali.
-Animacje są także interpolowane liniowo. Jeśli chcesz użyć bardziej zaawansowanej interpolacji krzywych, animacje muszą zostać wypieczone (prebaked) z poziomu eksportera.
-
-Klipy animacji w Collada nie są obsługiwane. Aby użyć wielu animacji na jednym modelu, wyeksportuj je jako osobne pliki *.dae*, a następnie zgromadź te pliki w pliku *.animationset* w Defold.
+Animacje są interpolowane liniowo. Jeśli chcesz zrobić bardziej zaawansowaną interpolację krzywych, musisz wcześniej wypiec (prebaked) animację w eksporcie.
:::
### Hierarchia kości
Kości (ang. bones) w szkielecie modelu są reprezentowane wewnętrznie jako obiekty gry (game objects).
-Możesz uzyskać identyfikator (id) instancji obiektu gry kości w czasie rzeczywistym. Funkcja [`model.get_go()`](/ref/model#model.get_go) zwraca identyfikator obiektu gry dla określonej kości.
+W czasie działania gry możesz pobrać identyfikator obiektu gry odpowiadającego konkretnej kości za pomocą funkcji [`model.get_go()`](/ref/model#model.get_go).
```lua
--- Weź środek kości 002 obiektu gry modelu wiggler
+-- Pobierz obiekt gry dla środkowej kości modelu wiggler
local bone_go = model.get_go("#wiggler", "Bone_002")
--- Zrób coś z obiektem gry
+-- Wykonaj z nim dowolną operację...
```
### Animacja kursora
-Oprócz korzystania z `model.play_anim()` do animacji modelu, komponenty typu *Model* udostępniają specjalną właściwość "kursor" (ang. cursor), którą można manipulować za pomocą `go.animate()` (więcej na temat [animacji właściwości](/manuals/property-animation))). Przykład:
+Oprócz wywoływania `model.play_anim()` do sterowania animacją, komponenty *Model* wystawiają właściwość "cursor", którą można animować za pomocą `go.animate()` (więcej w sekcji [animacje właściwości](/manuals/property-animation)).
```lua
--- Ustaw animację komponentu #model ale jeszcze nie rozpoczynaj
+-- Ustaw animację na komponencie #model, ale jej nie uruchamiaj
model.play_anim("#model", "wiggle", go.PLAYBACK_NONE)
--- Ustaw kursor animacji na początku (0)
+-- Ustaw kursor na początku animacji
go.set("#model", "cursor", 0)
--- Animuj wartość kursora animacji między 0 i 1 w tę i z powrotem
+-- Pomiędzy 0 a 1 animuj kursor w tę i z powrotem z easingiem in-out quad
go.animate("#model", "cursor", go.PLAYBACK_LOOP_PINGPONG, 1, go.EASING_INOUTQUAD, 3)
```
-## Funkcje po zakończeniu animacji
+## Callbacki zakończenia
-Animacje modelu (`model.play_anim()`) obsługują opcjonalną funkcję zwrotną Lua jako ostatni argument. Funkcja ta zostanie wywołana po zakończeniu animacji. Funkcja nigdy nie jest wywoływana dla animacji w pętli, więc takich, których tryby odtwarzania zaczynają się od: `PLAYBACK_LOOP_*`, ani w przypadku ręcznego anulowania animacji za pomocą `go.cancel_animations()`. Funkcję zwrotną można wykorzystać do wyzwalania zdarzeń po zakończeniu animacji (np. procesu zadania obrażeń po skończonej animacji ataku) lub do połączenia różnych animacji w serie, jedna za drugą. Przykłady:
+Funkcja `model.play_anim()` obsługuje opcjonalny callback Lua podany jako ostatni argument. Zostaje on wywołany po zakończeniu animacji. Nie jest uruchamiany dla animacji zapętlonych (z `PLAYBACK_LOOP_*`) ani gdy animację anulujesz ręcznie przez `go.cancel_animations()`. Callback umożliwia uruchamianie zdarzeń po zakończeniu animacji lub łączenie animacji w sekwencję.
```lua
local function wiggle_done(self, message_id, message, sender)
- -- Animacja skończona
+ -- Animacja zakończona
end
function init(self)
@@ -73,12 +71,12 @@ end
## Tryby odtwarzania
-Animacje można odtwarzać raz lub w pętli. Sposób odtwarzania animacji jest określany przez tryb odtwarzania (ang. Playback mode):
+Animacje można odtwarzać raz lub w pętli, a sposób ich grania zależy od wybranego trybu odtwarzania (ang. playback mode):
-* go.PLAYBACK_NONE
-* go.PLAYBACK_ONCE_FORWARD
-* go.PLAYBACK_ONCE_BACKWARD
-* go.PLAYBACK_ONCE_PINGPONG
-* go.PLAYBACK_LOOP_FORWARD
-* go.PLAYBACK_LOOP_BACKWARD
-* go.PLAYBACK_LOOP_PINGPONG
+* `go.PLAYBACK_NONE`
+* `go.PLAYBACK_ONCE_FORWARD`
+* `go.PLAYBACK_ONCE_BACKWARD`
+* `go.PLAYBACK_ONCE_PINGPONG`
+* `go.PLAYBACK_LOOP_FORWARD`
+* `go.PLAYBACK_LOOP_BACKWARD`
+* `go.PLAYBACK_LOOP_PINGPONG`
diff --git a/docs/pl/manuals/physics-messages.md b/docs/pl/manuals/physics-messages.md
index 0ce3fab6..a0d55d7b 100644
--- a/docs/pl/manuals/physics-messages.md
+++ b/docs/pl/manuals/physics-messages.md
@@ -1,26 +1,59 @@
---
-title: Wiadomości kolizji w Defoldzie
+title: Wiadomości kolizji w silniku Defold
brief: Kiedy obiekty się zderzają, silnik Defold wysyła wiadomości do komponentów tych obiektów.
---
# Wiadomości kolizji
-Kiedy dwa obiekty kolizji kolidują ze sobą, silnik wysyła wiadomości do wszystkich komponentów w obu tych obiektach:
+Kiedy dwa obiekty kolizji pozostają w kontakcie, silnik wysyła zdarzenia do ich komponentów. Na przykład, wiadomość może być dostarczona do funkcji zwrotnej obsługi zdarzeń (`physics.set_event_listener()`) albo trafić do domyślnego odbiorcy wiadomości za pomocą `on_message()`.
+
+## Filtrowanie zdarzeń
+
+Rodzaje generowanych zdarzeń kontrolujesz przez przełączniki dla każdego obiektu kolizji:
+
+* "Generate Collision Events"
+* "Generate Contact Events"
+* "Generate Trigger Events"
+
+Wszystkie są domyślnie ustawione na `true`. Gdy dwa obiekty kolizji wchodzą w interakcję, sprawdzamy te przełączniki, żeby zdecydować, czy wysłać wiadomość do gry.
+
+Przykład dla zaznaczonych opcji "Generate Contact Events":
+
+Gdy korzystasz z `physics.set_event_listener()`:
+
+| Komponent A | Komponent B | Wyślij wiadomość |
+|-------------|-------------|------------------|
+| ✅︎ | ✅︎ | Tak |
+| ❌ | ✅︎ | Tak |
+| ✅︎ | ❌ | Tak |
+| ❌ | ❌ | Nie |
+
+Podstawowy handler wiadomości zachowuje się trochę inaczej:
+
+| Komponent A | Komponent B | Wyślij wiadomość(y) |
+|-------------|-------------|------------------------|
+| ✅︎ | ✅︎ | Tak (A,B) + (B,A) |
+| ❌ | ✅︎ | Tak (B,A) |
+| ✅︎ | ❌ | Tak (A,B) |
+| ❌ | ❌ | Nie |
## Odpowiedź na kolizję
-Odpowiedź na kolizję `"collision_response"` to wiadomość wysyłana do wszystkich obiektów w przypadku ich kolizji. Zawiera ona następujące pola:
+Wiadomość "collision_response" jest wysyłana, gdy przynajmniej jeden z kolidujących obiektów ma typ "dynamic", "kinematic" lub "static". Zawiera następujące pola:
`other_id`
-: identyfikator innej instancji, z którą obiekt kolizji kolidował (typ `hash`).
+: identyfikator instancji, z którą obiekt kolizji kolidował (`hash`).
`other_position`
-: pozycja innej instancji w przestrzeni świata gry (world position), z którą obiekt kolizji kolidował (typ `vector3`).
+: pozycja innej instancji w przestrzeni świata gry, z którą obiekt kolizji kolidował (`vector3`).
`other_group`
-: grupa kolizyjna innego obiektu kolizji, z którą obiekt kolizji kolidował (typ `hash`).
+: grupa kolizyjna drugiego obiektu (`hash`).
+
+`own_group`
+: grupa kolizyjna obiektu, który otrzymał wiadomość (`hash`).
-Wiadomość `"collision_response"` jest odpowiednia do rozwiązywania kolizji, gdzie nie potrzebujesz szczegółów dotyczących rzeczywistego przecięcia (intersection) obiektów, na przykład, jeśli chcesz wykryć tylko czy pocisk trafia wroga. W ciągu jednej klatki jest wysyłana tylko jedna z tych wiadomości dla każdej pary obiektów kolidujących ze sobą.
+Wiadomość "collision_response" nadaje się do prostych detekcji kolizji, kiedy nie potrzebujesz szczegółów przecięcia, np. gdy chcesz sprawdzić, czy pocisk trafił wroga. W ciągu jednej klatki zostaje wysłana tylko jedna taka wiadomość dla każdej pary obiektów.
```Lua
function on_message(self, message_id, message, sender)
@@ -34,42 +67,45 @@ end
## Odpowiedź punktu kontaktu
-Odpowiedź punktu kontaktu `"contact_point_response"` to wiadomość wysyłana, gdy jeden z kolidujących obiektów jest dynamiczny lub kinematyczny. Zawiera ona następujące pola:
+Wiadomość "contact_point_response" jest wysyłana wtedy, gdy jeden z kolidujących obiektów ma typ "dynamic" lub "kinematic", a drugi może być "dynamic", "kinematic" lub "static". Oto zestaw dostępnych pól:
`position`
-: pozycja punktu kontaktu/styku w przestrzeni świata gry (world position) (typ `vector3`)
+: pozycja punktu kontaktu w przestrzeni świata gry (`vector3`).
`normal`
-: wektor normalny w przestrzeni świata do punktu kontaktu/styku, który wskazuje od innego obiektu kolizji w kierunku bieżącego obiektu, czyli tego, który otrzymał tę wiadomość (typ `vector3`).
+: normalna w przestrzeni świata wskazująca od drugiego obiektu w kierunku aktualnego obiektu (`vector3`).
`relative_velocity`
-: prędkość względna obiektu kolizji obserwowana z punktu widzenia innego obiektu kolizji, z którym obiekt, który otrzymał tę wiadomość kolidował (typ `vector3`).
+: prędkość względna obserwowana z punktu widzenia drugiego obiektu (`vector3`).
`distance`
-: odległość penetracji między obiektami kolizji - nieujemna (typ `number`).
+: odległość penetracji między obiektami (nieujemna, `number`).
`applied_impulse`
-: impuls, czyli siła która wynikała z kontaktu (typ `number`).
+: impuls powstały wskutek kontaktu (`number`).
`life_time`
-: (*obecnie nieużywane!*) czas trwania kontaktu (typ `number`).
+: (*obecnie nieużywane!*) czas trwania kontaktu (`number`).
`mass`
-: masa bieżącego obiektu kolizji w kilogramach (typ `number`).
+: masa bieżącego obiektu kolizji w kilogramach (`number`).
`other_mass`
-: masa innego obiektu kolizji, z którym kolidował obiekt, który otrzymał tę wiadomość, w kilogramach (typ `number`).
+: masa drugiego obiektu kolizji (`number`).
`other_id`
-: identyfikator instancji, z którą obiekt kolizji znajduje się w kontakcie (typ `hash`).
+: identyfikator instancji, z którą obiekt kolizji się styka (`hash`).
`other_position`
-: pozycja w przestrzeni świata gry (world position) innego obiektu kolizji, z którym kolidował obiekt, który otrzymał tę wiadomość (typ `vector3`).
+: pozycja drugiego obiektu kolizji w przestrzeni świata (`vector3`).
+
+`other_group`
+: grupa kolizyjna drugiego obiektu (`hash`).
-`group`
-: grupa kolizyjna innego obiektu kolizji, z którym kolidował obiekt, który otrzymał tę wiadomość (typ `hash`).
+`own_group`
+: grupa kolizyjna obiektu, który otrzymał wiadomość (`hash`).
-Dla gry lub aplikacji, w których potrzebujesz idealnie rozdzielać obiekty, wiadomość `"contact_point_response"` dostarcza wszystkie informacje, których potrzebujesz. Należy jednak zauważyć, że w przypadku danej pary kolizji, w zależności od charakteru kolizji, można otrzymać wiele wiadomości `"contact_point_response"` w jednej klatce. Zobacz szczegóły w [instrukcji do rozwiązywania kolizji](/manuals/physics-resolving-collisions).
+Dla zastosowań wymagających najwyższej precyzji wiadomość "contact_point_response" dostarcza wszystkie potrzebne dane. Zwróć uwagę, że dla jednej pary kolidujących obiektów możesz otrzymać kilka takich wiadomości w jednej klatce, zależnie od natury kolizji. Zobacz [Resolving collisions for more information](/manuals/physics-resolving-collisions).
```Lua
function on_message(self, message_id, message, sender)
@@ -85,15 +121,19 @@ end
## Odpowiedź na wyzwalacz
-Odpowiedź na wyzwalacz `"trigger_response"` to wiadomość wysyłana, gdy obiekt kolidujący ma typ `"trigger"` (wyzwalacz).
-
-W kolizji typu "trigger" są wysyłane wiadomości `"collision_response"`. Dodatkowo, wyzwalacze wysyłają również specjalną wiadomość `"trigger_response"` na początku i na końcu kolizji. Wiadomość ta zawiera następujące pola:
+Wiadomość "trigger_response" jest wysyłana, gdy jeden z kolidujących obiektów ma typ "trigger". Występuje raz na początku kolizji i raz po jej zakończeniu. Zawiera ona następujące pola:
`other_id`
-: identyfikator instancji, z którą obiekt kolizji kolidował (typ `hash`).
+: identyfikator instancji, z którą obiekt kolizji kolidował (`hash`).
`enter`
-: wejście - `true` jeśli interakcja była wejściem do wyzwalacza, `false`, jeśli była wyjściem (typ `boolean`).
+: `true`, jeśli wejście było wejściem do wyzwalacza, `false`, jeśli było wyjściem (`boolean`).
+
+`other_group`
+: grupa kolizyjna innego obiektu (`hash`).
+
+`own_group`
+: grupa kolizyjna obiektu, który otrzymał wiadomość (`hash`).
```Lua
function on_message(self, message_id, message, sender)
diff --git a/docs/pl/manuals/properties.md b/docs/pl/manuals/properties.md
index ff9d2c7b..e7756069 100644
--- a/docs/pl/manuals/properties.md
+++ b/docs/pl/manuals/properties.md
@@ -1,5 +1,5 @@
---
-title: Właściwości w Defoldzie
+title: Właściwości w Defold
brief: Ta instrukcja opisuje typy właściwości, jak je używać i animować.
---
@@ -56,6 +56,7 @@ Wszystkie obiekty gry i niektóre typy komponentów mają właściwości, które
| *rotation* | Lokalna rotacja obiektu gry wyrażona jako kwaternion. | `quaternion` | `get+set`{.mark} |
| *euler* | Lokalna rotacja obiektu gry wyrażona jako kąty Eulera. | `vector3` | `get+set`{.mark} |
| *scale* | Lokalna nieliniowa skala obiektu gry, wyrażona jako wektor, w którym każdy składnik zawiera mnożnik wzdłuż każdej osi. Przykładowo, aby podwoić rozmiar w osiach x i y, użyj vmath.vector3(2.0, 2.0, 0). | `vector3` | `get+set`{.mark} |
+| *scale.xy* | Lokalna nieliniowa skala obiektu gry w osiach X i Y. | `vector3` | `get+set`{.mark} |
::: sidenote
Istnieją także konkretne funkcje do pracy z transformacją obiektu gry, takie jak `go.get_position()`, `go.set_position()`, `go.get_rotation()`, `go.set_rotation()`, `go.get_scale()` i `go.set_scale()`.
@@ -68,6 +69,7 @@ Istnieją także konkretne funkcje do pracy z transformacją obiektu gry, takie
| *size* | Rozmiar sprite'a nieprzeskalowany - jego rozmiar pobierany z atlasu źródłowego. | `vector3` | `get`{.mark} |
| *image* | Skrót hasza ścieżki tekstury sprite'a. | `hash` | `get`{.mark}|
| *scale* | Nieliniowa skala sprite'a. | `vector3` | `get+set`{.mark}|
+| *scale.xy* | Nieliniowa skala sprite'a w osiach X i Y. | `vector3` | `get+set`{.mark}|
| *material* | Materiał używany przez sprite'a. | `hash` | `get+set`{.mark}|
| *cursor* | Pozycja (między 0 a 1) wskaźnika odtwarzania. | `number` | `get+set`{.mark}|
| *playback_rate* | Ilość klatek na sekundę animacji flipbook. | `number` | `get+set`{.mark}|
@@ -97,6 +99,7 @@ Istnieją także konkretne funkcje do pracy z transformacją obiektu gry, takie
| Właściwość | Opis | Typ | |
| ---------- | -------------------------------------- | --------------- | ---------------- |
| *scale* | Skala etykiety. | `vector3` | `get+set`{.mark} |
+| *scale.xy* | Skala etykiety w osiach X i Y. | `vector3` | `get+set`{.mark} |
| *color* | Kolor etykiety. | `vector4` | `get+set`{.mark} |
| *outline* | Kolor konturu etykiety. | `vector4` | `get+set`{.mark} |
| *shadow* | Kolor cienia etykiety. | `vector4` | `get+set`{.mark} |
@@ -108,8 +111,6 @@ Istnieją także konkretne funkcje do pracy z transformacją obiektu gry, takie
Węzły GUI również posiadają właściwości, ale są odczytywane i zapisywane za pomocą specjalnych funkcji getterów i setterów z API `gui`. Dla każdej właściwości istnieje funkcja gettera i settera. Istnieje także zestaw stałych zdefiniowanych do użycia jako odniesienie do właściwości podczas animacji. Jeśli potrzebujesz odnosić się do oddzielnych składowych właściwości, musisz używać nazwy ciągu znaków właściwości lub hasza nazwy ciągu znaków.
-GUI nodes also contain properties, but they are read and written through special getter and setter functions. For each property there exists one get- and one set- function. There is also a set of constants defined to use as reference to the properties when animating them. If you need to refer to separate property components you have to use the string name of the property, or a hash of the string name.
-
* `position` (lub `gui.PROP_POSITION`)
* `rotation` (lub `gui.PROP_ROTATION`)
* `scale` (lub `gui.PROP_SCALE`)
diff --git a/docs/pl/translation-guidelines.txt b/docs/pl/translation-guidelines.txt
new file mode 100644
index 00000000..59375e57
--- /dev/null
+++ b/docs/pl/translation-guidelines.txt
@@ -0,0 +1,154 @@
+---
+title: Polish Translation Guide
+brief: Observed translation rules and terminology for the Polish Defold documentation.
+---
+
+# Polish Translation Guide
+
+This file is based on a review of the current Polish corpus in `docs/pl/manuals` and `docs/pl/shared`.
+
+## Core rule
+
+Translate the explanatory prose into natural Polish. Keep English only when it is the exact product term, UI label, API symbol, file name, path, message name, enum, or other literal value used by Defold.
+
+## Translate
+
+Translate these parts fully into Polish:
+
+- introductions, explanations, warnings, notes, and recommendations
+- table descriptions and property explanations
+- conceptual text around examples
+- section headings, subheadings, captions, and ordinary link labels
+- operational instructions and caveats from the source, including cases where the user must act in English
+- Polish glosses for official Defold terms on first mention
+
+Examples already used in the corpus:
+
+- `Game object` -> `obiekt gry`
+- `Collection proxy` -> `pełnomocnik kolekcji`
+- `Tile map` -> `mapa kafelków`
+- `Input binding` -> `wiązania wejść`
+
+## Keep In English
+
+Keep the original English for literal engine and editor values:
+
+- product and technology names: `Defold`, `Lua`, `Spine`, `Android`, `iOS`, `HTML5`
+- API and code symbols: `msg.post()`, `go.animate()`, `gui.get_node()`, `hash("jump")`
+- message names, constants, and enum values: `acquire_input_focus`, `disable`, `Vsync`, `PLAYBACK_LOOP_PINGPONG`
+- file names, paths, extensions, and config keys: `game.project`, `.gui_script`, `/builtins/render/default.render`, `display.update_frequency`
+- exact editor labels and menu commands: `Outline`, `Properties`, `Assets`, `Add Component`, `Open With ▸ Text Editor`
+- exact service or workflow labels the reader must click or type: forum categories such as `Questions` and `Bugs`, or other English-only labels visible in tools and services
+
+In settings reference pages, keep section names and property names exactly as they appear in Defold, then explain them in Polish.
+
+Do not keep English for normal article headings or link text just because the English source uses English. Translate those unless they are exact UI labels, code, API names, file names, or other literals.
+
+Keep `Defold` unchanged as a brand name. Do not inflect it into forms like `Defoldzie`, `Defolda`, or `Defoldem`. Rewrite the sentence instead, for example: `w silniku Defold`, `w edytorze Defold`, `dla użytkowników Defold`.
+
+## Natural Polish
+
+Prefer natural Polish over literal calques from English.
+
+- If a direct translation sounds vague, misleading, or unnatural in Polish, rewrite it.
+- Prefer established Polish technical wording over word-for-word copies from English.
+- If the English source term is important for orientation, keep the Polish wording and add the English origin on first mention in parentheses.
+
+Examples:
+
+- `game object` -> `obiekt gry (ang. game object)` on first mention
+- `root collection` -> `główna kolekcja (ang. root collection)` or another natural Polish phrasing, not a literal calque
+- `hashed` -> `hashowany`
+- prefer established Polish wording such as `filtrowanie`, not mechanically similar but less natural forms
+
+## First Mention Pattern
+
+The existing Polish docs usually introduce official Defold concepts with the English name first and the Polish explanation in parentheses, or the reverse when the heading is already localized. Keep in mind that the Defold Editor is not localized to Polish, so readers of Polish manuals still need exposure to the English labels they will see in the product.
+
+Use patterns like:
+
+- `Collection proxy (Pełnomocnik kolekcji)`
+- `Label (Etykieta)`
+- `Etykieta (Label)`
+- `Węzeł GUI typu box`
+
+After the first mention, use whichever form is clearer in context:
+
+- use the Polish form in narrative prose
+- switch back to English when referring to the literal asset type, menu item, setting name, or API object
+- for editor concepts and official Defold naming, prefer giving both on first mention so the reader can map the Polish explanation back to the English UI or terminology
+
+## UI And Code Formatting
+
+- Wrap literal UI commands in `...`.
+- Keep inline code, code blocks, hashes, message ids, and paths unchanged.
+- Do not translate URLs.
+- Do not rename files, extensions, resource ids, or code identifiers inside examples.
+- If the source instructs the reader to report something or interact in English, keep that instruction explicit in the Polish translation.
+
+Examples:
+
+- `Add Component ▸ Label`
+- `` `layout_changed` ``
+- `` `default.render_script` ``
+- `` `go.set("#sprite", "tint", vmath.vector4(1,0,0,1))` ``
+
+## Terminology To Reuse
+
+Prefer the terminology already established in `docs/pl/manuals/glossary.md` and the existing manuals:
+
+| English term | Preferred Polish form |
+|---|---|
+| Game object | obiekt gry |
+| Component | komponent |
+| Collection | kolekcja |
+| Collection factory | fabryka kolekcji |
+| Collection proxy | pełnomocnik kolekcji |
+| Collision object | obiekt kolizji |
+| Camera | kamera |
+| Factory | fabryka |
+| Label | etykieta |
+| Library | biblioteka |
+| Message | wiadomość |
+| Render script | skrypt do renderowania |
+| Script | skrypt |
+| Sound | dźwięk |
+| Sprite | obraz / sprite |
+| Tile map | mapa kafelków |
+| Tile source | źródło kafelków |
+| Texture profiles | profile teksturowania |
+| Display profiles | profile wyświetlania |
+| GUI script | skrypt GUI |
+| Hot reload | szybkie przeładowanie |
+| Input binding | wiązania wejść |
+
+For editor views and commands, keep the English literal and optionally add a Polish explanation on first mention:
+
+- `Outline` -> `Outline` (widok zawartości pliku)
+- `Properties` -> `Properties` (właściwości)
+- `Build Errors` -> `Build Errors` (błędy budowania)
+- `Search Results` -> `Search Results` (wyniki wyszukiwania)
+
+## English Leftovers In The Corpus
+
+Several Polish files still contain copied English fragments or comments. Treat those as leftovers from the source material, not as the preferred house style.
+
+Examples were found in:
+
+- `docs/pl/manuals/components.md`
+- `docs/pl/manuals/gui-layouts.md`
+- `docs/pl/manuals/message-passing.md`
+- `docs/pl/manuals/properties.md`
+- `docs/pl/manuals/editor.md`
+
+For new or updated translations:
+
+- translate surrounding prose into Polish
+- preserve literal code and UI strings in English
+- do not copy stray English sentences just because they already appear in one file
+
+## Practical Default
+
+If a phrase is visible in the Defold UI, API, config, file system, or code, keep it in English.
+
+If a phrase explains what that thing means or how to use it, translate it into Polish.