PL Consultations [in Polish]

[TeoTN]

EDIT: Przenosimy dyskusje na Slacka ❗️ Wyślijcie sobie zaproszenie pod tym linkiem.

Cześć,

Proponuję używać tego wątku do konsultowania tłumaczeń. Chciałbym zacząć od zaproponowania odmiany nazwy "React", bo widziałem wiele różnych preferencji:

Przypadek	Odmiana - l.poj.	l.mn.
M	React	Reacty (?)
D	Reacta	Reactów
C	Reactowi	Reactom
B	Reacta	Reacty
N	Reactem	Reactami
Msc	Reakcie	Reactach
W	React	Reacty

Kierowałem się opinią dr-a Malinowskiego (zawiera poprawkę nie Reaccie a Reakcie), która wygląda imho całkiem sensownie.

[jakubdrozdek]

Jestem za - też bym tak to odmieniał. A Reaccie brzmi co najmniej śmiesznie... Dobrze, że to nie jest ta jedyna, poprawna forma... :D

[jakubdrozdek]

Mam w tej chwili problem z tłumaczeniem podstawowych pojęć do glosariusza (inspirowane repo hiszpańskim). Z czasem dodamy nowe.
Uważam, że nie ma sensu na siłę tłumaczyć niektórych utartych zwrotów technicznych, bo będą tylko bruździć... Te, które brzmią dla mnie dziwnie, ale znalazłem wystąpienia w Google, oznaczyłem (?).

Trafiłem jeszcze na Wikipedii na przetłumaczony termin "callback"

Termin oryginalny	Sugestia (z literatury)
array	tablica
arrow function	funkcja strzałkowa (?)
bug	błąd
bundler	bundler
camelCase	camelCase
callback	callback
controlled component	komponent kontrolowany
debugging	debugowanie
framework	framework
function component	komponent funkcyjny
hook	hook (?)
key	klucz (obiektu), key (jedna z właściwości komponentu)
lazy initialization	leniwa inicjalizacja
library	biblioteka
lowercase	małymi literami
props	właściwości
React element	element reactowy
render	renderować (czas.), renderowanie (rzecz.)
state	stan
string	łańcuch znaków
template literals	template literals (?)
uppercase	wielkimi literami
uncontrolled component	komponent niekontrolowany

[TeoTN]

Proponuję parę rozszerzeń / zmian:

• Pozostawiłbym "arrow function", znam ok 1 osoby, która używa "funkcja strzałkowa" i to chyba tylko dla żartu. MDN używa tego pojęcia. Proponuję zagłosować?

• Callback - występuje dość często jako "funkcja zwrotna" lub "wywołanie zwrotne", osobiście używałbym takiej formy wyłącznie w towarzystwie ang. - np. przekazujemy do atrybutu wywołanie zwrotne (ang. callback) - przykład użycia to Mozilla Developer Network. - Proponuję używać zamiennie, ale polskiej wersji wyłącznie w towarzystwie komentarza.

• key - w kontekście obiektu postawiłbym również na atrybuty, w przypadku elementu wyłącznie "klucz"

• props - postawiłbym tutaj na "atrybuty" - jest to o tyle uzasadnione, że w literaturze dot. HTMLa pojawia się mowa o elementach, atrybutach i wartościach. Mielibyśmy też spójność, jako że w ang. w obiektach mamy keys (Object.keys) lub properties (Object.hasOwnProperty), podobnie możemy mówić o "kluczach" lub "atrybutach"

• render - dodałbym jako alternatywę: "wyświetlanie". Nie będzie zawsze pasować, ale tam, gdzie można, proponowałbym używać zamiennie

• string - również "ciąg znaków"

• template literals - proponuję "literał szablonu (ang. template literal)" - o ile sam "literał" jest dość rozpowszechniony, tak z szablonem możemy być pionierami. Używałbym polskiej formy z odniesieniem do angielskiej.

• hooks - Zapytałem Dana Abramova co zrobili po rosyjsku i odpowiedział, że dokonali wyłącznie transliteracji na cyrylicę (huki). Proponuję zostać przy hook i odmieniać hooki, hooków, hookom, hooki, hookami, hookach?

[jakubdrozdek]

• arrow function - dla kompletności tłumaczenia stawiałbym na "funkcję strzałkową";
• callback - jestem za dodawaniem angielskiej wersji do formy "funkcja zwrotna" (lepiej widać, że to funkcja) 👍
• key, props - od zawsze w HTML-u mówiłem o "atrybutach" (np. <button type="submit" />), a w programowaniu obiektowym o "właściwościach" obiektu (MDN), dlatego tutaj faktycznie stawiałbym na "atrybuty" jako tłumaczenie props ❗️ . "Właściwości" używałbym tylko w kontekście obiektów JS-owych. key tłumaczyłbym jako "klucz" 👍
• render - jestem za dodaniem zamiennika, gdzie się da 👍
• string - faktycznie, zapomniałem o tym wariancie. Jestem za używaniem naprzemiennie: "ciąg znaków", "napis", "literał znakowy" (za: MDN) 👍
• template literals - na MDN przetłumaczyli jako "napisy szablonowe"... i nie wiem, co o tym myśleć :D Jak dla mnie ma to sens i brzmi dość zwięźle.
• hooks - jestem za polską odmianą: "hooki", "hooków", do czasu wymyślenia czegoś polskiego :) 👍

[TeoTN]

Zgadzam się w całości :) Co do "napisów szablonowych" - trochę mi to nie pasuje, jako że ukrywa się pod tym literał, czyli skrótowy format zapisywania czegoś dużego, ale ze względu na spójność możemy pójść w tym kierunku

[jakubdrozdek]

A co z event handler i event listener?
W MDN natrafiłem na, odpowiednio, "uchwyt zdarzenia" i "obserwator zdarzenia".

[jakubdrozdek]

Jest jeszcze kwestia formy zwracania się do czytelnika. Preferujemy "można zrobić X" czy "możesz zrobić X"? Patrząc na oficjalne "Guidelines for text", wydaje mi się, że w tutorialu można zwracać się "per Ty", a w docsach już przejść na formę bezosobową.

[bartlomiejzuber]

Widzę Panowie że nie próżnujecie. 👍

• "arrow function" - funkcja strzałkowa jakoś dziwnie brzmi. Jeżeli chcemy używać tego określenia proponowałbym dopisywanie wersji ang. w nawiasie. Sugeruję także spojrzeć na używane przez nas tłumaczenia czy są one pomocne dla społeczności. Jeżeli zaczniemy tłumaczyć "arrow function" jako "funkcja strzałkowa" i osoba zdecyduje się googlować to wyrażenie to może nic nie znaleźć.

• Callback - również jestem za dodawaniem angielskiej nazwy w nawiasie.

• key - w tej kwestii zgadzam się z Wami, "key" to oczywiście klucz.

• props - w tej kwestii również się zgadzam - props w kontekście komponentów nazywałbym atrybutami.

• render -

dodałbym jako alternatywę: "wyświetlanie". Nie będzie zawsze pasować, ale tam, gdzie można, proponowałbym używać zamiennie
👍

• string - również "ciąg znaków"

• template literals - w tym przypadku jestem za użyciem polskiej wersji wraz z angielską, napisy szablonowe trochę dziwnie brzmią ale specjalnie mi to nie przeszkadza. 👍

• hooks - skoro będziemy odmieniać hooki bez tłumaczenia to może zdecydujemy się tak samo traktować "propsy" wtedy atrybutami moglibyśmy określać atrybuty na tagach html. Dajcie znać co o tym sądzicie.

[jakubdrozdek]

Może to i dobry pomysł, żeby terminy Reactowe starać się jak najmniej zniekształcać. Ale idąc dalej, trzeba by zostawiać np. lifecycle hooks. Na pewno chcemy tak robić? Czy lepiej dać jakieś nasze tłumaczenie i często dawać w nawiasie oryginał (żeby nie trzeba było szukać w necie).

[jakubdrozdek]

Przenosimy dyskusje na Slacka ❗️ Czasem działa samodzielne zapraszanie się na ten workspace pod tym linkiem.
Jeśli nie działa - podaj maila, to Cię dodamy :-)

[bartlomiejzuber]

Może to i dobry pomysł, żeby terminy Reactowe starać się jak najmniej zniekształcać. Ale idąc dalej, trzeba by zostawiać np. lifecycle hooks. Na pewno chcemy tak robić? Czy lepiej dać jakieś nasze tłumaczenie i często dawać w nawiasie oryginał (żeby nie trzeba było szukać w necie).

Jestem za robieniem tłumaczenia i dodawaniem ang. nazw w nawiasie. Tak czy inaczej, trzeba się postarać, zrobić takie tłumaczenie, aby czytelnik mógł łatwo odnaleźć się w temacie po przeczytaniu dokumentacji. 🤵

[g12i]

Cześć wszystkim 👋 .

Przenosimy dyskusje na Slacka ❗️ Czasem działa samodzielne zapraszanie się na ten workspace pod tym linkiem.

Jako, że właśnie dołączyłem, z perspektywy nowo przybyłego - myślę, że lepiej mieć te informacje w jednym, "audytowalnym" miejscu. Idealnie byłoby, gdyby @TeoTN aktualizował pierwszy post.

props - obstawał bym jednak przy właściwościach. Zauważcie, że twórcy Reacta użyli props, jako skrótu od properties i unikali powiązania z attributes (mimo podobieństw do atrybutów HTML w JSX). Mam też jedną książkę po polsku (nie jest to żaden wyznacznik, ale można wysnuć wniosek, że polscy czytelnicy są przyzwyczajeni do tego tłumaczenia) i tam występuje właśnie "właściwości".

Ze swojej strony natrafiłem na:

• refs - zostawił bym nieprzetłumaczone.

[jakubdrozdek]

Ok, dodałem link do pierwszego posta.
@g12i Zapraszamy na Slacka - tam teraz dyskutujemy na temat tłumaczenia poszczególnych rzeczy. Wrzuć tam swój komentarz na kanał #pl.

[dawidsabat]

Przenosimy dyskusje na Slacka ❗️ Czasem działa samodzielne zapraszanie się na ten workspace pod tym linkiem. Jeśli nie działa - podaj maila, to Cię dodamy :-)

Cześć wszystkim! Chętnie wam pomogę i dołącze do Slacka, ale link do dodawania samego siebie nie działa, a średnio uśmiecha mi się publikowanie tutaj mojego maila. Z tego co widzę prywatnych wiadomości na GitHubie już nie ma.

Jakieś inne pomysły? Znaleźć kogoś z was na LinkedInie i tam zagadać?

[jakubdrozdek]

Cześć! Slack już jakiś czas temu umarł. Tak jak i zespół tłumaczy. Obecnie tylko ja tu zaglądam i coś klepię od czasu do czasu.

Odezwij się do mnie na LinkedIn: https://www.linkedin.com/in/jakub-drozdek-981a14111.

[dawidsabat]

Pracuję właśnie nad opisem useCallback i potrzebuję uzgodnić tłumaczenie pewnych pojęć. Wymienię je wraz z propozycjami. Pewnie część z nich już była/jest uzgodniona wiec tylko dajcie znać, a dostosuję się.

• cache i memoize - Memoizować? dla obu słów? Zapamiętanie pojawia się najczęściej w starej dokumentacji Reacta, ale wywodzi sie raczej ze słowa memoize niż z używanego w nowszej wersji cache. Ponadto Zapamiętywanie jest wg mnie zbyt ogólne i mało techniczne, natomiast memoizacja jest konkretnym konceptem z programowania i od razu wiadomo czego się spodziewać.
• store - Zachowanie? Store jest używany tam jako synonim cache.
• reactive value - Wartość reaktywna? Zmienna reaktywna? Używane w kontekscie zmiennych mogących znajdować sie w dependency array.
• component body - Wnętrze komponentu brzmi mi lepiej niż ciało komponentu ale dostosuję się.
• inline - Wprost? Bezpośrednio?
• dependecy - Zależność jest używane najczęściej w legacy.
• dependency array - Lista zależności? Tablica zależności? Oba określenia są używane naprzemiennie w legacy. Szedłbym bardziej w tablicę zależności jako że technicznie jest to tablica, nie lista 😄
• initial mount - Pierwsze montowanie?
• viewport - Widoczny obszar? Chodzi o to słowo w kontekście list wirtualnych.

Dajcie znać co sądzicie.

[ghost]

Pracuję właśnie nad opisem useCallback i potrzebuję uzgodnić tłumaczenie pewnych pojęć. Wymienię je wraz z propozycjami. Pewnie część z nich już była/jest uzgodniona wiec tylko dajcie znać, a dostosuję się.

• cache - Zapamiętanie pojawia się najczęściej w starej dokumentacji Reacta, ale wywodzi sie raczej ze słowa memoize niż z używanego w nowszej wersji cache.
• store - Zachowanie? Store jest używany tam jako synonim cache.
• reactive value - Wartość reaktywna? Zmienna reaktywna? Używane w kontekscie zmiennych mogących znajdować sie w dependency array.
• component body - Wnętrze komponentu brzmi mi lepiej niż ciało komponentu ale dostosuję się.
• inline - Wprost? Bezpośrednio?
• dependecy - Zależność jest używane najczęściej w legacy.
• dependency array - Lista zależności? Tablica zależności? Oba określenia są używane naprzemiennie w legacy. Szedłbym bardziej w tablicę zależności jako że technicznie jest to tablica, nie lista 😄
• initial mount - Pierwsze montowanie?
• viewport - Widoczny obszar? Chodzi o to słowo w kontekście list wirtualnych.

Dajcie znać co sądzicie.

• cache - jako rzeczownik to pamięć podręczna; jako czasownik to zapamiętać lub zapisać/trzymać w pamięci podręcznej.
• store - jako rzeczownik to magazyn; jako czasownik to zapisać, przechować
• reactive value - zgoda: wartość lub zmienna reaktywna
• component body - ja jestem przyzwyczajony do "ciała", ale wnętrze też mi pasuje. Można używać zamiennie.
• inline - to słowo jest trudne do przetłumaczenia w żargonie programistycznym i zawsze patrzę na nie krzywo. Jeśli chodzi o funkcję "inline", czyli taką, która jest zadeklarowana w miejscu wywołania/przekazania, to niestety nie znam lepszego tłumaczenia niż "funkcja wewnątrzliniowa". Czasownik "to inline" też jest trudny. Bezpośrednio czy wprost to bardzo luźne tłumaczenia i mogą trochę mylić, bo bardziej kojarzą się z referencją, a nie z czymś "inline". Według mnie zdanie typu "You need to inline a function" można by przetłumaczyć naokoło jako "Zdefiniuj funkcję w miejscu przekazania" itp.
• dependency - zależność
• dependency array - tablica zależności
• initial mount - pierwsze montowanie
• viewport - "widoczny obszar" może być

[dawidsabat]

Hej, przy okazji tłumaczenia dokumentacji dla useEffect napotkałem kilka słów i zwrotów co do których mam wątpliwości jak je tłumaczyć.

• cleanup function - funkcja czyszcząca? Sprzątająca?
• tooltip - dymek? Podpowiedź? Chodzi o element UI.
• external system - system zewnętrzny? Jest na to jakieś inne określenie?
• Strict Mode - tryb rygorystyczny tak jak w legacy?
• stress test - chodzi o ten dodatkowy cykl wywołania useEffect w Strict Modzie. Po prostu test?
• event listener - nasłuchiwacz zdarzeń? Obserwator zdarzeń? Żadne nie brzmi dobrze.
• modal dialog - okienko dialogowe? A może po prostu modal?
• sandbox - piaskownica? A może po prostu sandbox?
• garbage collector i to garbage-collect - nie mam pomysłu jak to nazwać i żeby to brzmiało poważnie.
• network waterfall - zero pomysłu jak to przetłumaczyć

Dodatkowo: jak tłumaczyć kod przykładów, gdzie pewne wartości muszą być wyrenderowane i odmienione przez przypadki?
Mam na myśli przykład z pokojem czatu i z biografiami ludzi.

Napisy "Jesteś w pokoju ogólny" (!) albo "To jest biografia Bob" wyglądają źle. Jakieś pomysły?

[ghost]

Hej, przy okazji tłumaczenia dokumentacji dla useEffect napotkałem kilka słów i zwrotów co do których mam wątpliwości jak je tłumaczyć.

• cleanup function - funkcja czyszcząca? Sprzątająca?
• tooltip - dymek? Podpowiedź? Chodzi o element UI.
• external system - system zewnętrzny? Jest na to jakieś inne określenie?
• Strict Mode - tryb rygorystyczny tak jak w legacy?
• stress test - chodzi o ten dodatkowy cykl wywołania useEffect w Strict Modzie. Po prostu test?
• event listener - nasłuchiwacz zdarzeń? Obserwator zdarzeń? Żadne nie brzmi dobrze.
• modal dialog - okienko dialogowe? A może po prostu modal?
• sandbox - piaskownica? A może po prostu sandbox?
• garbage collector i to garbage-collect - nie mam pomysłu jak to nazwać i żeby to brzmiało poważnie.
• network waterfall - zero pomysłu jak to przetłumaczyć

Dodatkowo: jak tłumaczyć kod przykładów, gdzie pewne wartości muszą być wyrenderowane i odmienione przez przypadki?
Mam na myśli przykład z pokojem czatu i z biografiami ludzi.

Napisy "Jesteś w pokoju ogólny" (!) albo "To jest biografia Bob" wyglądają źle. Jakieś pomysły?

• cleanup function - funkcja czyszcząca, po prostu.
• tooltip - "dymek" jest chyba dość powszechnym określeniem, więc przy nim zostańmy.
• external system - system zewnętrzny. Tak, tu chodzi o program/środowisko/system poza naszą aplikacją
• Strict Mode - Tryb Rygorystyczny
• stress test - test obciążeniowy
• event listener - obserwator zdarzeń lub nasłuchiwacz zdarzeń. Obydwie są poprawne, choć "obserwator" ma czasem inne konotacje i pochodzi od angielskiego "observer". Wydaje mi się, że tutaj głównie chodzi o pierwotne znaczenie i skojarzenia ze "starego programowania". No i określenie"to call a listener function", gdzie call kojarzy się raczej z dźwiękiem niż wzrokiem, stąd "listener".
• modal dialog - okno dialogowe. Można za pierwszym razem podać w nawiasie oryginalną nazwę angielską.
• sandbox - piaskownica lub tryb piaskownicy. Tu też bym dał za pierwszym razem oryginał.
• garbage collector - nie znam żadnego standardowego polskiego tłumaczenia, ale dałbym "program czyszczący pamięć" z angielskim odpowiednikiem w nawiasie.
• network waterfall - chodzi o sytuację, kiedy jedno żądanie powoduje odpalenie kolejnego, i tak kilka razy. Ja bym przetłumaczył trochę luźniej, w stylu "kaskada żądań sieciowych". Wodospad mi tu nie pasuje. I też dałbym oryginał za pierwszym razem.

Z odmianą przez przypadki i podstawianiem zmiennych zawsze jest problem, jeśli językiem źródłowym jest angielski. Ja zazwyczaj przekształcam zdanie na takie, w którym będzie pasował mianownik. W twoim przypadku byłoby to: "Aktualny pokój: ogólny" oraz "Bob - biografia". Pamiętaj, że to tylko przykłady. Czasem możesz zastąpić je czymś polskim, nawet zmieniając imiona na Annę, Barbarę i Cezarego 😉