Cách thực hành tốt nhất cho các giá trị khóa trong các tệp dịch

Question

Nói chung, các phương thức dịch thuật lấy một ánh xạ khóa> giá trị và sử dụng khóa để chuyển đổi giá trị đó thành một giá trị. Bây giờ tôi nhận ra hai phương pháp khác nhau để đặt tên cho các khóa dịch thuật của bạn và trong nhóm của tôi, chúng tôi không đi đến sự đồng thuận những gì có vẻ là phương pháp tốt nhất.

Phương pháp 1: Sử dụng các từ tiếng Anh đầy đủ hoặc câu:

Name => Name 
Please enter your email address => Please enter your email address 

Cách 2: Sử dụng các từ khóa mô tả tình hình:

NAME => Name 
ENTER_EMAIL => Please enter your email address 

Cá nhân tôi thích phương pháp # 1 vì nó trực tiếp cho thấy ý nghĩa của thông điệp. Nếu bản dịch không có, bạn có thể quay trở lại khóa và điều này không gây ra bất kỳ vấn đề nào. Tuy nhiên, phương pháp này cồng kềnh khi một bản dịch thay đổi thường xuyên, bởi vì tất cả các tệp cần được cập nhật. Cũng cho các văn bản dài hơn các phím này trở nên rất lớn. Điều này được giải quyết bằng cách sử dụng các phím như ENTER_EMAIL, nhưng cách phân đoạn hoàn toàn nằm ngoài ngữ cảnh. Danh sách các phím dịch trừu tượng sẽ rất lớn, bạn cần dữ liệu meta cho tất cả các phím giải thích cách sử dụng và va chạm có thể xảy ra dễ dàng hơn nhiều.

Có cách nào tốt nhất cho cả hai thế giới hoặc phương pháp thứ ba? Làm thế nào để bạn sử dụng các phím dịch trong ứng dụng của bạn? Trong trường hợp của chúng tôi nó là một ứng dụng web dựa trên php, nhưng tôi nghĩ rằng vấn đề trên là đủ chung để nói về i18n nói chung.

Answer 1

Đây là câu hỏi mà các nhà phát triển iOS/OSX cũng phải đối mặt. Và đối với họ thậm chí còn có một standard tool called genstrings mà giả định phương pháp 1. Nhưng tất nhiên các nhà phát triển Apple không phải sử dụng công cụ này - tôi không.

Trong khi mạng an toàn mà bạn nhận được với phương pháp 1 là tốt (nghĩa là bạn có thể hiển thị khóa nếu bạn quên bản địa hóa chuỗi), nó có nhược điểm là nó có thể dẫn đến các khóa xung đột. Đôi khi một đoạn văn bản hiển thị giống hệt nhau cần được bản địa hóa theo hai cách khác nhau, do các quy tắc ngữ pháp hoặc sự khác biệt trong ngữ cảnh. Ví dụ: bản dịch tiếng Pháp cho "E-mail" sẽ là "E-mail" nếu đó là tiêu đề của hộp thoại và "Envoyer un e-mail" nếu đó là một nút (bằng tiếng Pháp, từ "E-mail" chỉ là danh từ và không thể được sử dụng như một động từ, không giống như trong tiếng Anh, nơi nó là cả một danh từ và một động từ). Với phương pháp 2, bạn có thể có các khóa EMAIL_TITLE và EMAIL_BUTTON để giải quyết vấn đề này và như một phần thưởng, điều này sẽ gợi ý cho người dịch để giúp họ dịch chính xác.

Một ưu điểm nữa của phương pháp 2 là bạn có thể thay đổi văn bản tiếng Anh mà không phải lo lắng về việc cập nhật khóa bằng tiếng Anh và trong tất cả các bản địa hóa của bạn.

Vì vậy, tôi khuyên bạn nên sử dụng phương pháp 2!

Answer 2

Tại sao không sử dụng cả hai thế giới? Tôi sử dụng phương pháp # 1 cho các chuỗi ngắn và phương pháp # 2 cho các chuỗi dài là các câu đầy đủ. Tôi không ngại trộn cả hai vào cùng một tập tin.

Ví dụ, trong các chuỗi sau khi văn bản có thể thay đổi nếu trong một phiên bản ứng dụng mới kinh nghiệm người dùng được cải tiến:

"screen description" = "Tap the plus button to add a new item. Tap an item for more options or to edit its details."; 

Vì vậy, đây nó làm cho tinh thần để áp dụng phương pháp # 2. Tuy nhiên, cho các chuỗi đơn giản như trong ví dụ sau, phương pháp # 1 là hữu ích hơn:

"Preferences" = "Preferences"; 

Nói chung khi người ta cố gắng chuẩn hóa mọi thứ nó thường xuất hiện hạn chế đối với tôi. Cá nhân, tôi thích một cách tiếp cận "vô chính phủ" hơn, nơi một số phương thức hợp lệ (không chỉ như trong phương pháp này # 1 so với phương pháp # 2, mà còn ví dụ khi một nhóm các nhà phát triển chiến đấu với kiểu mã hóa).