กลยุทธ์ที่มีประสิทธิภาพสำหรับการรองรับหลายภาษาใน. NET [ปิด]

ฉันกำลังพัฒนา UI สำหรับแอปพลิเคชัน. NET MVC ที่จะต้องมีการแปลเนื้อหาทั้งหมดในระดับสากลในอนาคตอันใกล้ ฉันคุ้นเคยกับ. NET โดยทั่วไป แต่ไม่เคยมีโครงการที่ต้องการความสำคัญในการเข้าถึงระหว่างประเทศ

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

คุณกำลังพัฒนาแอพพลิเคชั่น ASP.Net MVC ใช่ไหม คำตอบอื่น ๆ ดูเหมือนจะเฉพาะเจาะจงสำหรับแอปพลิเคชันเดสก์ท็อป ให้ฉันจับสิ่งทั่วไป:

การตรวจจับตำแหน่ง

มันค่อนข้างสำคัญที่แอปพลิเคชันของคุณจะตรวจจับตำแหน่งของผู้ใช้อย่างถูกต้อง ในแอปพลิเคชันเดสก์ท็อป CultureInfo.CurrentCulture มีโลแคลการจัดรูปแบบที่ต้องการ (อันที่ควรใช้เพื่อจัดรูปแบบตัวเลขวันที่สกุลเงิน ฯลฯ ) ในขณะที่ CultureInfo.CurrentUICulture มีโลแคลอินเทอร์เฟซผู้ใช้ที่ต้องการ . สำหรับเว็บแอปพลิเคชันคุณควรตั้งค่าทั้งสองวัฒนธรรมเป็นอัตโนมัติ (เพื่อตรวจหาสถานที่โดยอัตโนมัติจากส่วนหัวของ AcceptLanguage) เว้นแต่ว่าคุณต้องการที่จะใช้เวิร์กโฟลว์การตรวจจับสถานที่แฟนซีบางอย่าง (เช่นต้องการสนับสนุนภาษาที่เปลี่ยนแปลงตามต้องการ)

ส่งออกสตริง

สตริงทั้งหมดควรมาจากแหล่งข้อมูลนั่นคือไฟล์ Resx ในแอป Winforms สามารถทำได้อย่างง่ายดายโดยการตั้งค่าคุณสมบัติ Localizable ให้เป็นจริง นอกจากนี้คุณยังจะต้อง (ภายนอก) สตริงที่มาจากรุ่นของคุณด้วยตนเอง มันค่อนข้างง่าย ใน Asp.Net คุณจะต้องส่งออกทุกอย่างด้วยตนเอง ...

เลย์เอาต์

คุณต้องอนุญาตให้มีการขยายสตริง ในโลก Winforms สามารถทำได้ผ่าน TableLayoutPanel ซึ่งควรใช้เพื่อให้แน่ใจว่าเค้าโครงจะปรับโดยอัตโนมัติเพื่อรองรับข้อความที่ยาวขึ้น ในโลกเว็บคุณโชคไม่ดีเลยสักนิด คุณอาจจำเป็นต้องใช้ CSS Localization Mechanism - วิธีในการแก้ไข (แทนที่) คำจำกัดความของ CSS สิ่งนี้จะช่วยให้ผู้ใช้รองรับหลายภาษาสามารถแก้ไขปัญหาเกี่ยวกับรูปแบบได้ตามต้องการ ตรวจสอบให้แน่ใจว่าองค์ประกอบ HTML แต่ละหน้าในการแสดงผลมีรหัสที่ไม่ซ้ำกันซึ่งจะช่วยให้สามารถกำหนดเป้าหมายได้อย่างแม่นยำ

ปัญหาเฉพาะทางวัฒนธรรม

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

ToString () และ Parse ()

ตรวจสอบให้แน่ใจว่าได้ผ่าน CultureInfo ทุกครั้งเมื่อเรียก ToString () เว้นแต่ว่าไม่ได้รับการสนับสนุน ด้วยวิธีนี้คุณแสดงความคิดเห็นเจตนาของคุณ ตัวอย่างเช่น: หากคุณใช้หมายเลขภายในและด้วยเหตุผลบางอย่างจำเป็นต้องแปลงเป็นสตริงใช้:

int i = 42;
var s = i.ToString(CultureInfo.InvariantCulture);

สำหรับตัวเลขที่จะแสดงต่อผู้ใช้ให้ใช้:

var s = i.ToString(CultureInfo.CurrentCulture); // formatting culture used

เช่นเดียวกับ Parse (), TryParse () และแม้แต่ ParseExact () - ข้อผิดพลาดที่น่ารังเกียจบางอย่างอาจถูกนำมาใช้โดยไม่ต้องใช้ CultureInfo นั่นเป็นเพราะจิตวิญญาณที่ไม่ดีใน Microsoft เต็มไปด้วยความตั้งใจดีตัดสินใจว่าควรรักษา CultureInfo.CurrentCulture เป็นค่าเริ่มต้น (มันจะถูกใช้ถ้าคุณไม่ผ่านอะไรเลย) - หลังจากที่ทุกคนใช้ ToString ( ) เขา / เธอต้องการแสดงมันต่อผู้ใช้ใช่ไหม? เปิดใช้งานไม่ได้ทุกกรณี - ตัวอย่างเช่นพยายามเก็บหมายเลขเวอร์ชันแอปพลิเคชันของคุณในฐานข้อมูลแล้วแปลงเป็นอินสแตนซ์ของคลาสเวอร์ชัน โชคดี.

วันที่และเขตเวลา

ให้แน่ใจว่าได้เสมอเก็บและยกตัวอย่าง DateTime ใน UTC (ใช้แทน DateTime.UtcNow DateTime.Now) แปลงเป็นเวลาท้องถิ่นในรูปแบบท้องถิ่นเมื่อแสดง:

DateTime now = DateTime.UtcNow;
var s = now.ToLocalTime().ToString(CultureInfo.CurrentCulture);

หากคุณต้องการส่งอีเมลที่มีการอ้างอิงเวลาในเนื้อหาต้องแน่ใจว่าได้รวมข้อมูลเขตเวลา - รวมทั้ง UTC offset และรายชื่อเมือง:

DateTime someDate; // i.e. from database
var formattedDate = String.Format("{0} {1}", 
             someDate.ToLocaleTime().ToString(CultureInfo.CurrentCulture),
             TimeZoneInfo.Local.DisplayName);

ข้อความผสม

คุณได้รับคำเตือนแล้วว่าจะไม่ต่อสตริงเข้าด้วยกัน แต่คุณอาจจะใช้ String.Format () ดังที่แสดงไว้ด้านบน อย่างไรก็ตามฉันต้องระบุว่าคุณควรลดการใช้ข้อความผสม นั่นเป็นเพราะกฎไวยากรณ์เป้าหมายแตกต่างกันมากดังนั้นนักแปลอาจไม่จำเป็นต้องเรียงประโยคอีกครั้งเท่านั้น (ซึ่งจะแก้ไขได้โดยใช้ตัวยึดและสตริงรูปแบบ ()) แต่แปลประโยคทั้งหมดด้วยวิธีที่แตกต่างกันตาม สิ่งที่จะถูกแทนที่ ฉันขอยกตัวอย่างบางอย่างให้คุณ:

// Multiple plural forms
English: 4 viruses found.
Polish: Znaleziono 4 wirusy. **OR** Znaleziono 5 wirusów.

// Conjugation
English: Program encountered incorrect character | Application encountered incorrect character.
Polish: Program napotkał nieznaną literę | Aplikacja napotkała nieznaną literę.

ปัญหาการต่อข้อมูลอื่น ๆ

การต่อข้อมูลไม่ จำกัด เฉพาะสตริง หลีกเลี่ยงการวางการควบคุมร่วมกันพูด:

เตือนฉันอีกครั้งใน [กล่องข้อความพร้อมหมายเลข] วัน

สิ่งนี้ควรได้รับการออกแบบใหม่เพื่อ: เตือนฉันอีกครั้งในจำนวนวันนี้: [กล่องข้อความ]

การเข้ารหัสอักขระและแบบอักษร

บันทึกถ่ายโอนข้อความใน Unicode ทุกครั้ง (เช่นใน UTF-8) ห้ามใช้ฟอนต์แบบฮาร์โค้ด - การแปลเป็นภาษาท้องถิ่นอาจต้องแก้ไขและจะปิดกลไกฟอนต์ถอยแบบอักษรเริ่มต้น (ในกรณีของ Winforms) อย่าลืมอนุญาตให้ใช้อักขระ "แปลก" ในฟิลด์ส่วนใหญ่ (เช่นชื่อผู้ใช้)

ทดสอบ

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

สิ่งพื้นฐานบางอย่างที่คุณควรคำนึงถึง:

แปลงทรัพยากรสตริงทั้งหมดออก

ทรัพยากรทั้งหมดของคุณควรมีอยู่ในไฟล์ภายนอกที่สามารถส่งสำหรับการแปล อย่าลืมข้อความแสดงข้อผิดพลาดหากคุณต้องการให้แปลเป็นภาษาท้องถิ่นด้วย

อนุญาตให้มีพื้นที่เพียงพอสำหรับการขยายสตริง

สตริงในบางภาษามีแนวโน้มที่จะยาวขึ้นถึง 30% (เช่นกรีก) ดังนั้นโปรดตรวจสอบให้แน่ใจว่าคุณออกแบบ UI ของคุณด้วยวิธีดังกล่าวเพื่อให้สตริงสามารถขยายได้หากจำเป็น นี่เป็นตัวอย่างที่ดีมากสำหรับชาวฝรั่งเศส:

Ok -> Accepter (ภาษาฝรั่งเศส - ส่วนขยาย 400%)

ฉันขอแนะนำให้ทำการแปลแบบหลอกบางอย่างเป็นจุดเริ่มต้น ( http://en.wikipedia.org/wiki/Pseudolocalization ) หรือคุณสามารถแปลทรัพยากรของคุณผ่าน Google Translate หรือ Bing สิ่งนี้จะช่วยให้คุณมีตัวบ่งชี้ที่ดีว่าการแปลที่แท้จริงจะเป็นอย่างไร

ระวังข้อความในภาพ

หากคุณใช้รูปภาพใด ๆ ในแอปพลิเคชันของคุณโปรดตรวจสอบว่าไม่มีข้อความใด ๆ - ไม่สามารถแปลได้อย่างชัดเจน

ไม่ต้องฮาร์ดโค้ดพา ธ ไปยังโฟลเดอร์ Windows

ชัดเจน แต่ฉันเคยเห็นมาแล้วในอดีต ตัวอย่างเช่นC:\Program Filesมีการแปลใน Windows รุ่นสากลบางอย่างเช่นC:\Programmeอยู่ในระบบปฏิบัติการเยอรมัน

หลีกเลี่ยงการใช้คำศัพท์เฉพาะสถานที่

ตัวอย่างเช่นหากคุณถามใครบางคนเกี่ยวกับ 'โรงเรียนมัธยม' ของพวกเขาในรูปแบบสิ่งนี้มีความหมายเล็กน้อยในยุโรปตะวันตก

หลีกเลี่ยงการสร้างสตริงผ่านการต่อสตริง

ตัวอย่างเช่นสิ่งนี้ดูไม่เป็นอันตราย:

strWelcome = ReadExternalString("Welcome"); 
strMessage = strWelcome + ", " + UserName;

ตัวอย่างเช่นการเรียงลำดับคำในภาษาญี่ปุ่นจะแตกต่างกันดังนั้นสิ่งนี้อาจสิ้นสุดลงโดยที่ไม่มีเหตุผลใด ๆ

การตั้งค่าเวลา / วันที่

ให้แน่ใจว่าได้รูปแบบเวลา / วันที่ในระบบปฏิบัติการเสมอ

ข้อพิจารณาพิเศษสำหรับภาษาเอเชีย

นอกจากคำตอบที่ยอดเยี่ยมทั้งหมดแล้วที่นี่มีการระวังสำหรับภาษาเอเชีย:

ระวังข้อความที่มีความยาวต่างกัน

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

อย่างไรก็ตามข้อความภาษาญี่ปุ่นมักจะมีความยาวมากกว่าแม้จะยาวกว่าข้อความภาษาอังกฤษที่เทียบเท่าในแง่ของจำนวนตัวอักษร

ระวังเค้าโครงพื้นฐานและลักษณะ "เลื่อนขึ้น"

อักขระเอเชียมักจะวางบนเส้นฐานซึ่งไม่รวมถึงตัวคั่น (เช่นส่วนล่างของ y, g, q, j ฯลฯ ) เมื่อคุณจัดรูปแบบองค์ประกอบหน้าจอ - โดยปกติจะเป็นปุ่ม - พร้อมข้อความที่อยู่ภายในและหากเป็นเช่นนั้น ข้อความเป็นภาษาเอเชียเท่านั้น (เช่นไม่มีตัวอักษรตะวันตก) จากนั้นข้อความจะดูเหมือนว่าเลื่อนขึ้นด้านบน

การจัดรูปแบบของตัวเลขและหน่วยตัวเลขท้องถิ่น

จัดการการจัดรูปแบบตัวเลขต่างกัน ประเทศในเอเชียที่ต่างกันมีวิธีการจัดรูปแบบตัวเลขต่างกัน เช่นเดียวกับสกุลเงิน ตัวอย่างเช่นในเอเชียตะวันออก 10,000 (วัน) เป็นหน่วยทั่วไป ในอินเดีย 100,000 เรื่อง (แสนวิเศษ) เป็นเรื่องธรรมดา

สกุลเงินท้องถิ่น

สกุลเงินของบางประเทศมีค่าเป็นศูนย์จำนวนมากและไม่มีจุดทศนิยม (เช่นญี่ปุ่นอินโดนีเซียอิตาลี) ในขณะที่ประเทศอื่น ๆ มีตัวเลขสองหลักหลังจุดทศนิยม

ระวังคำสั่งต่าง ๆ

ลำดับของคำอาจไม่เหมือนกันเสมอไป ที่ดีที่สุดที่จะใช้ {0}, {1} ฯลฯ ในการจัดรูปแบบสตริงแทนคำสั่งเข้ารหัสยากถ้าสตริงของคุณมาจากการรวมกันของชิ้นส่วนของข้อมูลที่แตกต่างกัน

ใช้การจัดเรียงเฉพาะสถานที่

การเรียงลำดับนั้นแตกต่างกันไปตามภาษาและต่อสถานที่ - คุณควรพึ่งพาการเรียงลำดับเฉพาะของสถานที่ของ O / S

ใช้ความระมัดระวังอย่างยิ่งกับอักขระเต็มความกว้าง / ครึ่งความกว้าง

ระวังความแตกต่างระหว่างอักขระ "เต็มความกว้าง" และ "ครึ่งความกว้าง" เครื่องหมายวงเล็บเครื่องหมายวรรคตอน ฯลฯ อาจมีรุ่น "เต็มความกว้าง" ซึ่งแตกต่างจาก ASCII มาตรฐาน หากคุณทำการค้นหาหรือแยกสตริงโดยใช้ตัวอักษรเหล่านี้คุณจะต้องแปลงสัญลักษณ์เต็มความกว้างทั้งหมดให้เทียบเท่าครึ่งความกว้าง

จุดไม่ใช่จุด ... เครื่องหมายจุลภาคไม่ใช่เครื่องหมายจุลภาค ...

ระวังการป้อนข้อมูล gotcha's - ตัวอย่างเช่นในภาษาจีนระยะเวลาไม่ใช่จุด "" เครื่องหมายจุลภาคมีความกว้างเต็มไม่ใช่ "," อย่าพยายามค้นหาเครื่องหมายวรรคตอนตะวันตกหากผู้ใช้ป้อนข้อมูลอาจเปิด IME ภาษาเอเชียโดยไม่ตั้งใจ

เบอร์โทรศัพท์

อย่าคาดเดาสิ่งใดในการจัดรูปแบบหมายเลขโทรศัพท์ ไม่มีรหัสพื้นที่ ฯลฯ เสมอไปและสามารถจัดรูปแบบแตกต่างกันได้ โดยปกติแล้วจะมีสตริงรูปแบบต่อประเทศ

อย่าคิดคนเท่านั้นที่จะมีหนึ่งหมายเลขโทรศัพท์มือถือหรือหนึ่งหมายเลขโทรสาร ฯลฯ มันไม่ได้เป็นแบบนี้ในเอเชีย

ที่อยู่ - หนาแน่นกว่าที่คุณคิด

สำหรับที่อยู่ที่ไม่คิดอะไร อาจมีรหัสไปรษณีย์ไม่ได้เสมอไป รหัสไปรษณีย์อาจไม่ใช่ตัวเลขเสมอไป ประเทศอาจไม่มีจังหวัด / รัฐ ประเทศอาจเป็นเพียงเมืองใหญ่ (เช่นสิงคโปร์) สำหรับบางประเทศในเอเชียหน่วยที่เล็กที่สุดของบ้านอาจเป็น "ห้อง X, หน่วย Y, ส่วน Z, ชั้น A, บล็อก B, กลุ่ม C, อสังหาริมทรัพย์ D" โดยทั่วไปแล้วจะมีความอิสระอย่างมากในจำนวนฟิลด์และจำนวนตัวอักษรที่อนุญาตในที่อยู่

Memorial ~

Memorial ~ ไม่ได้ จำกัด เฉพาะกับนายนาง ฯลฯ แม้ว่าคุณอาจมีความปลอดภัยในการใช้ "M" และ "F" สำหรับการมีเซ็กซ์ - เราไม่ได้ว่าแปลก ๆ ...

ขั้นตอนพื้นฐานบางอย่างเพื่อให้แน่ใจว่าสตริงใด ๆ ที่แสดงบนหน้าจอไม่ใช่ตัวอักษรในรหัสของคุณ หากคุณกำลังทำ Winforms แต่ละฟอร์มจะมีทรัพยากร UI สำหรับไดอะล็อกรายงาน ฯลฯ ให้แน่ใจว่าคุณใช้ไฟล์ทรัพยากรโครงการ

ดังนั้นแทนที่จะเป็น "การอัปโหลดล้มเหลว" ในรหัสของคุณคุณอาจมีทรัพยากรเช่นอัปโหลดอัปโหลด

วิธีนี้คุณสามารถสร้างไฟล์ทรัพยากรใหม่สำหรับแต่ละภาษาที่คุณใช้ (และ. Net จะช่วยในเรื่องนี้) และมีสตริงที่แปลเป็นภาษาท้องถิ่นในแต่ละไฟล์

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

ฉันขอแนะนำให้คุณเรียกใช้การวิเคราะห์รหัสFXCopหรือ Visual Studio (มันค่อนข้างเหมือนกัน) ในชุดประกอบของคุณ

พวกเขามีดีที่การตรวจสอบรหัส NET ที่ไม่ได้ใช้วัฒนธรรมที่มุ่งเน้น overloads ที่เหมาะสมเช่นนี้: CA1305: ระบุ IFormatProvider

ฉันต้องเพิ่มว่าเครื่องมือเหล่านี้น่าหงุดหงิดเพราะพวกเขามักจะตรวจจับปัญหาของ zillions ในรหัสของคุณ แต่ถึงกระนั้นแม้ว่าคุณจะไม่ปฏิบัติตามกฎแต่ละข้อคุณควรเรียนรู้มากมาย

นอกเหนือจากวิธีการโหลดทรัพยากรโดยเฉพาะฉันต้องแน่ใจว่าคุณทดสอบด้วยรุ่นที่แปลเป็นภาษาท้องถิ่นเพื่อเริ่มต้นด้วย มิฉะนั้นคุณจะไม่สังเกตเห็นสถานที่ซึ่งมีการพิจารณาความเป็นสากลจนกว่าจะสิ้นสุด

นอกจากคำแนะนำที่เป็นประโยชน์อื่น ๆ ทั้งหมดต่อไปนี้เป็นคำแนะนำบางส่วนที่ขาดหายไป:

พิจารณาว่าบางประเทศใช้มากกว่าหนึ่งภาษา ตัวอย่างเช่นในแคนาดาผู้ใช้คาดว่าจะสามารถสลับระหว่างภาษาอังกฤษและภาษาฝรั่งเศสได้อย่างง่ายดาย

หากคุณถามคำถามกับผู้ใช้ที่คาดว่าจะได้รับคำตอบเดียวอย่าคาดหวังให้ผู้ใช้กดปุ่ม 'Y' เพื่อบอกว่าใช่

ระวังให้ดีใน Stored procs ซึ่งวันที่ใน SQL DB อยู่ในรูปแบบ USA

การวางสตริงข้อความใน DB ช่วยให้คุณสามารถเพิ่มภาษาเพิ่มเติมในภายหลังโดยไม่ต้องปรับใช้ซ้ำ

เมื่อส่งไฟล์ข้อความที่เป็นลายลักษณ์อักษรเพื่อการแปลให้ใส่คำอธิบายบริบทไว้เสมอเพื่อให้แน่ใจว่าผู้แปลเลือกคำที่ถูกต้อง เช่นไม่มีบริบทคุณสามารถแปล "เสียงแหลม" เป็นสิ่งที่ต้องทำด้วยเสียงหรือสถานที่ที่คุณเล่นฟุตบอล

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

คุณต้องพิจารณา:

1. การกำหนดเส้นทางสำหรับหลายภาษา

2. ย้ายสตริง hardcode ทั้งหมดไปยังไฟล์ทรัพยากร

ตัวอย่างสำหรับคุณสมบัติ:

รุ่น:

[Display(Name = <Resource for display name>.<field for this property>)]
[Required(ErrorMessage = <Resource for error message>.<field for this validate message>)]
public string TestProperty { get; set; }

ดู:

@Html.LabelFor(m=>m.TestProperty)
@Html.EditorFor(m => m.TestProperty)
@Html.ValidationMessageFor(m => m.TestProperty)

นี่คือสิ่งที่ไม่ได้กล่าวถึงในคำตอบที่เหลือ

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

1. มีความเจ็บปวดในก้นเพื่อแก้ไขใน Visual Studio
2. จำกัด การแจกจ่ายและการจัดการทรัพยากรที่แปลแล้วหลังจากรวบรวมแอปพลิเคชัน / จัดส่ง / รัน

กรณีใช้งานที่เป็นไปได้ให้เตรียมชุดภาษาสำหรับแอปพลิเคชันของคุณและความสามารถในการนำเข้าและส่งออกภาษาผ่าน UI ไฟล์ RESX จะไม่ช่วยที่นี่

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

สิ่งที่สำคัญที่สุดคือการจัดการเนื้อหาในภาษาต่างๆ ฉันได้พัฒนา websistes สองสามตัวและจัดการเนื้อหาในภาษาต่าง ๆ เป็นความท้าทายที่ยิ่งใหญ่ที่สุด

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

คุณสามารถใช้นักแปลเพื่อแปลงค่าภาษาอังกฤษเป็นภาษาใดก็ได้

สรุปสิ่งที่ต้องพิจารณาในการทำให้เป็นสากล:

• ข้อมูลทั้งหมดควรเป็นสากล คำนึงถึงว่ากราฟิกอาจมีข้อมูลที่เราต้องการทำให้เป็นสากล

• ขนาดของเขตข้อมูลหรือสตริงขึ้นอยู่กับภาษาเพราะอาจทำให้เรามีปัญหา

• ลำดับของคำขึ้นอยู่กับภาษาที่เราเป็นดังนั้นลำดับในภาษาหนึ่งจะเหมือนกันในอีกภาษาหนึ่ง

• เราต้องคำนึงว่ารูปแบบวันที่จะเปลี่ยนจากภาษาหนึ่งเป็นอีกภาษาหนึ่ง

ทำแบบทดสอบตุรกี :

การทำให้เป็นสากลของซอฟต์แวร์เป็นเรื่องยากภายใต้สถานการณ์ที่ดีที่สุดแต่มันก็ทำให้ฉันประหลาดใจอยู่เสมอว่าประเทศใดประเทศหนึ่งเกิดการถกปัญหาเกี่ยวกับความเป็นสากล: ตุรกี ...

หากคุณสนใจเล็กน้อยเกี่ยวกับการแปลหรือสากลที่บังคับให้รหัสของคุณให้ทำงานภายใต้สถานที่ตุรกีโดยเร็วที่สุดเท่าที่เป็นไปได้พอสมควร มันเป็นสัญญาณเตือนที่แข็งแกร่งสำหรับรหัสของคุณที่ใช้งานเกือบทุกอย่าง - แต่ไม่ได้หมายความว่าทั้งหมด - วัฒนธรรมและที่ตั้ง ...

หากไซต์ / โปรแกรมของคุณทำงานได้ดีกับลูกค้าชาวตุรกีคุณสามารถมั่นใจได้ว่ามันจะทำงานบนแพลตฟอร์มอื่น ๆ ส่วนใหญ่