Menerjemahkan data eksternal ke bahasa tempat Anda pemrograman


39

Saya tidak yakin apa yang harus dilakukan dengan hal berikut:

Kami mengambil data dari alat eksternal di dalam alat kami sendiri. Data ini ditulis dalam bahasa Belanda. Kami sedang menulis kode Java kami dalam bahasa Inggris. Haruskah kita menerjemahkan bahasa Belanda ini ke bahasa Inggris atau tetap menggunakan bahasa Belanda? Misalnya, kami memiliki 2 departemen: Bouw (Konstruksi dalam bahasa Inggris) & Onderhoud (Pemeliharaan dalam bahasa Inggris).

Maka apakah logis untuk membuat:

public enum Department { BOUW, ONDERHOUD }

atau:

public enum Department { CONSTRUCTION, MAINTENANCE }

atau bahkan:

public enum Afdeling { BOUW, ONDERHOUD }

(Afdeling adalah Department in Dutch)


3
Kemungkinan rangkap dari Konvensi Penamaan Non-Bahasa Inggris
agas

3
Saya kira itu bukan duplikat karena saya berbicara tentang data eksternal dan bukan data aplikasi kita sendiri, yang dinamai dalam bahasa Inggris.
Jelle

1
Jika menggunakan objek atau sumber data non-Inggris secara umum, ada baiknya memiliki tabel referensi terjemahan yang setara dengan Bahasa Inggris kasar untuk setiap fungsi dan objek data. Ini sangat relevan untuk nama fungsi dan objek yang menggunakan beberapa kata, yang cukup umum di beberapa bahasa. Saya harus memperbaiki bug yang tidak ada dalam bahasa ibu saya sama sekali tanpa pengetahuan bahasa, tetapi karena memiliki kamus terjemahan untuk program itu, itu sepele. Pustaka terjemahan terprogram biasanya hanya termasuk dalam proyek-proyek yang terlokalisasi dengan baik perangkat lunak mereka.
kayleeFrye_onDeck

3
Apakah sisa program Anda (terlepas dari perpustakaan standar) menggunakan pengidentifikasi bahasa Inggris atau Belanda?
user253751

Untuk saat ini, kami hanya menggunakan bahasa Inggris, tetapi Departemen saat ini adalah satu-satunya data pengguna yang dikode keras, karena Departemen proyek tertentu memainkan peran besar dalam aplikasi kami. Nilai-nilai Belanda lainnya disimpan di dalam basis data kami, sehingga tidak disimpan dalam bentuk hard-cod.
Jelle

Jawaban:


33

Dalam skenario ini, saya akan meninggalkan enum nilai-nilai di Belanda:

public enum Department { BOUW, ONDERHOUD }

Karena logika menggunakan konstanta ini akan cocok dengan data yang juga dalam bahasa Belanda . Misalnya, jika inputnya adalah "bouw", kode perbandingannya mungkin terlihat seperti:

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

Saya merasa lebih mudah untuk men-debug ketika nilainya cocok (bahkan jika saya tidak tahu apa artinya nilainya). Penerjemahan hanya menambahkan lingkaran mental I, sebagai pengembang, seharusnya tidak harus melewati untuk membuktikan kebenaran.

Namun demikian, Anda bisa mengomentari kodenya jika itu membantu orang lain memahami konteks data:

public enum Department { 
    BOUW, /* build */
    ONDERHOUD /* maintenance */
}

3
@Jelle Tentu saja, jika Anda akhirnya berkembang secara internasional, Anda mungkin senang dengan logika terjemahannya. YMMV di YAGNI.
Williham Totland

6
Anda tidak harus membandingkan enum Anda dengan string secara langsung. Bagaimana jika Anda harus membandingkan string dengan beberapa kata dengan nilai enum?
Jørgen Fogh

25
Saya tidak akan pernah membandingkan string menggunakan .toUpper () dan ==, terutama ketika bekerja dengan input pengguna dan string lokal. Contoh buku sekolah ini adalah karakter "i" Turki.
Adriano Repetti

4
@ABoschman Komentar akhir baris secara universal merujuk pada baris yang mereka pakai. Saya telah melihat jenis komentar ini untuk deskripsi sederhana dari daftar item ratusan kali ...
StarWeaver

13
Di toko kami, kami melakukan kebalikan dari apa yang disarankan di sini: nama enum / const adalah dalam bahasa Inggris (atau apa yang berlaku untuk bahasa Inggris), dan komentarnya "dilokalkan". Yang mana yang bagus. Kalau tidak, kita akan memiliki semua const ini dengan nama seperti PAAMAYIM_NEKUDOTAYIM.
sq33G

59

Bahasa Inggris adalah lingua franca / penyebut umum terendah karena suatu alasan. Bahkan jika alasannya secara konseptual selemah "Semua orang melakukannya", itu masih merupakan alasan yang agak penting.

Melawan praktik umum berarti Anda harus memahami bahasa Belanda untuk memahami struktur data dalam perangkat lunak Anda. Tidak ada yang salah dengan bahasa Belanda, tetapi probabilitas bahwa setiap insinyur yang diberikan harus berinteraksi dengan basis kode berbicara itu masih lebih rendah daripada itu untuk bahasa Inggris.

Oleh karena itu, kecuali Anda seorang Belanda hanya berbelanja, dan tidak berencana untuk memperluas internasional pernah , hampir selalu ide yang baik untuk menjaga monolingual basis kode Anda, dan menggunakan bahasa pengkodean yang paling populer.

Catatan: Saran ini hanya berlaku untuk kode program . Data pengguna seharusnya tidak diterjemahkan, tetapi diproses "sebagaimana adanya". Bahkan jika Anda memiliki pelanggan "Goldstein", jelas Anda tidak boleh menyimpan nama mereka sebagai "batu emas".

Masalahnya adalah ada kontinum istilah antara "yang disediakan pengguna, jangan sentuh" ​​dan "fragmen kode, gunakan bahasa Inggris setiap saat". Nama pelanggan sangat dekat dengan ujung spektrum sebelumnya, variabel Java di dekat ujung spektrum. Konstanta untuk enumnilai sedikit lebih jauh, terutama jika mereka menunjukkan entitas eksternal yang terkenal dan unik (seperti departemen Anda). Jika semua orang di organisasi Anda menggunakan istilah Belanda untuk departemen, Anda tidak berencana menghadapi siapa pun dengan basis kode yang tidak, dan set departemen yang ada jarang berubah, maka menggunakan nama-nama departemen yang diterima dapat membuat lebih banyak akal untuk konstanta enum daripada variabel lokal. Saya masih tidak akan melakukannya.


3
+1, menggunakan Bahasa Inggris dalam hal ini memberi Anda kode Keterbacaan dan Dapat Digunakan Kembali, yang diungkapkan dalam jawaban ini. Sementara itu membuat Belanda menghancurkan mereka dalam beberapa cara.
Mikhail Churbanov

4
@ Joelle Apakah nama itu memiliki makna semantik terhadap kode? Jika ya, terjemahkanlah - Anda tetap membutuhkan terjemahan konsep tersebut. Jika tidak, mengapa Anda memilikinya enum? Itu mungkin hanya pertanda bahwa Anda mencoba memodelkan data dalam kode, yang mungkin merupakan ide yang buruk.
Luaan

29
Saya sangat tidak setuju dengan gagasan ini untuk menerjemahkan istilah khusus domain secara umum. Dalam beberapa domain, misalnya industri kereta api, glosarium berbagai bahasa atau bahkan wilayah sangat berbeda sehingga upaya apa pun untuk menerjemahkan bahkan satu istilah pun akan membelokkan maknanya sedemikian rupa sehingga Anda mencegah siapa pun memahaminya. Kecuali Anda benar-benar yakin bahwa domain aplikasi memungkinkan untuk terjemahan tanpa kerugian, jangan terjemahkan terminologi domain .
Rhymoid

6
Saya juga mendengar dari pemimpin proyek saya bahwa pada proyek lain, pengembang kami menerjemahkan beberapa objek domain dari Belanda ke Bahasa Inggris, dan kemudian menjadi tidak jelas dalam proyek apa arti benda-benda ini karena terjemahan khusus ini.
Jelle

4
Baca komentar oleh @Rhymoid dan Jelle lagi. Jangan pernah membuat terjemahan Anda sendiri dari terminologi domain! Jika Anda memutuskan untuk menggunakan istilah bahasa Inggris untuk entitas bernama Belanda pastikan untuk menggunakan terjemahan resmi, bukan milik Anda.
Guran

15

Hindari terjemahan jika memungkinkan, karena setiap terjemahan adalah upaya tambahan dan dapat menimbulkan bug.

Kontribusi utama "Desain Didorong Domain" untuk rekayasa perangkat lunak modern adalah konsep Bahasa yang Dapat Ditebak , yang merupakan bahasa tunggal yang digunakan oleh semua pemegang saham suatu proyek. Menurut DDD, terjemahan tidak boleh terjadi dalam tim (yang mencakup pakar domain, bahkan jika hanya hadir dengan proksi dokumen spesifikasi), tetapi hanya antar tim (bacaan lebih lanjut: "Desain Didorong Domain" oleh Eric Evans, khususnya bab-bab tentang Bahasa yang Tidak Disadari dan desain strategis).

Yaitu, jika pakar bisnis Anda (atau dokumen spesifikasi Anda) berbicara bahasa Belanda, gunakan terminologi (Belanda) mereka saat mengungkapkan kekhawatiran bisnis dalam kode sumber. Jangan menerjemahkan ke dalam bahasa Inggris dengan sia-sia, karena hal itu menciptakan hambatan buatan untuk komunikasi antara pakar bisnis dan programmer, yang membutuhkan waktu dan dapat (melalui terjemahan yang ambigu atau buruk) menyebabkan bug.

Sebaliknya, jika para pakar bisnis Anda dapat berbicara tentang bisnis mereka dalam bahasa Inggris dan Belanda, Anda berada dalam situasi yang menguntungkan untuk dapat memilih bahasa di mana-mana proyek, dan ada alasan yang sah untuk memilih bahasa Inggris (seperti "dapat dipahami secara internasional dan lebih mungkin digunakan oleh standar "), tetapi melakukan itu tidak berarti bahwa pembuat kode harus menerjemahkan apa yang dibicarakan oleh para pelaku bisnis. Sebaliknya, para pebisnis harus beralih bahasa.

Memiliki bahasa di mana-mana sangat penting jika persyaratannya rumit dan harus diterapkan dengan tepat, jika Anda hanya melakukan CRUD, bahasa yang Anda gunakan kurang penting secara internal.

Anekdot pribadi: Saya sedang dalam proyek di mana kami mengekspos beberapa layanan bisnis sebagai titik akhir SOAP. Bisnis itu sepenuhnya ditentukan dalam bahasa Jerman, dan tidak mungkin digunakan kembali seperti dalam bahasa Inggris, karena ini menyangkut masalah hukum khusus untuk wilayah hukum tertentu. Namun demikian, beberapa arsitek menara gading mengamanatkan bahwa antarmuka SOAP menjadi bahasa Inggris untuk mempromosikan penggunaan kembali di masa depan. Terjemahan ini terjadi di hoc, dan dengan sedikit koordinasi di antara para pengembang, belum satu pun glosarium bersama, menghasilkan istilah bisnis yang sama dengan beberapa nama dalam kontrak layanan web, dan beberapa istilah bisnis memiliki nama yang sama dalam kontrak layanan web. Oh, dan tentu saja beberapa nama yang digunakan di kedua sisi membagi - tetapi dengan makna yang berbeda!

Jika Anda tetap memilih untuk menerjemahkan, harap distandarkan terjemahan dalam glosarium, tambahkan kepatuhan dengan glosarium tersebut pada definisi selesai, dan periksa di ulasan Anda. Jangan ceroboh seperti sebelumnya.


5
Para pakar bisnis akan berbicara bahasa Inggris. Kecakapan bahasa Inggris di antara orang Belanda yang berpendidikan dalam angkatan kerja adalah 100%.
MSalters

4
Berbicara dalam bahasa Inggris adalah satu hal. Mampu membuat terjemahan yang berkualitas dari terminologi domain belanda ke bahasa Inggris adalah hal lain.
Guran

1
@ MSalters: Mahir di tingkat apa? Pada proyek yang saya bicarakan, semua orang dapat berbicara bahasa Inggris, tetapi mereka tidak memiliki kemampuan berbahasa Jerman. Misalnya, ada metode getAdminRollyang memeriksa peran admin ... (kata Jerman adalah "Rolle", dan mereka menjatuhkan huruf yang salah :-)
meriton - mogok kerja

@ Guran: Sebenarnya, itu biasanya sebaliknya: pakar domain Anda dapat merusak tata bahasa Inggris dan memiliki tantangan dengan obrolan ringan, tetapi mereka akan tahu terminologi domain mereka dalam bahasa Inggris. Para programer mungkin masalah yang lebih besar: domain mereka adalah perangkat lunak, yang berarti mereka tahu bahwa kosa kata, tetapi belum tentu kosa kata bisnis.
MSalters

@meriton: Sebenarnya itu bukan kesalahan yang aneh, mengingat "roll" adalah sufiks Inggris, misalnya daftar gaji , dari rolle Prancis . Rata-rata, kelancaran berbahasa Inggris di Belanda secara signifikan lebih tinggi daripada di Jerman. Misalnya, saya belum berharap universitas Jerman untuk beralih ke bahasa Inggris sebagai bahasa lisan. Dan mengajukan tesis dalam bahasa Jerman masih dianggap normal, saya pikir?
MSalters

9

Solusi yang benar adalah dengan tidak melakukan hard-code pada departemen sama sekali:

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

Atau, jika Anda benar-benar membutuhkan jenis departemen:

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

Jika Anda merasa perlu menguji terhadap departemen tertentu dalam kode Anda, Anda harus bertanya secara lebih umum apa yang istimewa tentang departemen itu, dan menerima mengonfigurasi departemen itu sebagai memiliki properti itu. Misalnya, jika satu departemen memiliki daftar gaji mingguan, dan itulah yang diperhatikan oleh kode, harus ada properti WEEKLY_PAYROLL yang dapat dilampirkan ke departemen mana pun dengan konfigurasi.


Ini. Apa yang terjadi ketika keberangkatan dipisahkan atau digabungkan atau yang baru terbentuk? Kode ini akan beradaptasi kurang lebih secara otomatis; mengubahnya menjadi enum berarti Anda memerlukan bangunan baru atau itu akan meledak.
jpmc26

1
Ini akan menjadi solusi jika departemen tidak memainkan peran besar dalam aplikasi kita. Kami memiliki banyak if (project.getDepartment().equals(Department.XYZ))pernyataan.
Jelle

@Jelle, bagaimana dengan project.isForDepartment("XYZ"), yang pada gilirannya menggunakan hashmap Daniel (yang disuntikkan dalam Project, atau sesuatu)
SáT

2
@ SáT, Itu hanya meminta kesalahan ketik, jujur ​​...
Jelle

@ Joe Ya, tapi itu bisa ditangkap runtime. Tes bisa menangkap mereka dalam waktu kompilasi juga. (Meskipun saya mengerti dari mana Anda berasal, dan saya agak setuju.)
SáT

3

Untuk setiap orang yang bertanya-tanya: kami telah memilih untuk opsi pertama, terutama karena kami pikir Anda tidak boleh membuat istilah untuk menerjemahkan. Namun, jika suatu saat, pengembang internasional akan mengerjakan proyek, kami telah menambahkan beberapa dokumentasi untuk menjelaskannya:

/** The possible departments of a project, given in the Dutch language. */
public enum Department { BOUW, ONDERHOUD }

Senang Anda menemukan pendekatan yang memuaskan. 😀 Namun jawaban yang diterima tampaknya berbeda dari pendekatan yang Anda pilih. Harap pertimbangkan untuk mengubah jawaban yang diterima ke salah satu yang lain yang cocok dengan pendekatan yang Anda pilih.
Uskup

Saya mengubah jawaban yang diterima. Namun, mengingat kisaran dalam upvotes, saya pikir itu juga pilihan pribadi, dan saya memilih untuk pendekatan ini.
Jelle

2

Jika Anda khawatir memiliki representasi string untuk ditampilkan kepada pengguna atau sesuatu, cukup tentukan array deskripsi di dalam enum Anda dan paparkan sebuah metode.
Misalnya: Department.BUILD.getDescription();akan menampilkan "BOUW"

public enum Department { 
    BUILD,
    MAINTENANCE;

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

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

Saya tahu Anda memilih sebaliknya, tetapi kalau-kalau google vortex melempar orang ke sini secara tidak sengaja.

EDIT: Seperti dicatat oleh Pokechu22 Anda dapat menggunakan enum konstruktor dan properti pribadi seperti ini:

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

    private final String description;

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

    public String getDescription() {
        return description;
    }
}

yang juga akan mencapai efek itu.


1
Anda tidak perlu array. Di java, enum dapat memiliki konstruktor dan bidang (pribadi).
Pokechu22

1
@ Pokechu22, tetapi apakah nilai atau ordinal tersedia di konstruktor untuk dapat mencocokkannya dengan deskripsi? Maksud saya, Anda masih memerlukan sebuah array di dalam konstruktor untuk mendapatkan deskripsi yang benar, bukan?
SparK

1
Tidak, Anda dapat melakukannya seperti ini: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 Ditambahkan ke jawabannya. Saya juga memperhatikan jika array meningkat, implementasi saya mungkin rusak dan meningkat 2 baris setiap kali, sedangkan Anda akan meningkatkan 1 baris dan tidak akan merusak referensi.
SparK

0

Invarian tertentu dari kode Anda diharapkan berlaku. Salah satu invarian itu adalah bahwa suatu program tidak akan berperilaku berbeda ketika pengenal diubah namanya. Dalam hal ini khususnya, ketika Anda memiliki enum, dan Anda mengganti nama setiap anggota enum itu, dan memperbarui semua penggunaan anggota itu, Anda tidak akan mengharapkan kode Anda untuk mulai berfungsi secara berbeda.

Parsing adalah proses membaca data dan memperoleh struktur data darinya. Saat Anda mengambil data eksternal, membacanya, dan membuat instance enum Anda, Anda mengurai data. Proses parsing itu adalah satu-satunya bagian dari program Anda yang bertanggung jawab untuk menjaga hubungan antara representasi data bagaimana Anda menerimanya, dan bentuk serta penamaan anggota tipe data Anda.

Dengan demikian, tidak masalah apa nama yang Anda tetapkan untuk anggota enum. Bahwa mereka kebetulan bertepatan dengan string yang digunakan dalam data yang Anda baca adalah kebetulan.

Saat Anda merancang kode untuk memodelkan domain, nama anggota tidak boleh terkait dengan format serialisasi data. Seharusnya bukan istilah Belanda, atau terjemahan bahasa Belanda, tetapi harus sesuai dengan model domain yang Anda pilih.

Pengurai daripada menerjemahkan antara format data dan model domain Anda. Itulah pengaruh terakhir yang harus dimiliki format data pada kode Anda.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.