Tại sao các tài nguyên chuỗi thường được giữ bên ngoài mã và không nằm trong mã?

Nói chung, trên nhiều nền tảng, tôi đang viết tài nguyên chuỗi của mình vào tệp .resx hoặc .xml, và sau đó tôi sẽ nhận được chúng bằng cách sử dụng một số cách tiếp cận phụ thuộc vào nền tảng.

Đó là, trên iOS, tôi nhận được chúng thông qua NSBundle.MainBundlevà bằng cách sử dụng Context.Resourcestrên Android.

Những lợi thế của phương pháp này là gì và tại sao không có nó có thể truy cập trực tiếp trong mã, ví dụ:

1. Trong một dự án đa nền tảng, bất kỳ nền tảng nào cũng có thể truy cập trực tiếp vào nó mà không cần tích hợp.

2. Không có mối quan tâm trong quá trình xây dựng về việc liệu các tài nguyên được xây dựng tốt hay không.

3. Bộ mã hóa có thể sử dụng các chức năng như xử lý đa ngôn ngữ

Câu chuyện dài: lý do tại sao tài nguyên chuỗi được cấu trúc theo cách đó là gì?

[Biên tập]

Giả sử tập tin của tôi là một phần của dự án "cốt lõi" được chia sẻ giữa các dự án khác. (Hãy nghĩ về PCL, cấu trúc tệp dự án đa nền tảng.)

Và giả sử rằng tệp của tôi hoàn toàn giống với tệp .resx / .xml, trông như thế này (Tôi không phải là chuyên gia trong xml, xin lỗi!): Tham số Paramètres

Vì vậy, về cơ bản, đây là một xml tùy chỉnh, nơi bạn trỏ đến khóa / ngôn ngữ để có được chuỗi thích hợp.

Tệp sẽ là một phần của ứng dụng giống như bạn thêm bất kỳ tệp nào có thể truy cập được trong ứng dụng và hệ thống để truy cập tài nguyên chuỗi, được mã hóa bằng PCL. Điều này sẽ thêm một chi phí cho các ứng dụng?

Bản địa hóa và quốc tế hóa,

Giữ các chuỗi bên ngoài cho phép chúng thay đổi (đọc: đã dịch) mà không cần phải biên dịch lại (chỉ là một bản phát lại nhiều nhất, và chỉ cần thả vào một thư mục mới là tốt nhất).

Nếu bạn có một tệp chỉ chứa các tài nguyên chuỗi thì bạn có thể cung cấp tệp tài nguyên cho cơ quan dịch thuật hoặc một cái gì đó tương tự và nhận bản dịch. Tôi đoán bạn có thể tưởng tượng sẽ khó đến mức nào nếu bạn phải đưa rất nhiều mật mã cho một giáo dân để thực hiện một số bản dịch (ngoài việc có thể không muốn đưa mã của bạn cho bất kỳ ai).

Ngoài việc quốc tế hóa / bản địa hóa, việc tách các chuỗi văn bản ra như thế này cũng cho phép một trình đọc bằng chứng gửi các sửa lỗi chính tả / ngữ pháp / dấu câu được cách ly messages.${LOCALE}mà không cần phải chạm vào một tệp mã nguồn thực sự. Bạn có thể mất điện về thay đổi mã nhưng chấp nhận sửa văn bản như vậy. Nếu bạn chấp nhận thay đổi đồng thời cho cả mã và tin nhắn, việc giữ chúng tách biệt sẽ giúp hợp nhất các bản vá dễ dàng hơn, miễn là các thay đổi mã không xác định lại bất kỳ thông báo nào tồn tại khi trình đọc bằng chứng kiểm tra messages.en_US.

Ngoài ra, tùy thuộc vào cách nó được triển khai, thậm chí có thể không cần thiết phải xem lại ứng dụng. Mã có thể chỉ đơn giản là lấy dòng 138 từ messages.${LOCALE}một thông điệp cụ thể, với số dòng được xác định khi chạy.

Đây chỉ là cách mà ngôn ngữ / nền tảng của bạn đã quyết định triển khai nội địa hóa chuỗi. Tất cả các phương pháp tiếp cận nội địa hóa cần một số loại tệp tài nguyên bên ngoài để có được các bản dịch từ đó. Điểm đau chính là cách bạn duy trì các tài nguyên này.

Có vẻ như bạn cần duy trì các tệp tài nguyên này theo cách thủ công , đây có thể là một gánh nặng khá lớn. Nó cũng làm phức tạp việc chia sẻ các chuỗi lặp đi lặp lại. Và phải làm điều này khi bạn hiện chỉ vận chuyển một ngôn ngữ, thậm chí còn trở thành gánh nặng nhiều hơn.

Một cách khác phổ biến là cách tiếp cận GNU Gettext chỉ đánh dấu các chuỗi có thể dịch trong mã nguồn và tự động trích xuất các chuỗi này thành các tệp PO tiêu chuẩn hoạt động đa nền tảng và ngôn ngữ chéo độc đáo. Từ góc độ nhà phát triển, nó đánh bại việc bảo trì thủ công các tệp tài nguyên XML bất kỳ ngày nào.