GB Inggris, atau Inggris AS?


97

Jika Anda memiliki API, dan Anda adalah pengembang yang berbasis di Inggris dengan audiens yang sangat internasional, sebaiknya API Anda

setColour()

atau

setColor()

(Untuk mengambil satu kata sebagai contoh sederhana.)

Insinyur yang berbasis di Inggris seringkali cukup defensif tentang ejaan mereka yang 'benar' tetapi dapat dikatakan bahwa ejaan AS lebih 'standar' di pasar internasional.

Saya kira pertanyaannya adalah apakah itu penting? Apakah pengembang di lokal lain kesulitan dengan ejaan GB, atau biasanya cukup jelas apa artinya?

Haruskah semuanya AS-Inggris?


1
termasuk keduanya. itu tidak akan menyakitimu.
Amarghosh

Sistem pendidikan kita selalu mengajarkan en-gb jadi saya terbiasa menulis en-gb di kode. (Kadang-kadang saya malas dan memasukkan beberapa pengenal bahasa Mandarin ketika mengembangkan kode khusus pelanggan bahasa Mandarin, dan itu diubah ke bahasa Inggris nanti)
Michael Tsang

Jawaban:


79

Saya cenderung menggunakan bahasa Inggris AS karena hal itu telah menjadi norma di API lain. Berbicara sebagai pemrogram bahasa Inggris, saya tidak punya masalah menggunakan "warna", misalnya.


6
Standardisasi adalah tujuan yang baik, dan API Anda akan lebih mudah diterima oleh komunitas internasional daripada jika menggunakan versi GB.
Maitus

55

Saya bukan penutur asli. Dalam menulis, saya selalu mencoba menggunakan en-gb. Namun, dalam pemrograman, saya selalu menggunakan en-usalih-alih bahasa Inggris British karena alasan yang sama bahwa saya tidak menggunakan bahasa Jerman atau Prancis untuk pengenal saya.


16

Secara umum saya akan menjadi orang yang kaku untuk pengejaan GB tetapi saya pikir kode membaca jauh lebih baik jika konsisten dan saya menemukan:

Color lineColor = Color.Red;

agar terlihat jauh lebih baik daripada:

Color lineColour = Color.Red;

Saya rasa pada akhirnya itu tidak terlalu penting.


9
Lebih buruk lagi jika Anda memiliki Color Color milik publik {get;}
Benjol

15

Tergantung di mana Anda melihat sebagian besar pelanggan Anda. Saya pribadi lebih suka menggunakan Bahasa Inggris-GB (misalnya Warna) dalam kode pribadi saya, tetapi saya memilih Warna untuk aplikasi / API / kode yang diterbitkan secara eksternal!


7
Menggunakan GB secara internal dan AS secara eksternal menjalankan risiko tabrakan variabel semantik - Mirip dengan jenis hal yang terjadi dengan "warna" dan "warna". Otak Anda memproses kata, bukan ejaannya dan itu dapat menyebabkan kebingungan
Chris Cudmore

1
Saya cenderung melakukan hal yang sama, tetapi berhati-hatilah dengan apa yang dikatakan Chris - jika Anda menggunakan satu ejaan di API, Anda mungkin harus menggunakan ejaan yang sama di tempat lain dalam proyek.
Mark Baker

10

Meskipun saya biasanya sangat berhati-hati tentang ejaan yang benar, sebagai pengembang Inggris, saya akan selalu menggunakan ejaan 'warna' Amerika. Dalam semua bahasa pemrograman yang saya temui, ini seperti ini, jadi demi konsistensi, menggunakan 'warna' sangat masuk akal.


5

Dengan asumsi ini adalah Java atau C # API, mungkin tidak masalah mengingat fungsionalitas pelengkapan otomatis yang tersebar luas di IDE. Jika ini untuk bahasa dinamis atau bahasa di mana IDE modern bukan norma, saya akan menggunakan ejaan Amerika. Tentu saja saya orang Amerika dan oleh karena itu jelas bias, tetapi sepertinya sebagian besar kode yang saya lihat dari pengembang yang bukan penutur asli bahasa Inggris menggunakan ejaan AS untuk nama variabel mereka, dll.


3
Panduan desain .NET Framework merekomendasikan Bahasa Inggris AS demi konsistensi
Mark Cidade

@MarkCidade: Apakah Anda memiliki tautan ke rekomendasi yang disebutkan? Saya mencarinya dari atas ke bawah tanpa hasil.
Dio F

1
@DioF Disebutkan dalam buku, "Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries" oleh Krzysztof Cwalina dan Brad Abrams
Mark Cidade

5

Sebagai pemrogram bahasa Inggris, saya menggunakan en-US untuk perangkat lunak saya. Bahasa Inggris Amerika mendominasi dengan sangat baik di hampir semua API lainnya sehingga jauh lebih mudah untuk tetap menggunakan satu jenis ejaan dan menghilangkan ambiguitas. Buang-buang waktu mencari metode hanya untuk menemukan ejaannya salah dengan satu huruf karena pelokalan ejaan.


4

Saya akan menggunakan standar saat ini dan memilih ejaan Inggris AS. HTML dan CSS adalah standar yang diakui dengan ejaan "color", kedua, jika Anda bekerja dengan kerangka seperti .NET maka kemungkinan Anda sudah memiliki warna yang tersedia di ruang nama yang berbeda.

Pajak mental karena harus berurusan dengan dua ejaan akan menghambat daripada membantu pengembang.

Label myLabel.color = setColour();

3

Saya mengalami masalah dengan API yang tidak menggunakan bahasa Inggris-AS. Hanya karena perbedaan ejaan. Saya tahu apa arti kata-kata itu tetapi ejaan yang berbeda membuat saya tersandung.

Sebagian besar perpustakaan dan kerangka kerja yang saya kenal menggunakan ejaan AS. Tentu saja, saya orang Amerika jadi ... US-English adalah bahasa ibu saya.


3

Mayoritas dokumentasi pengembangan (seperti MSDN) dalam bahasa Inggris Amerika.

Jadi mungkin lebih baik untuk tetap menggunakan aliran utama dan menggunakan bahasa Inggris Amerika di API Anda jika Anda menargetkan pemirsa internasional.


2

Saya mendapat sampel lain: Serialise dan Serialize. :)

Secara pribadi, menurut saya itu tidak terlalu penting. Saya telah mengerjakan proyek yang menggunakan negara pengejaan Inggris-Inggris dan mereka menggunakan ejaan Inggris. Ini masih bahasa Inggris dan tidak terlalu penting karena Intellisense.


Saya yakin guru bahasa Inggris saya memberi tahu saya bahwa akhiran ize valid dalam GB bahasa Inggris? Baik akhiran ise dan ize dapat diterima dalam GB Inggris, jadi saya menyesuaikan milik saya agar sesuai dengan septik. ( cockneyrhymingslang.co.uk/slang/sceptic_tank )
Scott Langham

2

Sebagai orang Kanada, saya sering mengalami hal ini. Sangat sulit bagi saya untuk mengetik "warna" karena ingatan otot saya terus menerus meraih 'u'.

Namun, saya cenderung mengadopsi bahasa perpustakaan. Java memiliki kelas Color, jadi saya menggunakan color.


1
"c", "o", "l", Ctrl + Spasi, "."
Tom

1

Saya mencoba mencari kata-kata alternatif jika memungkinkan. Aku akan membiarkannya meluncur. Untuk Warna saya mungkin bisa menggunakan Hue, Ink, Foreground / Background ...

Jika tidak, sebagai orang Inggris, saya akan menggunakan en-GB karena saya memiliki kebanggaan yang tersisa di negara dan asal saya.

Namun, jika itu akan menjadi bagian dari proyek yang lebih besar, terutama yang internasional, saya akan menjaga keseluruhan proyek konsisten di atas memiliki sebagian kecil dalam satu variasi bahasa dan sisanya dalam bahasa lain.


2
Saya tidak setuju dengan menggunakan foreground / background daripada color / atau color). depan / latar belakang juga bisa berarti pola, misalnya. Jika Anda ingin menyetel / mendapatkan colo (u) r, Anda harus menyebutnya begitu. Huruf 'u' yang hilang / tambahan tidak terlalu membingungkan daripada properti yang salah namanya.
Treb

Itu contoh yang rewel, bukan prinsipnya, tapi cukup adil.
JeeBee

2
Btw. ejaan -ize bukanlah sebuah Amerikanisme!
Jules

@ Jules ya, itu dia.
igorcadelima

@igorcadelima Mungkin bahasa Inggris dalam penggunaan umum, tetapi harap pertimbangkan: en.wikipedia.org/wiki/Oxford_spelling
Jules

1

Saya juga harus berpihak pada AS-Inggris, hanya untuk menjaga konsistensi (seperti yang telah disebutkan orang lain di sini). Meskipun saya penutur asli AS-Inggris, saya telah melakukan proyek perangkat lunak dengan perusahaan perangkat lunak Jerman dan Swedia, dan dalam kedua kasus godaan kadang-kadang akan menyerang rekan tim saya untuk menggunakan teks bahasa Jerman atau Swedia dalam kode - biasanya untuk komentar, tetapi terkadang juga untuk nama variabel atau metode. Meskipun saya dapat berbicara dalam bahasa-bahasa tersebut, itu benar-benar mengejutkan dan mempersulit untuk membawa non-pembicara baru ke dalam proyek.

Sebagian besar perusahaan perangkat lunak Eropa (setidaknya yang pernah bekerja dengan saya) berperilaku dengan cara yang sama - kode tetap dalam bahasa Inggris, hanya karena itu membuat kode lebih ramah internasional jika programmer lain ikut serta. Dokumentasi internal biasanya cenderung dilakukan dalam bahasa asli.

Meskipun demikian, perbedaannya di sini adalah tentang dua dialek bahasa Inggris yang berbeda, yang tidak terlalu ekstrim seperti melihat dua bahasa yang sama sekali berbeda dalam file kode sumber yang sama. Jadi saya akan mengatakan, simpan API dalam AS-Inggris, tetapi komentar Anda dalam GB-Inggris jika itu lebih cocok untuk Anda.


1

Menurut saya, lihat bagaimana perpustakaan lain dalam bahasa Anda memilih dan mengikuti konvensi mereka.

Perancang bahasa pemrograman dan API bawaannya membuat pilihan, dan apakah pengguna internasional atau tidak, mereka terbiasa melihat ejaan yang konsisten dengan pilihan ini. Anda tidak menargetkan penutur bahasa yang berbeda tetapi pengguna bahasa pemrograman. Kemungkinan mereka telah mempelajari beberapa kata dalam bahasa asing dari API bawaan, dan mereka mungkin tidak menyadari ada perbedaan antara bahasa Inggris AS dan Inggris GB. Jangan membingungkan mereka dengan mengganti sisi kolam.

Saya menggunakan bahasa .NET terutama, dan .NET Framework menggunakan ejaan bahasa Inggris AS. Pada platform ini, saya akan tetap menggunakan bahasa Inggris AS. Saya tidak mengetahui bahasa apa pun yang distandarisasi pada GB Inggris, tetapi jika bahasa Anda telah melakukannya, maka tetaplah konsisten dengan bahasa tersebut.


1

Saya setuju dengan rombongan "pilih orang Amerika". Saya sendiri lebih suka en-GB saat menulis e-mail dan semacamnya, tetapi bahasa Inggris Amerika cukup banyak standar di semua lingkaran pemrograman.


1

Meskipun bahasa Inggris British adalah yang digunakan di seluruh dunia - saya merekomendasikan penggunaan bahasa Inggris Amerika yang seperti yang dikatakan orang lain mendominasi pasar.



1

Pertama, saya di AS. Dalam proyek saya saat ini, itu selalu "warna" namun, kata yang sepertinya tidak bisa kita pilih ejaannya adalah "abu-abu" vs "abu-abu".

Ini sebenarnya cukup mengganggu.


1

Pemilihan bahasa untuk nama pengenal tidak ada hubungannya dengan audiens dan semuanya berkaitan dengan bahasa asli tempat framework atau API dikembangkan.

Saya tidak tahu banyak bahasa, tetapi saya tidak dapat memikirkan satu pun bahasa yang menggunakan bahasa lain selain Inggris AS.

Bahaya memperkenalkan bug halus karena ejaan yang berbeda adalah IMHO yang terlalu bagus.

Penimpaan fungsi dapat dengan mudah menjadi pseudo-overload.

File konfigurasi bisa menjadi tidak valid karena perbedaan ejaan.

Situasi mungkin muncul di mana objek konseptual yang sama telah didefinisikan menggunakan beberapa kelas, menggunakan en-US dan en-GB.

Jadi oleh karena itu, apakah sebuah kode murni untuk penggunaan internal atau ditujukan untuk penggunaan eksternal juga, ejaan yang digunakan harus selalu sesuai dengan bahasa asli platform / framework / compiler / API.


Saya hanya peduli dengan konsistensi dalam API kami. Misalnya, jika paket kami menargetkan Inggris, hanya en-gb yang dapat digunakan, sama sekali tidak ada ejaan seperti "color".
Michael Tsang

Saya menduga Anda juga menulis perpustakaan kelas dasar Anda sendiri, Michael?
Umar Farooq Khawaja

0

Jika semua programmer Anda orang Inggris, gunakan en-gb. Jika kode Anda akan dilihat oleh programmer di luar Inggris, maka en-us akan menjadi pilihan yang lebih baik.

Satu hal kecil, kami mengandalkan layanan terjemahan untuk menyalin dokumentasi kami ke dalam bahasa lain. Kami mendapati bahwa kami mendapatkan terjemahan yang lebih baik saat menggunakan en-us sebagai sumbernya.


0

Anda perlu mempertimbangkan audiens Anda. Siapa yang akan menggunakan kode dan apa yang mereka harapkan untuk dilihat?

Saya bekerja di perusahaan yang memiliki kantor di Kanada & AS. Kami menggunakan ejaan Kanada (sangat mirip dengan Inggris British) saat membuat dokumentasi dan kode di Kanada dan ejaan AS untuk apa yang digunakan di AS.

Beberapa hal melintasi batas, tetapi perbedaan ejaan jarang menjadi masalah. Ini sebenarnya dapat menghasilkan beberapa dialog yang menarik ketika orang Amerika tidak mengetahui ejaan yang berbeda untuk bahasa Candian dan British English. Kadang-kadang mereka baik-baik saja dengan itu, di lain waktu mereka bersikeras untuk mengubahnya menjadi ejaan yang "benar". Ini juga memengaruhi format tanggal (hh / bb / tttt di Kanada dan bb / hh / tttt di AS)

Ketika ada kebuntuan, kami biasanya menggunakan ejaan AS karena orang-orang di Kanada terbiasa dengan kedua variasi tersebut.


0

Alasan utama saya mendengar untuk memilih AS daripada Inggris Inggris adalah karena penonton Inggris, ketika dihadapkan dengan ejaan AS, menyadari bahwa itu adalah aplikasi AS (atau anggap demikian), sedangkan pemirsa AS yang dihadapkan dengan ejaan Inggris berpikir '.. .Hai, itu salah .. itu warna bukan warna '

Tapi seperti yang dikatakan orang lain, standarisasi. Pilih dan pertahankan.


0

Itu wajar bagi saya untuk bekerja dalam bahasa Inggris UK tanpa berpikir tentang itu. Namun, jika Anda mengembangkan prosedur internal, itu tidak terlalu penting. Jika Anda membuat API yang akan digunakan secara publik, dan audiens Anda adalah internasional, mengapa tidak menerapkan keduanya?



0

Saya salah satu dari orang-orang ini yang detak jantung dan tekanan darahnya meningkat setiap kali saya terpaksa menggunakan bahasa Inggris Amerika dalam file penyiapan, dll., Karena fakta bahwa perangkat lunak tidak memberikan opsi untuk bahasa Inggris British, tetapi itu hanya saya :)

Pendapat pribadi saya tentang yang satu ini adalah memberikan kedua ejaan, memberi mereka setColor () dan setColour (), tulis kode di salah satunya, dan minta yang kedua melewati parameter.

Dengan cara ini Anda membuat kedua kelompok senang, mengingat kecerdasan Anda menjadi sedikit lebih lama, tetapi setidaknya orang tidak dapat mengeluh tentang Anda menggunakan bahasa yang 'salah'.


7
Ini bukan ide yang bagus. API akan dikotori dengan metode redundan.
McDowell

6
Itu solusi yang sangat buruk. Anda mungkin akan membingungkan banyak orang, yang mencoba mencari tahu perbedaan antara setColour dan setColor. Selain itu, ini dapat membuat banyak kekacauan di API jika Anda memiliki banyak metode dengan kata warna di dalamnya.
Kibbee

Pikiranku persis. Anda tidak perlu mengeluarkan biaya untuk memberikan kedua ejaan dan hanya mendokumentasikannya sebagai identik. Adapun keberatan redundansi, kegunaan mengalahkan ortogonalitas.
Dave Sherohman

0

Jika Anda menengok ke belakang beberapa ratus tahun, Anda akan menemukan bahwa perubahan itu tidak ada hubungannya sama sekali dengan AS, seperti yang dipikirkan banyak orang. Perubahan tersebut berasal dari pengaruh Eropa, khususnya Prancis. Sebelumnya, kata bahasa Inggris "color" sebenarnya dieja sebagai "color".

Untuk mencoba menstandarkan akan sia-sia karena setengah dari anak-anak China sedang mempelajari pengaruh bahasa Inggris pra Eropa dan pemahaman AS tentang bahasa Inggris, sementara setengah lainnya mengambilnya seperti sekarang, sebagai bahasa Inggris.

Jika menurut Anda bahasa adalah masalah, maka Anda harus mempertimbangkan Taiwan Kg yang beratnya 600g. Saya belum tahu bagaimana mereka mengelolanya, tapi saya harap mereka tidak pernah dipekerjakan sebagai personel pengisian bahan bakar pesawat!


0

Saya selalu menggunakan en-GB untuk semua program saya. Saya kira itu karena pengaruh besar novel-novel Inggris.

Namun, mungkinkah tidak mungkin memiliki dua set API yang berbeda (satu untuk en-US, satu untuk en-GB) yang secara internal memanggil fungsi yang sama? Ini mungkin membengkakkan file header, jadi mungkin tergantung pada definisi preprocessor, kompilasi bersyarat? Jika Anda menggunakan C ++, Anda dapat melakukan sesuatu seperti di bawah ini ...

#ifdef ENGB
     typedef struct Colour
     {
      //blahblahblah
     };
     void SetColour(Colour c);
#else
    typedef struct Color
    {
      //blahblahblah
    };
    void SetColor(Color c);
#endif

Bergantung pada apakah programmer klien mendefinisikan ENGB atau tidak seperti di bawah ini

#define ENGB

dia bisa menggunakan API dalam budaya yang dia sukai. Mungkin berlebihan untuk tujuan yang sepele, tapi hei, jika tampaknya penting, mengapa tidak! :)


2
Lebih baik mengikuti ejaan AS karena hampir semua API standar mengikutinya. Penyusun benar-benar membutuhkan ejaan yang tepat, oleh karena itu adalah ide yang buruk untuk menyediakan dua API berbeda untuk dua lokal. Dokumentasi dapat memenuhi dua lokal yang berbeda, tetapi API harus konsisten. Secara umum diharapkan bahwa meskipun API yang sama digunakan di wilayah berbeda yang menggunakan bahasa berbeda seperti Jerman, Prancis, Spanyol, dll., Meskipun dokumentasi dapat memberikan penjelasan dalam bahasa lokal, metode, variabel, dll. Semuanya akan mengikuti bahasa API asli (kemungkinan besar US Eng).
ADTC
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.