Làm thế nào để tổ chức tài nguyên chuỗi nội địa hóa?

Chúng tôi đang phát triển một ứng dụng lớn, bao gồm nhiều gói nhỏ. Mỗi gói có tập hợp các tệp tài nguyên riêng để bản địa hóa.

Cách tiếp cận tốt nhất để tổ chức và đặt tên các chuỗi nội địa hóa là gì?

Đây là những suy nghĩ của tôi cho đến nay:

Xử lý trùng lặp

Cùng một văn bản (giả sử, "Mã zip") có thể xảy ra nhiều lần trong một gói nhất định. Bản năng lập trình (DRY) bảo tôi tạo một tài nguyên chuỗi duy nhất được chia sẻ bởi tất cả các lần xuất hiện .

Sau đó, một lần nữa, một dịch giả có thể muốn chọn một bản dịch dài ("Postleitzahl") ở một số nơi và một bản dịch ngắn hơn ("PLZ") ở những nơi có ít không gian hơn. Hoặc chúng tôi có thể quyết định nối thêm dấu hai chấm vào một số lần xuất hiện ("Mã zip:"), nhưng không cho các trường hợp khác. Hoặc chúng tôi có thể yêu cầu viết hoa khác ("mã zip") ở một số nơi. Tất cả các đối số này đều chỉ ra việc tạo một tài nguyên cho mỗi lần sử dụng, ngay cả khi nội dung của chúng giống hệt nhau .

Đặt tên

Nếu chúng tôi nhắm đến việc loại bỏ các bản sao, việc đặt tên tài nguyên theo nội dung sẽ có ý nghĩa, có thể gợi ý về loại sử dụng thông qua tiền tố. Vì vậy, chúng tôi có thể có labelOK= "OK" , messageFileTooLarge= "Tệp vượt quá kích thước tệp tối đa." và labelZipCode= "Mã zip" .

Đặt tên theo nội dung có lợi thế là xử lý các đối số định dạng một cách tự nhiên: Tài nguyên messageFileHas_0_MBWhileMaximumIs_1_MBrõ ràng có hai đối số định dạng, kích thước tệp thực tế và kích thước tệp tối đa.

Tuy nhiên, nếu chúng tôi cho phép trùng lặp, chỉ đặt tên theo nội dung sẽ không có ý nghĩa. Để có được tên tài nguyên duy nhất, bằng cách nào đó chúng ta phải bao gồm nơi sử dụng trong tên tài nguyên. Điều đó hoạt động cho các điều khiển đồ họa, mặc dù các định danh có xu hướng hơi dài: fileSelectionConfirmationButtonText= "OK" , customerDetailsTableColumnZipCode= "Mã Zip" . Tuy nhiên, đối với các tệp mã không trực quan, nó trở nên khó hơn. Làm thế nào để bạn đặt tên cho một cách sử dụng cụ thể của một chuỗi nếu bạn không biết cuối cùng nó sẽ được hiển thị ở đâu? Theo tập tin mã và tên hàm? Có vẻ khá vụng về và dễ vỡ đối với tôi.

Nói chung, tôi nghiêng về việc cho phép các bản sao, nhưng tôi đang cố gắng tìm một sơ đồ đặt tên nhất quán hỗ trợ việc này.

Chỉnh sửa: Câu hỏi này có hai khía cạnh: Làm thế nào để tổ chức các nguồn lực (DRY vs bản sao) và làm thế nào để đặt tên cho chúng. Cho đến nay, các câu trả lời đã tập trung vào khía cạnh đầu tiên. Tôi đánh giá cao một số phản hồi về quy ước đặt tên!

Tôi sẽ chấp nhận sao chép bất cứ khi nào bạn không thể hoàn toàn chắc chắn ý nghĩa hoàn toàn giống nhau trong mọi trường hợp một chuỗi nhất định được sử dụng.

Ngay cả khi hai nhãn luôn chứa cùng một chuỗi trong tiếng Anh (hoặc tiếng mẹ đẻ của bạn), chúng sẽ không nhất thiết phải giống nhau trong tất cả các ngôn ngữ. Chấp nhận sao chép có thể cung cấp cho bạn (hay đúng hơn là người dịch) sự linh hoạt cần thiết để xử lý các tình huống đó.

Ví dụ: Xem xét nhãn "Điều kiện", tùy theo ngữ cảnh - có thể được dịch sang "Zustand" hoặc "Bedingung" bằng tiếng Đức (trong số rất nhiều bản dịch có thể khác).

Chấp nhận một số trùng lặp.

Bạn có thể tránh một số bản dịch bằng cách tạo thêm các điều khiển. Ví dụ: a CancelButtonvà một OKButtonđã chứa văn bản của họ, và bây giờ Hủy / Abbrechen OK / OK chỉ cần được dịch một lần. Nhưng đó gần như là một trường hợp đặc biệt.

Đây là cách chúng tôi xử lý nó trong công ty của tôi:

Quy ước đặt tên: Chúng tôi đặt tên nhãn bằng cách thêm tiền tố vào lớp / phần / biểu mẫu / v.v. Ví dụ loadFile_loadButton, loadFile_fileNameLabel, loadFile_cancellà tất cả các nhãn thuộc về một cuộc đối thoại Load File. Mặc dù quy ước đặt tên không được chú ý này không phải là phổ biến nhất, chúng tôi ủng hộ nó hơn các quy ước tiêu chuẩn hơn vì nó cải thiện khả năng đọc và "khả năng nhóm": chú ý xem nhãn đó thuộc về yếu tố nào và mỗi nhãn đại diện cho cái gì, so với nhãn được đặt tên loadFileLoadButton, loadFileNameLabelvà loadFileCancel. Bạn có thể nghĩ rằng sự khác biệt không phải là lớn, nhưng khi bạn có hàng ngàn nhãn, hiệu ứng gộp là xứng đáng.

Nhận xét tiêu đề: Bổ sung cho tiền tố tên nhãn, chúng tôi cũng thêm nhận xét "tiêu đề" vào tệp tài nguyên để xác định rõ ràng các nhóm nhãn. Bằng cách này, ai đó muốn sửa đổi hoặc thêm nhãn cụ thể liên quan đến một lớp / phần / biểu mẫu / vv cụ thể có thể tìm thấy tất cả các nhãn liên quan đến phần tử cụ thể đó chỉ trong một vị trí, dưới một tiêu đề và có thể dễ dàng tiến hành thêm hoặc sửa đổi nhãn dễ dàng biết rằng họ sẽ không phá vỡ các bản dịch cho bất kỳ yếu tố nào khác (IMHO, đây cũng là một điểm rất mạnh về lý do tại sao bạn cần cho phép sao chép).

Các bản sao "hợp lý" là mong muốn: Như đã đề cập ở trên, các thực tiễn này chắc chắn sẽ dẫn đến các nhãn trùng lặp, nhưng chúng tôi không thấy có vấn đề gì với điều đó (thêm về cách xử lý vấn đề này trong Công cụ giao dịch).

Như những người khác đã chỉ ra, một nhãn trong một ngôn ngữ có thể được dịch theo hai hoặc nhiều cách khác nhau trong các ngôn ngữ khác tùy thuộc vào bối cảnh chúng được trình bày. Nếu bạn "hợp nhất" các nhãn, người dịch sẽ có một thời gian thực sự khó khăn với một nhãn duy nhất phù hợp với tất cả các bối cảnh nơi nó được tìm thấy. Vì vậy, như chúng ta thấy, việc cho phép các bản sao "hợp lý" giúp cải thiện chất lượng bản địa hóa, miễn là chúng không đề cập đến cùng một điều trong cùng một bối cảnh (đây là ý nghĩa của "hợp lý").

Công cụ giao dịch: Để có hiệu quả nhất có thể khi thực hiện các bản dịch của mình, bạn có thể xây dựng công cụ của riêng mình để tìm các nhãn tương tự tồn tại trong gói của bạn và cung cấp bản dịch của chúng dưới dạng giá trị mặc định cho nhãn mới hoặc thậm chí bạn có thể sử dụng các dịch vụ hiện có như dịch vụ này , cung cấp các công cụ như tôi vừa đề cập, giúp việc dịch nhãn mới trở nên dễ dàng (thậm chí nhiều hơn nếu chúng được lặp lại nhiều lần, vì công cụ sẽ cung cấp cho bạn một số tùy chọn dịch theo mặc định cho nhãn mới ).

Tóm tắt: Sao chép hợp lý và có các nhãn được nhóm theo một ngữ cảnh thực sự giúp người dịch thực hiện công việc của họ. Thời điểm trọng đại. Chỉ cần nghĩ về nó: có bối cảnh đi một chặng đường dài trong việc hỗ trợ người dịch để chọn bản dịch phù hợp. Và cho phép các bản sao "hợp lý" sẽ loại bỏ xung đột khi phải chọn một bản dịch phù hợp với một số bối cảnh (nhưng dù sao cũng phù hợp nhất với tổng thể).

Tôi hi vọng cái này giúp được!

Khi tôi đã làm điều này trong quá khứ, chúng tôi đã đi theo tuyến của tệp tài nguyên có chứa các câu đầy đủ. Nếu cùng một câu được sử dụng lặp đi lặp lại tuyệt vời, nhưng nếu đó chỉ là những từ riêng lẻ trong một câu thì những từ đó sẽ bị trùng lặp.

Chúng tôi đã được gắn với một khung trong đó tệp tài nguyên chỉ chứa một danh sách các cụm từ tiếng Anh theo sau là bản dịch (với một số dữ liệu lập chỉ mục ở cuối để tra cứu nhanh).

Đối với các dấu nhắc hoặc nút dữ liệu nhỏ, chẳng hạn như tên trường của "Mã ZIP" hoặc nút "OK", nó sẽ lưu trữ chuỗi "Mã ZIP" theo sau là bản dịch và sẽ sử dụng bất cứ nơi nào cần chuỗi đầy đủ. Nhưng (trừ khi chúng tôi tự ngắt chuỗi) sẽ không sử dụng chuỗi đó cho "Mã ZIP" xuất hiện trong câu.

Sử dụng ví dụ Mã ZIP của bạn, nếu bạn cố gắng tự dịch và thay thế nó trong tất cả các câu sử dụng nó, bạn sẽ nhận được một bản dịch rất tệ.

Ví dụ: "Phải nhập mã ZIP" có thể cần dịch tương đương theo nghĩa đen của "Mã ZIP đã nhập phải" bằng ngôn ngữ khác. Nếu bạn cắt một câu, bạn sẽ không nhận được sự đảo ngược của các từ cần thiết trong ngôn ngữ khác.

Đó là lý do tại sao một số bản dịch sai sang tiếng Anh trông rất lố bịch, người thực hiện nó chỉ dịch các từ riêng lẻ chứ không phải toàn bộ câu.

Chúng tôi luôn thấy tốt nhất để dịch toàn bộ câu, mà không phá vỡ chúng. Chúng tôi đã có chủ sở hữu vị trí cho dữ liệu cần chèn (ví dụ: "Phần số @ 1 là dự phòng") và người dịch có thể di chuyển người giữ chỗ đến vị trí họ muốn có bản dịch tốt.

Tuy nhiên, chúng tôi thấy rằng việc cho phép các địa điểm sử dụng chính xác cùng một câu hoặc cùng một dấu nhắc dữ liệu hoặc cùng nhãn nút, v.v., đều tốt để chia sẻ bản dịch. Điều đó không bao giờ được đưa ra như một vấn đề và tiết kiệm thời gian / chi phí cho người dịch.

Suy nghĩ của bạn về việc đặt tên là tốt.

Mục tiêu

• Xác định nhãn chung (tức là tên biến) cho văn bản địa phương.
• Nhãn phải là "cỡ tâm". Đó là ... thực tế ngắn trong khi không rõ ràng.
• Các nhãn phải tuân theo một định dạng nhất quán để tối đa hóa khả năng dự đoán và thu hồi.

Thực hiện

• Giảm tải nhận thức với việc sử dụng nhất quán các chữ viết tắt nổi tiếng (ví dụ: thông điệp = tin nhắn, lbl = nhãn, btn = nút, ...)
• Các công cụ trình bày các biến / nhãn trong danh sách theo thứ tự chữ cái, vì vậy việc tra cứu con người là tốt nhất khi các nhãn liên quan nhóm lại với nhau. Đặt tên theo thứ bậc từ tổng quát nhất đến cụ thể nhất. (ví dụ: dirFileMissing, dirFileSatted, dirFileDelatted).
• Tiếng Anh là một động từ - danh từ ngôn ngữ. Nhiều (hầu hết?) Các ngôn ngữ khác là danh từ-động từ. Danh từ-động từ hoạt động tốt nhất cho việc phân nhóm.