PL Consultations [in Polish]
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.
Jestem za - też bym tak to odmieniał. A Reaccie brzmi co najmniej śmiesznie... Dobrze, że to nie jest ta jedyna, poprawna forma... :D
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 |
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ż naatrybuty, 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 mamykeys(Object.keys) lubproperties(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ć przyhooki odmieniaćhooki,hooków,hookom,hooki,hookami,hookach?
-
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łumaczenieprops❗️ . "Właściwości" używałbym tylko w kontekście obiektów JS-owych.keytł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 :) 👍
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
A co z event handler i event listener?
W MDN natrafiłem na, odpowiednio, "uchwyt zdarzenia" i "obserwator zdarzenia".
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ą.
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.
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).
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 :-)
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. 🤵
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.
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.
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ć?
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.
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ę.
-
cacheimemoize- 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?Storejest używany tam jako synonimcache. -
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.
Pracuję właśnie nad opisem
useCallbacki 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?Storejest używany tam jako synonimcache.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ć
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łaniauseEffectw 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 collectorito 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?
Hej, przy okazji tłumaczenia dokumentacji dla
useEffectnapotkał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łaniauseEffectw 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 collectorito 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 😉