เหตุใดทรัพยากรสตริงจึงถูกเก็บภายนอกรหัสและไม่อยู่ในรหัส

โดยทั่วไปในหลาย ๆ แพลตฟอร์มฉันกำลังเขียนแหล่งข้อมูลสตริงของฉันไปยังไฟล์. resx หรือ. xml

นั่นคือบน iOS ฉันกำลังทำให้พวกเขาผ่านNSBundle.MainBundleและโดยใช้Context.Resourcesบน Android

อะไรคือข้อดีของวิธีการนี้และทำไมไม่ให้เข้าถึงโดยตรงในรหัสดังนั้นตัวอย่างเช่น:

1. ในโครงการข้ามแพลตฟอร์มแพลตฟอร์มใด ๆ สามารถเข้าถึงได้โดยตรงโดยไม่มีการรวมเข้าด้วยกัน

2. ไม่มีความกังวลในระหว่างการสร้างว่าทรัพยากรที่สร้างขึ้นนั้นดีหรือไม่

3. coder สามารถใช้ฟังก์ชันต่างๆเช่นการจัดการหลายภาษา

เรื่องสั้นสั้น: อะไรคือสาเหตุที่ทำให้โครงสร้างของทรัพยากรสตริงเป็นแบบนั้น?

[แก้ไข]

สมมติว่าไฟล์ของฉันเป็นส่วนหนึ่งของโครงการ "แกน" ที่แชร์ระหว่างโครงการอื่น (คิดเกี่ยวกับ PCL โครงสร้างไฟล์โครงการข้ามแพลตฟอร์ม)

และสมมติว่าไฟล์ของฉันคล้ายกับไฟล์. resx / .xml ทั้งหมดโดยมีลักษณะเช่นนี้ (ฉันไม่ใช่มืออาชีพในรูปแบบ xml ขอโทษด้วย!): พารามิเตอร์พารามิเตอร์

ดังนั้นนี่คือ XML แบบกำหนดเองโดยที่คุณชี้ไปที่คีย์ / ภาษาเพื่อรับสตริงที่เหมาะสม

ไฟล์ดังกล่าวจะเป็นส่วนหนึ่งของแอปพลิเคชันเช่นเดียวกับที่คุณเพิ่มไฟล์ใด ๆ ที่สามารถเข้าถึงได้ภายในแอพและระบบเพื่อเข้าถึงทรัพยากรสตริงโดยใช้ PCL นี่จะเป็นการเพิ่มโอเวอร์เฮดให้กับแอปพลิเคชันหรือไม่

รองรับหลายภาษาและสากล

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

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

นอกเหนือจากการทำให้เป็นสากล / การโลคัลไลซ์ชันการแยกสตริงข้อความออกเช่นนี้ยังช่วยให้ผู้พิสูจน์อักษรสามารถส่งการแก้ไขไปยังการสะกด / ไวยากรณ์ / เครื่องหมายวรรคตอนที่แยกได้messages.${LOCALE}โดยไม่ต้องสัมผัสไฟล์ซอร์สโค้ดที่แท้จริง คุณอาจมีปัญหาในการเปลี่ยนรหัส แต่ยอมรับการแก้ไขข้อความดังกล่าว ถ้าคุณยอมรับการเปลี่ยนแปลงที่เกิดขึ้นพร้อมกันทั้งรหัสและข้อความทำให้พวกเขาแยกออกจากกันทำให้ง่ายต่อการผสานแพทช์ระบุว่าการเปลี่ยนแปลงรหัสไม่ redefine ข้อความใด ๆ messages.en_USที่มีอยู่เมื่อสำอางตรวจสอบออก

นอกจากนี้ยังอาจไม่จำเป็นต้องเชื่อมโยงแอปพลิเคชันอีกครั้งทั้งนี้ขึ้นอยู่กับวิธีการนำไปใช้ รหัสอาจคว้าสาย 138 จากmessages.${LOCALE}ข้อความที่ต้องการโดยมีการกำหนดหมายเลขบรรทัด ณ เวลาใช้งาน

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

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

ทางเลือกทั่วไปคือGNU Gettextวิธีการเพียงแค่ทำเครื่องหมายสายอักขระที่แปลได้ในซอร์สโค้ดและแยกสตริงเหล่านี้ไปยังไฟล์ PO มาตรฐานโดยอัตโนมัติซึ่งทำงานข้ามแพลตฟอร์มและข้ามภาษาได้โดยอัตโนมัติ จากมุมมองของนักพัฒนามันจะเป็นการบำรุงรักษาไฟล์ทรัพยากร XML ด้วยตนเองทุกวัน