Cześć,
Po rozmowie z osobą z mojej poprzedniej branży naszło mnie kilka przemyśleń dotyczących tworzenia aplikacji dla branż w których nie ma sensownego tłumaczenia pojęć na język angielski - np. polskie prawo, administracja, pojęcia prawne związane z budownictwem(ale w kontekście prawodawstwa,rozporządzeń, czy norm polskich) itd. W jaki sposób sensowenie w tej sytuacji nazywać zmienne, kiedy wprowadzanie na siłę pojęć angielski albo nie jest możliwe albo wprowadza niejednoznaczność do kodu?
W jaki sposób sensowenie w tej sytuacji nazywać zmienne, kiedy wprowadzanie na siłę pojęć angielski albo nie jest możliwe albo wprowadza niejednoznaczność do kodu?
Nazywać po polsku.
Np. sam mam trochę stałych w klimacie DOCUMENT_TYPE_KFS = 666 (korekta faktury sprzedaży) i nie wydaje mi się, aby wersja w całości angielska była w tym wypadku czytelniejsza ;-)
w pełni popieram po polsku w warstwie domenowej.
Np tematyka kadrowo-płacowa jest pełna słów jak "tacierzyńskie", przy czym jest to coś odrębnego od "urlop ojcowski" ~= "fathers leave".
Kto przetłumaczy "becikowe" ?
Też bym nie tłumaczył rzeczy nieprzetłumaczalnych albo tracących kontekst po tłumaczeniu.
AnyKtokolwiek napisał(a):
Kto przetłumaczy "becikowe" ?
Ja. start maternity grant. Wygrałem coś?
PS. Twórca tego potworka językowego "tacierzyński" powinien zostać wykastrowany trzy pokolenia wstecz.
Przypomniałem sobie argument na swoją stronę. TDD + DDD ma prowadzić do tego (wg licznych prezentacji), że bardziej kumający przedstawiciel biznesu ma (z niewielką pomocą) czytać testy. Jest nasze przysłowie, że kod się pisze dla człowieka a tylko rzadko dla kompilatora. Zbudował bym analogiczne przysłowie: kod domenowy się pisze dla przedstawiciela domeny, a tylko czasem dla programisty 'core'