aboutsummaryrefslogtreecommitdiffstats
path: root/doc/pl/admin
diff options
context:
space:
mode:
authorAndrzej Budziński <andrzej@budzinski.ovh>2021-05-31 13:39:11 +0200
committerAndrzej Budziński <andrzej@budzinski.ovh>2021-05-31 13:39:11 +0200
commit5ae21d04b0184fef0df8c33c71445d71e76a77ec (patch)
tree86e7ebc669664aab838bdf0d5144dbb3ec21b8e3 /doc/pl/admin
parent5e07ebe7fa7691869e3ab85dab0a27b3123d335c (diff)
downloadvolse-hubzilla-5ae21d04b0184fef0df8c33c71445d71e76a77ec.tar.gz
volse-hubzilla-5ae21d04b0184fef0df8c33c71445d71e76a77ec.tar.bz2
volse-hubzilla-5ae21d04b0184fef0df8c33c71445d71e76a77ec.zip
New traslations: view/pl/invite* files + some fixes
Diffstat (limited to 'doc/pl/admin')
-rw-r--r--doc/pl/admin/administrator_guide.md8
1 files changed, 4 insertions, 4 deletions
diff --git a/doc/pl/admin/administrator_guide.md b/doc/pl/admin/administrator_guide.md
index 344ce81c0..862cab15f 100644
--- a/doc/pl/admin/administrator_guide.md
+++ b/doc/pl/admin/administrator_guide.md
@@ -350,17 +350,17 @@ Na dole dostarczonego pliku *.htconfig.php* znajduje się kilka linii, które, j
**Trzeci to "dziennik aplikacji"**. Jest to używane przez Hubzillę do zgłaszania tego, co dzieje się w programie i zwykle zapisywane są tu wszelkie trudności lub nieoczekiwane dane, które otrzymaliśmy. Jego nazwę (ścieżkę) trzeba podać na stronie "Administracja - Logi" (/admin/logs), np. *hubzilla.log* wskazuje na plik o tej nazwie zlokalizowany w katalogu głównym Hubzilla. Czasem zgłaszane są tu również komunikaty o stanie "pulsu", aby wskazać, że osiągnęliśmy określony punkt w skrypcie. Jest to dla nas najważniejszy plik dziennika, ponieważ tworzymy go samodzielnie wyłącznie w celu zgłaszania stanu zadań w tle i wszystkiego, co wydaje się dziwne lub nie na miejscu. Te błędy mogą być "śmiertelne", ale też niegroźne i po prostu nieoczekiwane. Jeśli wykonujesz zadanie i występuje problem, daj nam znać, co znajduje się w tym pliku, gdy wystąpił problem. Proszę nie wysyłaj nam 100 milionów zrzutów, bo tylko nas wkurzysz! Tylko kilka odpowiednich wierszy, ab można było wykluczyć kilkaset tysięcy wierszy kodu i skoncentrować się na tym, gdzie zaczyna się pojawiać problem.
-To są dzienniki Twojego serwisu. Zgłaszamy poważne problemy na każdym poziomie dziennika. Gorąco polecam poziom dziennika *DEBUG* dla większości witryn. Dostarcza on trochę dodatkowych informacji i nie tworzy dużych plików dziennika. Kiedy pojawia się problem, który uniemożliwia wszelkie próby śledzenia, możesz wtedy włączyć na krótki czas poziom *DATA*, aby uchwycić wszystkie szczegóły struktur, z którymi mieliśmy do czynienia w tym czasie. Ten poziom dziennika zajmuje dużo miejsca, więc jest zalecany tylko na krótkie okresy lub w przypadku witryn testowych dla programistów.
+To są dzienniki Twojego serwisu. Zgłaszamy poważne problemy na każdym poziomie dziennika. Gorąco polecamy poziom dziennika *DEBUG* dla większości witryn. Dostarcza on trochę dodatkowych informacji i nie tworzy dużych plików dziennika. Kiedy pojawia się problem, który uniemożliwia wszelkie próby śledzenia, możesz wtedy włączyć na krótki czas poziom *DATA*, aby uchwycić wszystkie szczegóły struktur, z którymi mieliśmy do czynienia w tym czasie. Ten poziom dziennika zajmuje dużo miejsca, więc jest zalecany tylko na krótkie okresy lub w przypadku witryn testowych dla programistów.
-Zalecam skonfigurowanie *logrotate* zarówno dla dziennika php, jak i dziennika aplikacji. Zazwyczaj co tydzień lub dwa zaglądam do *dbfail.out*, naprawiam zgłoszone problemy i zaczynam od nowego pliku. Podobnie jest z plikiem dziennika PHP. Odwołuję się do tego od czasu do czasu, aby sprawdzić, czy jest coś, co wymaga naprawy.
+Zalecamy skonfigurowanie *logrotate* zarówno dla dziennika php, jak i dziennika aplikacji. Zazwyczaj co tydzień lub dwa zaglądam do *dbfail.out*, naprawiam zgłoszone problemy i zaczynam od nowego pliku. Podobnie jest z plikiem dziennika PHP. Odwołuję się do tego od czasu do czasu, aby sprawdzić, czy jest coś, co wymaga naprawy.
-Jeśli coś pójdzie nie tak i nie jest to błąd krytyczny, patrzę na plik dziennika aplikacji. Często robię to:
+Jeśli coś pójdzie nie tak i nie jest to błąd krytyczny, warto zajrzeć do pliku dziennika aplikacji. Można zrobić to tak:
```
tail -f logfile.out
```
-ponieważ powtarza operację, która ma problemy. Często wstawiam w kodzie dodatkowe instrukcje rejestracji, jeśli nie ma żadnej wskazówki, co się dzieje. Nawet coś tak prostego jak "got here" lub drukuję wartości zmiennej, która może być podejrzana. Ty też możesz to zrobić - wręcz zachęcam Cię do tego. Gdy już znajdziesz to, czego potrzebujesz, możesz wykonać:
+ponieważ powtarzaja się wpisy dla operacju, która ma problemy. MOzna wstawić w kodzie dodatkowe instrukcje rejestracji, jeśli nie ma żadnej wskazówki, co się dzieje. Nawet coś tak prostego jak "got here" lub wydrukować wartości zmiennej, która może być podejrzana. Zachecamy aby to robić. Gdy już znajdziesz to, czego potrzebujesz, możesz wykonać:
```
git checkout file.php