GB English หรือ US English?

หากคุณมี API และคุณเป็นนักพัฒนาในสหราชอาณาจักรที่มีผู้ชมจากต่างประเทศสูง API ของคุณควรเป็น

setColour()

หรือ

setColor()

(เพื่อใช้คำหนึ่งคำเป็นตัวอย่างง่ายๆ)

วิศวกรที่อยู่ในสหราชอาณาจักรมักจะค่อนข้างป้องกันเกี่ยวกับการสะกดคำที่ 'ถูกต้อง' แต่อาจเป็นที่ถกเถียงกันอยู่ว่าการสะกดของสหรัฐฯเป็น 'มาตรฐาน' มากกว่าในตลาดต่างประเทศ

ฉันเดาว่าคำถามมันสำคัญหรือไม่? นักพัฒนาซอฟต์แวร์ในภาษาอื่น ๆ ต่อสู้กับการสะกด GB หรือโดยปกติมันค่อนข้างชัดเจนว่าสิ่งต่างๆหมายถึงอะไร

ทุกอย่างควรเป็นภาษาอังกฤษแบบสหรัฐอเมริกาหรือไม่

ฉันมักจะใช้ภาษาอังกฤษแบบสหรัฐอเมริกาซึ่งกลายเป็นบรรทัดฐานใน API อื่น ๆ พูดในฐานะโปรแกรมเมอร์ภาษาอังกฤษฉันไม่มีปัญหาในการใช้ "สี" เช่น

ฉันไม่ใช่เจ้าของภาษา en-gbในการเขียนฉันพยายามที่จะใช้ อย่างไรก็ตามในการเขียนโปรแกรมฉันมักจะใช้en-usแทน British English ด้วยเหตุผลเดียวกันกับที่ฉันไม่ได้ใช้ภาษาเยอรมันหรือฝรั่งเศสสำหรับตัวระบุของฉัน

โดยทั่วไปฉันจะเป็นคนยึดติดสำหรับการสะกด GB แต่ฉันคิดว่ารหัสอ่านได้ดีกว่ามากถ้ามันสอดคล้องกันและฉันพบว่า:

Color lineColor = Color.Red;

ไปดูกันเลยดีกว่า:

Color lineColour = Color.Red;

ฉันเดาว่าในที่สุดมันก็ไม่สำคัญ

ขึ้นอยู่กับว่าคุณเห็นลูกค้าส่วนใหญ่ที่ใด โดยส่วนตัวแล้วฉันชอบใช้ English-GB (เช่น Color) ในรหัสส่วนตัวของฉัน แต่ฉันไปที่ Color สำหรับแอปพลิเคชัน / API / รหัสที่เผยแพร่ภายนอก!

แม้ว่าโดยปกติแล้วฉันจะอวดดีในเรื่องการสะกดคำที่ถูกต้อง แต่ในฐานะนักพัฒนาในสหราชอาณาจักรฉันมักจะใช้การสะกด 'สี' แบบอเมริกัน ในภาษาโปรแกรมทั้งหมดที่ฉันเคยพบมันเป็นเช่นนี้ดังนั้นเพื่อความสอดคล้องการใช้ 'สี' จึงมีความหมายมาก

สมมติว่านี่เป็น Java หรือ C # API อาจไม่สำคัญเนื่องจากความแพร่หลายของฟังก์ชันการเติมข้อความอัตโนมัติใน IDE หากนี่เป็นภาษาไดนามิกหรือภาษาที่ IDE สมัยใหม่ไม่ใช่บรรทัดฐานฉันจะใช้การสะกดแบบอเมริกัน แน่นอนว่าฉันเป็นคนอเมริกันและเห็นได้ชัดว่ามีความลำเอียง แต่ดูเหมือนว่าโค้ดส่วนใหญ่ที่ฉันเห็นจากนักพัฒนาที่ไม่ใช่เจ้าของภาษาใช้การสะกดแบบสหรัฐอเมริกาสำหรับชื่อตัวแปรของพวกเขาเป็นต้น

ในฐานะโปรแกรมเมอร์ภาษาอังกฤษฉันใช้ en-US สำหรับนักพัฒนาซอฟต์แวร์ของฉัน ภาษาอังกฤษแบบอเมริกันมีอิทธิพลอย่างมากในเกือบทุก API อื่น ๆ ซึ่งง่ายกว่ามากที่จะยึดติดกับการสะกดประเภทหนึ่งและลบความคลุมเครือ เสียเวลาในการค้นหาวิธีการเดียวที่จะพบว่าการสะกดถูกปิดด้วยตัวอักษรเดียวเนื่องจากการสะกดคำ

ฉันจะใช้มาตรฐานปัจจุบันและเลือกตัวสะกดภาษาอังกฤษแบบสหรัฐอเมริกา HTML และ CSS เป็นมาตรฐานที่ได้รับการยอมรับด้วยการสะกด "color" ประการที่สองหากคุณกำลังทำงานกับกรอบงานเช่น. NET โอกาสที่คุณจะมีสีอยู่แล้วในช่องว่างชื่ออื่น

ภาษีทางใจที่ต้องจัดการกับการสะกดสองครั้งจะขัดขวางมากกว่าช่วยนักพัฒนา

Label myLabel.color = setColour();

ฉันมีปัญหากับ API ที่ไม่ใช่ภาษาอังกฤษแบบสหรัฐอเมริกา เพียงเพราะความแตกต่างของการสะกด ฉันรู้ว่าคำนี้หมายถึงอะไร แต่การสะกดคำที่แตกต่างกันทำให้ฉันเข้าใจ

ไลบรารีและเฟรมเวิร์กส่วนใหญ่ที่ฉันคุ้นเคยใช้การสะกดแบบสหรัฐอเมริกา แน่นอนฉันเป็นคนอเมริกันดังนั้น ... US-English เป็นภาษาแม่ของฉัน

เอกสารประกอบการพัฒนาส่วนใหญ่ (เช่นเดียวกับ MSDN) เป็นภาษาอังกฤษแบบอเมริกัน

ดังนั้นจึงอาจเป็นการดีกว่าที่จะอยู่กับสตรีมหลักและใช้ภาษาอังกฤษแบบอเมริกันใน API ของคุณหากคุณกำหนดเป้าหมายผู้ชมจากต่างประเทศ

ฉันมีตัวอย่างอื่น: Serialise และ Serialize :)

ส่วนตัวไม่คิดว่าเรื่องมาก ฉันทำงานในโครงการที่ใช้ประเทศที่สะกดคำอังกฤษ - อังกฤษและพวกเขาใช้การสะกดแบบสหราชอาณาจักร มันยังคงเป็นภาษาอังกฤษและมันไม่สำคัญมากนักเนื่องจาก Intellisense

ในฐานะคนแคนาดาฉันเจอปัญหานี้ตลอดเวลา มันยากมากสำหรับฉันที่จะพิมพ์ "สี" เนื่องจากความทรงจำของกล้ามเนื้อของฉันเอื้อมไปหา "คุณ"

อย่างไรก็ตามฉันมักจะใช้ภาษาของห้องสมุด Java มีคลาส Color ดังนั้นฉันจึงใช้สี

ฉันพยายามหาคำอื่นถ้าเป็นไปได้ ฉันจะปล่อยสไลด์ สำหรับสีฉันอาจใช้ Hue, Ink, Foreground / Background ...

ถ้าไม่ใช่ในฐานะคนอังกฤษฉันจะใช้ en-GB เพราะฉันมีความภาคภูมิใจในประเทศและต้นกำเนิดของฉัน

อย่างไรก็ตามหากต้องเป็นส่วนหนึ่งของโครงการที่ใหญ่กว่าโดยเฉพาะโครงการระหว่างประเทศฉันจะทำให้โครงการทั้งหมดสอดคล้องกันข้างต้นโดยมีส่วนเล็ก ๆ อยู่ในรูปแบบภาษาหนึ่งและส่วนที่เหลือในอีกโครงการหนึ่ง

ฉันจะต้องใช้ภาษาอังกฤษแบบสหรัฐฯ - อังกฤษเพื่อให้ทุกอย่างสอดคล้องกัน (ตามที่คนอื่น ๆ ได้กล่าวไว้แล้วที่นี่) แม้ว่าฉันจะเป็นคนพูดภาษาอังกฤษแบบสหรัฐอเมริกา แต่ฉันได้ทำโครงการซอฟต์แวร์กับ บริษัท ซอฟต์แวร์ทั้งในเยอรมันและสวีเดนและในทั้งสองกรณีการล่อลวงในบางครั้งอาจทำให้เพื่อนร่วมทีมของฉันใช้ข้อความภาษาเยอรมันหรือภาษาสวีเดนในรหัสซึ่งโดยปกติจะแสดงความคิดเห็น แต่ บางครั้งยังใช้สำหรับชื่อตัวแปรหรือเมธอด แม้ว่าฉันจะพูดภาษาเหล่านั้นได้ แต่มันก็สั่นสะเทือนในสายตามากและทำให้การนำผู้ที่ไม่ใช่ผู้พูดคนใหม่เข้ามาในโครงการนั้นยากขึ้น

บริษัท ซอฟต์แวร์ในยุโรปส่วนใหญ่ (อย่างน้อย บริษัท ที่ฉันเคยทำงานด้วย) มีพฤติกรรมในลักษณะเดียวกัน - โค้ดยังคงเป็นภาษาอังกฤษเพียงเพราะทำให้โค้ดเป็นมิตรกับสากลมากขึ้นหากโปรแกรมเมอร์คนอื่นเข้ามาบนเรือ เอกสารภายในมักจะทำในภาษาแม่

ที่กล่าวว่าความแตกต่างในที่นี้คือภาษาอังกฤษสองภาษาที่แตกต่างกันซึ่งไม่ได้รุนแรงเท่ากับการเห็นสองภาษาที่แตกต่างกันโดยสิ้นเชิงในไฟล์ซอร์สโค้ดเดียวกัน ดังนั้นฉันจะบอกว่าให้เก็บ API เป็นภาษาอังกฤษแบบสหรัฐอเมริกา แต่ความคิดเห็นของคุณเป็น GB-English หากเหมาะสมกับคุณมากกว่า

ฉันจะบอกว่าให้ดูว่าห้องสมุดอื่น ๆ ในภาษาของคุณเลือกอย่างไรและทำตามแบบแผน

นักออกแบบของภาษาโปรแกรมและ API ในตัวได้ทำการเลือกและไม่ว่าผู้ใช้จะเป็นชาวต่างชาติหรือไม่พวกเขาคุ้นเคยกับการเห็นการสะกดที่สอดคล้องกับตัวเลือกนี้ คุณไม่ได้กำหนดเป้าหมายผู้พูดภาษาอื่น แต่เป็นผู้ใช้ภาษาโปรแกรม พวกเขาได้เรียนรู้คำศัพท์ในภาษาต่างประเทศจาก API ในตัวค่อนข้างน้อยและพวกเขาอาจไม่ทราบว่ามีความแตกต่างระหว่างภาษาอังกฤษแบบสหรัฐอเมริกาและภาษาอังกฤษแบบ GB อย่าสับสนโดยการสลับข้างบ่อ

ฉันใช้ภาษา. NET เป็นหลักและ. NET Framework ใช้การสะกดภาษาอังกฤษแบบสหรัฐอเมริกา บนแพลตฟอร์มนี้ฉันใช้ภาษาอังกฤษแบบสหรัฐอเมริกา ฉันไม่ทราบภาษาใด ๆ ที่เป็นมาตรฐานใน GB English แต่ถ้าคุณทำเช่นนั้นโดยทั้งหมดแล้วจะสอดคล้องกับภาษานั้น ๆ

ฉันเห็นด้วยกับคณะ "go for American" ตัวฉันเองชอบ en-GB เมื่อเขียนอีเมลและอื่น ๆ แต่ภาษาอังกฤษแบบอเมริกันเป็นมาตรฐานในแวดวงการเขียนโปรแกรมทั้งหมด

แม้ว่าภาษาอังกฤษแบบบริติชจะเป็นสิ่งที่พูดกันทั่วโลก แต่ฉันขอแนะนำให้ใช้ภาษาอังกฤษแบบอเมริกันซึ่งเหมือนกับที่คนอื่น ๆ กล่าวว่าครองตลาด

แน่นอนภาษาอังกฤษ

อันดับแรกฉันอยู่ในสหรัฐอเมริกา ในโปรเจ็กต์ปัจจุบันของฉันมันเป็น "สี" เสมออย่างไรก็ตามคำที่ดูเหมือนว่าเราไม่สามารถเลือกตัวสะกดได้คือ "สีเทา" กับ "สีเทา"

จริงๆแล้วมันค่อนข้างน่ารำคาญ

การเลือกภาษาสำหรับชื่อตัวระบุไม่มีส่วนเกี่ยวข้องกับผู้ชมและทุกอย่างเกี่ยวข้องกับภาษาดั้งเดิมที่พัฒนากรอบงานหรือ API

ฉันไม่รู้หลายภาษา แต่คิดไม่ออกว่าภาษาเดียวที่ใช้ภาษาอื่นนอกจากภาษาอังกฤษแบบสหรัฐอเมริกา

อันตรายจากการแนะนำจุดบกพร่องที่ละเอียดอ่อนเนื่องจากการสะกดที่แตกต่างกันนั้นยอดเยี่ยมเกินไป IMHO

การแทนที่ฟังก์ชันอาจกลายเป็นการโอเวอร์โหลดหลอกได้อย่างง่ายดาย

ไฟล์กำหนดค่าอาจไม่ถูกต้องเนื่องจากความแตกต่างในการสะกดคำ

สถานการณ์อาจเกิดขึ้นเมื่อวัตถุแนวความคิดเดียวกันถูกกำหนดโดยใช้หลายคลาสโดยใช้ทั้ง en-US และ en-GB

ดังนั้นไม่ว่าโค้ดส่วนหนึ่งจะมีไว้สำหรับการใช้งานภายในอย่างแท้จริงหรือมีไว้สำหรับการใช้งานภายนอกเช่นกันการสะกดที่ใช้จะต้องตรงกับภาษาดั้งเดิมของแพลตฟอร์ม / เฟรมเวิร์ก / คอมไพเลอร์ / API เสมอ

หากโปรแกรมเมอร์ของคุณทั้งหมดเป็นชาวอังกฤษให้ใช้ en-gb หากโปรแกรมเมอร์นอกสหราชอาณาจักรจะเห็นโค้ดของคุณ en-us จะเป็นทางเลือกที่ดีกว่า

จุดด้อยอีกประการหนึ่งเราต้องใช้บริการแปลเพื่อคัดลอกเอกสารของเราเป็นภาษาอื่น เราพบว่าเราได้รับการแปลที่ดีขึ้นเมื่อใช้ en-us เป็นแหล่งที่มา

คุณต้องพิจารณาผู้ชมของคุณ ใครจะใช้รหัสและพวกเขาคาดหวังว่าจะได้เห็นอะไร?

ฉันทำงานใน บริษัท ที่มีสำนักงานทั้งในแคนาดาและสหรัฐอเมริกา เราใช้การสะกดแบบแคนาดา (คล้ายกับภาษาอังกฤษแบบบริติช) เมื่อจัดทำเอกสารและรหัสในแคนาดาและการสะกดแบบสหรัฐอเมริกาสำหรับสิ่งที่ใช้ในสหรัฐอเมริกา

บางอย่างข้ามพรมแดน แต่ความแตกต่างในการสะกดไม่ค่อยเป็นปัญหา มันสามารถสร้างบทสนทนาที่น่าสนใจได้อย่างชัดเจนเมื่อคนอเมริกันไม่ทราบถึงการสะกดที่แตกต่างกันสำหรับ Candian และ British English บางครั้งพวกเขาก็โอเคกับมันบางครั้งพวกเขายืนยันที่จะเปลี่ยนเป็นการสะกดที่ "ถูกต้อง" นอกจากนี้ยังมีผลต่อรูปแบบวันที่ (dd / mm / yyyy ในแคนาดาและ mm / dd / yyyy ในสหรัฐอเมริกา)

เมื่อมีทางตันเรามักจะใช้การสะกดแบบสหรัฐอเมริกาเนื่องจากผู้คนในแคนาดาคุ้นเคยกับทั้งสองรูปแบบ

เหตุผลหลักที่ฉันเคยได้ยินมาในการเลือก US มากกว่า UK English เป็นเพราะผู้ชมในสหราชอาณาจักรเมื่อต้องเผชิญกับการสะกดคำของสหรัฐอเมริกาตระหนักว่าเป็นแอปพลิเคชันของสหรัฐอเมริกา (หรือคิดว่าเป็นเช่นนั้น) ในขณะที่ผู้ชมในสหรัฐอเมริกาที่ต้องเผชิญกับการสะกดคำในสหราชอาณาจักรคิดว่า '.. . เดี๋ยวก่อนผิด.. มันไม่ใช่สี '

แต่ก็เหมือนที่คนอื่น ๆ บอกว่าสร้างมาตรฐาน เลือกและติดมัน

มันเป็นเรื่องธรรมดาสำหรับฉันที่จะทำงานเป็นภาษาอังกฤษแบบสหราชอาณาจักรโดยไม่ได้คิดถึงเรื่องนี้ อย่างไรก็ตามหากคุณกำลังพัฒนาขั้นตอนภายในมันไม่สำคัญจริงๆ หากคุณกำลังสร้าง API ที่จะใช้แบบสาธารณะและผู้ชมของคุณเป็นสากลทำไมไม่ใช้ทั้งสองอย่าง

ฉันชอบภาษาอังกฤษแบบสหรัฐอเมริกา

ฉันเป็นหนึ่งในคนเหล่านี้ที่อัตราการเต้นของหัวใจและความดันโลหิตสูงขึ้นทุกครั้งที่ฉันถูกบังคับให้ใช้ภาษาอังกฤษแบบอเมริกันในไฟล์ติดตั้ง ฯลฯ เนื่องจากซอฟต์แวร์ไม่ได้ให้ตัวเลือกสำหรับภาษาอังกฤษแบบอังกฤษ แต่นั่นเป็นเพียง ผม :)

ความคิดเห็นส่วนตัวของฉันเกี่ยวกับเรื่องนี้อย่างไรก็ตามจะให้การสะกดทั้งสองให้ setColor () และ setColour () เขียนโค้ดในหนึ่งในนั้นและให้อันที่สองส่งผ่านพารามิเตอร์

ด้วยวิธีนี้คุณจะทำให้ทั้งสองกลุ่มมีความสุขการได้รับ Intellisense ของคุณจะนานขึ้นเล็กน้อย แต่อย่างน้อยคนก็ไม่สามารถบ่นว่าคุณใช้ภาษาที่ 'ผิด' ได้

หากคุณมองย้อนกลับไปสักสองสามร้อยปีคุณจะพบว่าการเปลี่ยนแปลงนี้ไม่ได้เกี่ยวข้องอะไรกับสหรัฐฯมากเท่ากับที่หลาย ๆ คนคิดเช่นนั้น การเปลี่ยนแปลงเกิดจากอิทธิพลของยุโรปโดยเฉพาะฝรั่งเศส ก่อนหน้านั้นคำภาษาอังกฤษ "color" นั้นจริงแล้วสะกดว่า "color"

การพยายามสร้างมาตรฐานจะเป็นเรื่องไร้ผลเนื่องจากเด็กจีนครึ่งหนึ่งกำลังเรียนรู้อิทธิพลของยุโรปในยุคก่อนและความเข้าใจภาษาอังกฤษของสหรัฐฯในขณะที่อีกครึ่งหนึ่งกำลังใช้ภาษาอังกฤษในปัจจุบัน

หากคุณคิดว่าภาษาเป็นปัญหาคุณควรพิจารณา Taiwan Kg ซึ่งมีน้ำหนัก 600g ฉันยังไม่ทราบว่าพวกเขาจัดการเรื่องนี้อย่างไร แต่ฉันหวังว่าพวกเขาจะไม่ถูกจ้างเป็นพนักงานเติมน้ำมันเครื่องบิน!

ฉันมักจะใช้ en-GB สำหรับการเขียนโปรแกรมทั้งหมดของฉัน ฉันเดาว่ามันเป็นเพราะอิทธิพลอย่างมากของนวนิยายอังกฤษ

อย่างไรก็ตามอาจเป็นไปไม่ได้ที่จะมี API สองชุดที่แตกต่างกัน (ชุดหนึ่งสำหรับ en-US หนึ่งชุดสำหรับ en-GB) ซึ่งเรียกใช้ฟังก์ชันเดียวกันภายในหรือไม่ สิ่งนี้อาจทำให้ไฟล์ส่วนหัวขยายได้ดังนั้นอาจขึ้นอยู่กับคำจำกัดความของตัวประมวลผลล่วงหน้าการคอมไพล์ตามเงื่อนไข? หากคุณใช้ C ++ คุณสามารถทำสิ่งต่างๆดังต่อไปนี้ ...

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

ขึ้นอยู่กับว่าโปรแกรมเมอร์ไคลเอนต์กำหนด ENGB หรือไม่ดังต่อไปนี้

#define ENGB

เขาสามารถใช้ API ในวัฒนธรรมที่เขาต้องการ อาจจะมากเกินไปสำหรับจุดประสงค์ที่ไม่สำคัญ แต่เดี๋ยวก่อนถ้ามันดูสำคัญทำไมไม่! :)