Tłumaczenie zewnętrznych danych na język, w którym programujesz

39

Nie jestem pewien, co zrobić z następującymi elementami:

Pobieramy dane z zewnętrznego narzędzia w ramach naszego własnego narzędzia. Te dane są napisane w języku niderlandzkim. Piszemy nasz kod Java w języku angielskim. Czy powinniśmy przetłumaczyć ten holenderski na angielski, czy zachować go w języku holenderskim? Na przykład mamy 2 działy: Bouw (budownictwo w języku angielskim) i Onderhoud (konserwacja w języku angielskim).

Czy logiczne byłoby utworzenie:

public enum Department { BOUW, ONDERHOUD }

lub:

public enum Department { CONSTRUCTION, MAINTENANCE }

lub nawet:

public enum Afdeling { BOUW, ONDERHOUD }

(afdeling jest departamentem w języku niderlandzkim)

Jelle
źródło
3
Chyba nie jest to duplikat, ponieważ mówię o danych zewnętrznych, a nie o naszych własnych danych aplikacji, które są nazwane w języku angielskim.
Jelle
1
Jeśli używasz obiektów danych lub źródła w języku innym niż angielski, pomaga mieć tabelę referencyjną tłumaczenia przybliżonego angielskiego odpowiednika dla każdej funkcji i obiektu danych. Jest to szczególnie istotne w przypadku nazw funkcji i obiektów, które używają wielu słów, co jest dość powszechne w niektórych językach. Musiałem naprawiać błędy nie w moim ojczystym języku bez absolutnej znajomości języka, ale z powodu posiadania słownika tłumaczeń dla tego programu było to trywialne. Zazwyczaj programowe biblioteki tłumaczeń są uwzględniane tylko w projektach, które prawidłowo zlokalizowały swoje oprogramowanie.
kayleeFrye_onDeck
3
Czy reszta twojego programu (oprócz standardowych bibliotek) używa identyfikatorów angielskich lub holenderskich?
user253751,
Na razie używamy tylko języka angielskiego, ale Departamenty są obecnie jedynymi zakodowanymi danymi użytkownika, ponieważ Departament określonego projektu odgrywa dużą rolę w naszej aplikacji. Inne holenderskie wartości są zapisywane w naszej bazie danych, więc nie są zakodowane na stałe.
Jelle

Odpowiedzi:

33

W tym scenariuszu pozostawiłbym wartości wyliczeniowe w języku niderlandzkim:

public enum Department { BOUW, ONDERHOUD }

Ponieważ logika wykorzystująca te stałe będzie pasować do danych, które również są w języku niderlandzkim . Na przykład, jeśli dane wejściowe to „bouw”, kod porównania może wyglądać następująco:

if (Department.BOUW == input.toUpper())

Łatwiej jest mi debugować, gdy wartości się zgadzają (nawet jeśli nie wiem, co oznaczają wartości). Tłumaczenie dodaje po prostu mentalny obręcz I, jako programista, nie powinienem przeskakiwać, aby udowodnić poprawność.

Niemniej jednak możesz po prostu skomentować kod, jeśli pomaga on innym zrozumieć kontekst danych:

public enum Department { 
    BOUW, /* build */
    ONDERHOUD /* maintenance */
}
biskup
źródło
3
@Jelle Oczywiście, jeśli kiedykolwiek rozwiniesz się na arenie międzynarodowej, i tak możesz być zadowolony z logiki tłumaczenia. YMMV w YAGNI.
Williham Totland
6
I tak nie powinieneś bezpośrednio porównywać swoich wyliczeń z łańcuchami. Co jeśli musisz porównać ciąg z kilkoma słowami o wartości wyliczeniowej?
Jørgen Fogh
25
Chciałbym nigdy porównywania ciągów znaków przy użyciu .toUpper () i ==, zwłaszcza podczas pracy z łatwość wejścia i zlokalizowanych ciągów. Przykładem tego szkolnego podręcznika jest turecki znak „i”.
Adriano Repetti,
4
@ABoschman Komentarze na końcu linii ogólnie odnoszą się do linii, na której są. Ten typ komentarza widziałem setki razy w prostych opisach elementów listy…
StarWeaver,
13
W naszym sklepie robimy coś przeciwnego do tego, co tutaj sugerujemy: nazwy enum / const są w języku angielskim (lub to, co przechodzi w języku angielskim), a komentarze są „zlokalizowane”. Który jest dobry. W przeciwnym razie mielibyśmy wszystkie te stałe o nazwach takich jak PAAMAYIM_NEKUDOTAYIM.
sq33G
59

Angielski jest z jakiegoś powodu lingua franca / najniższym wspólnym mianownikiem. Nawet jeśli pod względem koncepcyjnym powód jest tak słaby jak „Wszyscy to robią”, jest to nadal dość ważny powód.

Postępowanie wbrew powszechnej praktyce oznacza, że ​​musisz rozumieć język holenderski, aby zrozumieć struktury danych w oprogramowaniu. Nie ma nic złego w języku holenderskim, ale prawdopodobieństwo, że każdy inżynier, który będzie musiał wejść w interakcję z bazą kodu, mówi, jest wciąż niższe niż w przypadku języka angielskiego.

Dlatego też, jeśli nie jesteś holenderski tylko zakupy, i nie planuje ekspansję międzynarodową kiedykolwiek , to prawie zawsze dobry pomysł, aby zachować swoją codebase jednojęzycznych i używać najpopularniejszy język kodowania.

Uwaga: ta rada dotyczy tylko kodu programu . Dane użytkownika zdecydowanie nie powinny być tłumaczone, ale przetwarzane „tak jak są”. Nawet jeśli masz klienta „Goldstein”, oczywiście nie powinieneś przechowywać jego nazwy jako „złotego kamienia”.

Problem polega na tym, że istnieje ciąg terminów między „dostarczonym przez użytkownika, nie dotykaj” a „fragmentem kodu, używaj angielskiego zawsze”. Nazwy klientów znajdują się bardzo blisko pierwszego końca spektrum, zmienne Java w pobliżu drugiego końca. Stałe enumwartości są nieco dalej, szczególnie jeśli oznaczają znane, unikalne jednostki zewnętrzne (takie jak twoje działy). Jeśli wszyscy w Twojej organizacji używają holenderskich terminów dla działów, nie planujesz konfrontować nikogo z bazą kodu, kto tego nie robi, a zestaw istniejących działów rzadko się zmienia, wtedy użycie zaakceptowanych nazw departamentów może zwiększyć wyczuwa stałe wyliczeniowe niż zmienne lokalne. Nadal bym tego nie zrobił.

Kilian Foth
źródło
3
+1, użycie angielskiego w tym przypadku daje czytelność kodu i możliwość ponownego użycia, co ujawniono w tej odpowiedzi. Podczas gdy holenderski w jakiś sposób ich łamie.
Michaił Czurbanow
4
@Jelle Czy nazwa ma znaczenie semantyczne w kodzie? Jeśli tak, przetłumacz to - i tak potrzebujesz tłumaczenia tej koncepcji. Jeśli nie, dlaczego masz enumna to? Może to być tylko znak, że próbujesz modelować dane w kodzie, co może być złym pomysłem.
Luaan
29
Zdecydowanie nie zgadzam się z tym pomysłem polegającym na ogólnym tłumaczeniu terminologii specyficznej dla domeny. W niektórych domenach, na przykład w branży kolejowej, słowniki różnych języków, a nawet terytoriów różnią się tak bardzo, że każda próba przetłumaczenia choćby jednego terminu zniekształci znaczenie tak bardzo, że uniemożliwisz jego zrozumienie. Jeśli nie masz absolutnej pewności, że domena aplikacji pozwala na bezstratne tłumaczenie, nie tłumacz terminologii domeny .
Rhymoid
6
Słyszałem też od mojego lidera projektu, że w innym projekcie programiści tłumaczą niektóre obiekty domeny z języka niderlandzkiego na angielski, a później w projekcie stało się niejasne, co te obiekty oznaczają z powodu tych niestandardowych tłumaczeń.
Jelle
4
Przeczytaj ponownie komentarze @Rhymoid i Jelle. Nigdy nie twórz własnych tłumaczeń terminologii domen! Jeśli zdecydujesz się używać angielskich terminów dla podmiotów o nazwach holenderskich, upewnij się, że korzystasz z oficjalnego tłumaczenia, a nie własnego.
Guran
15

W miarę możliwości unikaj tłumaczenia, ponieważ każde tłumaczenie to dodatkowy wysiłek i może powodować błędy.

Kluczowym wkładem „Domain Driven Design” do nowoczesnej inżynierii oprogramowania jest koncepcja języka wszechobecnego , który jest jednym językiem używanym przez wszystkich interesariuszy projektu. Według DDD tłumaczenie nie powinno odbywać się w zespole (który obejmuje ekspertów w dziedzinie, nawet jeśli jest obecny tylko przez pełnomocnika dokumentu specyfikacji), ale tylko między zespołami (dalsze czytanie: „Domain Driven Design” Erica Evansa, w szczególności rozdziały o wszechobecnym języku i projektowaniu strategicznym).

Oznacza to, że jeśli Twoi eksperci biznesowi (lub dokument specyfikacji) mówią po holendersku, używaj ich (holenderskiej) terminologii podczas wyrażania obaw biznesowych w kodzie źródłowym. Nie tłumacz niepotrzebnie na angielski, ponieważ stwarza to sztuczną przeszkodę w komunikacji między ekspertami biznesowymi a programistami, co zajmuje dużo czasu i może (poprzez niejednoznaczne lub złe tłumaczenie) powodować błędy.

Jeśli natomiast eksperci biznesowi mogą rozmawiać o swojej działalności zarówno w języku angielskim, jak i holenderskim, masz szczęście, że możesz wybrać wszechobecny język projektu, i istnieją uzasadnione powody, aby preferować angielski (np. „Zrozumiały dla całego świata i bardziej prawdopodobne, że będą używane przez standardy ”), ale nie oznacza to, że koderzy powinni tłumaczyć to, o czym rozmawiają ludzie biznesu. Zamiast tego ludzie biznesu powinni zmieniać języki.

Posiadanie wszechobecnego języka jest szczególnie ważne, jeśli wymagania są złożone i muszą zostać zaimplementowane precyzyjnie, jeśli tylko robisz CRUD język, którego używasz wewnętrznie, ma mniejsze znaczenie.

Osobista anegdota: Byłem w projekcie, w którym ujawniliśmy niektóre usługi biznesowe jako punkt końcowy SOAP. Firma została w całości określona w języku niemieckim i jest mało prawdopodobne, aby została ponownie wykorzystana, podobnie jak w języku angielskim, ponieważ dotyczyła kwestii prawnych właściwych dla konkretnej jurysdykcji. Niemniej jednak niektórzy architekci z wieży z kości słoniowej zalecili, aby interfejs SOAP był angielski, aby promować przyszłe ponowne użycie. Tłumaczenie to odbyło się w trybie hoc i przy niewielkiej koordynacji między programistami, ale tylko ze wspólnym glosariuszem, w wyniku czego ten sam termin biznesowy ma kilka nazw w umowie o świadczenie usług internetowych, a niektóre warunki biznesowe mają tę samą nazwę w umowie o świadczenie usług internetowych. Aha, i oczywiście niektóre nazwy były używane po obu stronach podziału - ale mają różne znaczenia!

Jeśli mimo wszystko zdecydujesz się na tłumaczenie, ujednolic tłumaczenie w glosariuszu, dodaj zgodność z tym glosariuszem do swojej definicji ukończenia i sprawdź w swoich recenzjach. Nie bądź tak nieostrożny jak my.

meriton - podczas strajku
źródło
5
Eksperci biznesowi będą mówić po angielsku. Znajomość języka angielskiego wśród wykształconych Holendrów na rynku pracy wynosi 100%.
MSalters
4
Mówienie po angielsku to jedno. Możliwość tłumaczenia wysokiej jakości terminologii z domeny holenderskiej na angielski to zupełnie inna sprawa.
Guran
1
@MSalters: Biegły na jakim poziomie? W projekcie, o którym mówiłem, wszyscy byli w stanie mówić po angielsku, ale nie byli tak biegli jak po niemiecku. Na przykład istniała metoda, getAdminRollktóra sprawdziła rolę administratora ... (niemieckie słowo to „Rolle” i
upuściły
@Guran: Właściwie jest to na odwrót: Twój ekspert w dziedzinie domen może spartaczać gramatykę angielską i mieć problemy z rozmową, ale zna terminologię domen w języku angielskim. Programiści mogą być większym problemem: ich domeną jest oprogramowanie, co oznacza, że ​​znają to słownictwo, ale niekoniecznie słownictwo biznesowe.
MSalters
@meriton: W rzeczywistości nie jest to taki dziwny błąd, biorąc pod uwagę, że „roll” jest angielskim sufiksem, np. listy płac , od francuskiej roli . Średnio biegła znajomość języka angielskiego w Holandii jest znacznie wyższa niż w Niemczech. Na przykład II nie spodziewałbym się, że niemieckie uniwersytety przestawią się na angielski jako język mówiony. A myślę, że przesłanie pracy w języku niemieckim jest nadal uważane za normalne?
MSalters
9

Prawidłowe rozwiązanie to wcale nie kodować działów w ogóle:

ArrayList<String> departments = (... load them from a configuration file ...)

Lub, jeśli absolutnie potrzebujesz typu działu:

class Department { String name; Department(String name) { this.name = name; } ... }
HashMap<String, Department> = (... generate from configuration file ...)

Jeśli okaże się, że konieczne jest przetestowanie określonych działów w kodzie, należy bardziej ogólnie zapytać, co jest specjalnego w tym dziale, i zaakceptować skonfigurowanie tego działu jako posiadającego tę właściwość. Na przykład, jeśli jeden dział ma tygodniową listę płac i właśnie o to chodzi w kodzie, powinna istnieć właściwość WEEKLY_PAYROLL, którą konfiguracja może dołączyć do dowolnego działu.

DepressedDaniel
źródło
To. Co dzieje się, gdy odejście zostaje podzielone lub połączone lub powstaje nowy? Ten kod dostosuje się mniej więcej automatycznie; przekształcenie go w wyliczenie oznacza, że ​​potrzebujesz nowej wersji, inaczej wybuchnie.
jpmc26,
1
Byłoby to rozwiązaniem, gdyby działy nie odgrywały tak dużej roli w naszej aplikacji. Mamy wiele if (project.getDepartment().equals(Department.XYZ))wypowiedzi.
Jelle
@Jelle jak około project.isForDepartment("XYZ"), który z kolei wykorzystuje hashmap Daniela (który jest wtryskiwany w projekcie lub coś)
SAT
2
@ SáT, To tylko prośba o literówki, szczerze mówiąc ...
Jelle
@Jelle Tak, ale można go przechwycić. Testy mogą również złapać je w czasie kompilacji. (Chociaż rozumiem, skąd pochodzisz, i zgadzam się.)
SáT
3

Dla wszystkich zastanawiających się: wybraliśmy pierwszą opcję, głównie dlatego, że uważamy, że nie powinieneś nadrabiać warunków ze względu na tłumaczenie. Jeśli jednak jakiś projekt opracowałby międzynarodowy programista, dodaliśmy dokumentację, aby to wyjaśnić:

/** The possible departments of a project, given in the Dutch language. */
public enum Department { BOUW, ONDERHOUD }
Jelle
źródło
Cieszę się, że znalazłeś satysfakcjonujące podejście. 😀 Jednak zaakceptowana odpowiedź różni się od wybranego przez ciebie podejścia. Proszę rozważyć zmianę zaakceptowanej odpowiedzi na jedną, która pasuje do wybranego przez ciebie podejścia.
biskup
Zmieniłem przyjętą odpowiedź. Jednak biorąc pod uwagę zakres opinii, myślę, że jest to również osobisty wybór i wybrałem takie podejście.
Jelle
2

Jeśli martwisz się, że masz ciąg znaków reprezentujący użytkownika lub coś, po prostu zdefiniuj tablicę opisów w swoim wyliczeniu i ujawnij metodę.
Np .: Department.BUILD.getDescription();wyświetli „BOUW”

public enum Department { 
    BUILD,
    MAINTENANCE;

    private String[] descriptions = new String[] {
        "BOUW",
        "ONDERHOUD"
    };

    public String getDescription() {
        return descriptions[ordinal()];
    }
}

Wiem, że wybrałeś inaczej, ale na wypadek, gdyby wir Google go rzucił tu przez przypadek.

EDYCJA: Jak zauważył Pokechu22 , możesz używać konstruktorów enum i własności prywatnych, takich jak:

public enum Department {
    BUILD("BOUW"),
    MAINTENANCE("ONDERHOUD");

    private final String description;

    private Department(String description) {
        this.description = description;
    }

    public String getDescription() {
        return description;
    }
}

który również osiągnie ten efekt.

Iskra
źródło
1
Nie potrzebujesz tablicy. W języku Java wyliczenia mogą mieć (prywatne) konstruktory i pola.
Pokechu22,
1
@ Pokechu22, ale czy wartość lub liczba porządkowa są dostępne w konstruktorze, aby móc dopasować ją do opisu? Mam na myśli, że nadal potrzebujesz tablicy wewnątrz konstruktora, aby uzyskać odpowiedni opis, prawda?
SparK
1
Nie, możesz to zrobić w następujący sposób:public enum Department { BUILD("BOUW"), MAINTENANCE("ONDERHOUD"); private final String description; private Department(String description) { this.description = description; } public String getDescription() { return description; } }
Pokechu22,
@ Pokechu22 Dodano do odpowiedzi. Zauważyłem również, że w przypadku zwiększenia tablicy moja implementacja może się łamać i zwiększać o 2 linie za każdym razem, podczas gdy twoja zwiększy 1 linię i nie zerwie referencji.
SparK
0

Oczekuje się, że niektóre niezmienniki kodu będą przechowywane. Jednym z tych niezmienników jest to, że program nie będzie zachowywać się inaczej po zmianie nazwy identyfikatora. W szczególności w tym przypadku, gdy masz wyliczenie i zmieniasz nazwę dowolnego członka tego wyliczenia i aktualizujesz wszystkie zastosowania tego członka, nie spodziewałbyś się, że kod zacznie działać inaczej.

Analiza składniowa to proces odczytu danych i uzyskiwania z nich struktur danych. Gdy pobierasz dane zewnętrzne, czytasz je i tworzysz wystąpienia wyliczenia, analizujesz dane. Ten proces analizowania jest jedyną częścią Twojego programu odpowiedzialną za utrzymanie relacji między reprezentacją danych, w jaki sposób je otrzymujesz, a kształtem i nazwami członków typów danych.

W związku z tym nie powinno mieć znaczenia, jakie nazwy przypisujesz członkom wyliczenia. To, że akurat pokrywają się z łańcuchami używanymi w czytanych danych, jest przypadkowe.

Podczas projektowania kodu do modelowania domeny nazwy członków nie powinny być powiązane z formatem serializacji danych. Nie powinny one być ani holenderskimi terminami, ani nie powinny być tłumaczeniem holenderskich terminów, ale powinny być tym, co według Ciebie najlepiej pasuje do modelu domeny.

Analizator składni następnie tłumaczy między formatem danych a modelem domeny. To ostatni wpływ formatu danych na kod.

Martijn
źródło