Dấu hai chấm trong giao diện người dùng quốc tế

Khi sử dụng gettext hoặc một khung tương tự, các chuỗi dịch nên bao gồm ':'(như "Label:") để tạo nhãn cho UI hay tôi nên thêm ':'vào chính mã UI?

Dấu hai chấm có thể được coi là một biểu tượng dấu chấm câu. Đó là một quy ước là một phần của văn bản, giống như một dấu chấm hoặc dấu hỏi.

Chúng tôi sẽ không bỏ dấu chấm hỏi từ "Bạn có chắc chắn muốn thoát không?" và sau đó viết mã để thêm các thuộc tính câu hỏi theo cách phụ thuộc ngôn ngữ vào chuỗi dịch. Làm như vậy có nghĩa là mã UI không cần thiết đảm nhận trách nhiệm biết cách chấm câu trong các ngôn ngữ khác nhau: một trách nhiệm có thể được xử lý trong việc thay thế tin nhắn.

Có một khả năng trung gian. Có khả năng, giống như tất cả các nhãn có tính năng dấu hai chấm trong tiếng Anh, trong các ngôn ngữ khác, nhãn cũng có một số yếu tố từ vựng chung. Phần tử đó, nếu có, có lẽ là một loại tiền tố hoặc hậu tố, hoặc cả hai.

Bạn có thể đại diện cho các nhãn mà không cần trang trí, và sau đó có một chuỗi có thể dịch bổ sung cung cấp một lược đồ để thêm trang trí nhãn. Ví dụ, giả sử rằng sprintfđịnh dạng kiểu C có sẵn trong ứng dụng UI. Phiên bản tiếng Anh của chuỗi định dạng tạo nhãn sẽ là "%s:", và đó cũng có thể là mặc định, vì nó hoạt động ở một số ngôn ngữ khác. Các dịch giả UI có thể thay thế điều này "%s:"bằng bất cứ điều gì họ thấy phù hợp. Một trong những khả năng là họ có thể thay thế nó bằng chỉ "%s"(không làm gì) và sau đó chỉ định biểu diễn đầy đủ, được tô điểm của mỗi nhãn trong bảng chuỗi dịch. Vì vậy, cách tiếp cận này thậm chí xử lý một số khả năng kỳ lạ trong đó điểm đánh dấu từ vựng biểu thị nhãn phải được chèn vào giữa.

Cách tiếp cận này có vẻ không đáng, nếu tất cả những gì nó đạt được là một sự nén nhẹ trong biểu diễn các chuỗi nhãn: loại bỏ một ký tự dấu hai chấm. Nếu bạn phải viết thêm 100 ký tự cho mã này, bạn phải xóa dấu hai chấm khỏi 100 nhãn chỉ để hòa vốn: và điều đó thậm chí không tính đến việc chứng minh thời gian sử dụng.

Phải có một số tiền cho việc này: cụ thể là ứng dụng sử dụng các chuỗi cho các mục đích khác ngoài việc tạo nhãn, chẳng hạn như tạo các câu liên quan đến các trường UI theo tên. Giả sử rằng hộp thoại có nhãn "ID người dùng:" để nhập văn bản. Nếu bạn có logic chung tạo ra thông báo "Bạn đã nhập ID người dùng không hợp lệ." bằng cách kết hợp một văn bản soạn sẵn câu với tên của một thành phần UI, sau đó cần phải có chuỗi "ID người dùng" chưa được cung cấp và chuyển nó qua chức năng tạo nhãn để tạo "ID người dùng:".

Đối với nhiều ngôn ngữ, không có bản dịch một-một từ từ và cụm từ tiếng Anh, mà nhiều bản dịch có ngữ cảnh nhạy cảm.

Để làm cho cuộc sống của dịch giả dễ dàng hơn, bạn nên cung cấp càng nhiều ngữ cảnh cho các chuỗi càng tốt. Điều đó bao gồm dấu hai chấm trong nhãn và thông tin theo ngữ cảnh nơi các nhãn đó đang được sử dụng.

Theo quy định cơ bản, trong giao diện người dùng quốc tế, bạn nên

• không sửa đổi các chuỗi dịch, ngoại trừ để điền các tham số với các giá trị thực tế của chúng. Vì vậy, đừng thêm dấu hai chấm sau thực tế.
• không cắt chuỗi thành các phần xung quanh tham số. Đặc biệt, nếu có nhiều tham số được điền vào, bạn có thể chắc chắn rằng sẽ có ít nhất một ngôn ngữ mà ở đó sẽ tự nhiên hơn khi có các tham số theo cách khác.
• hãy thực sự cẩn thận với các hình thức số ít / số nhiều. Không có mô hình chung làm thế nào để tạo ra số nhiều từ số ít, hoặc thậm chí có bao nhiêu dạng số nhiều.

Cuối cùng tôi đã quyết định sử dụng toàn bộ chuỗi (chuỗi có dấu hai chấm trong trường hợp này) trong các tệp i18n của tôi.

Lý do cho điều này là trong tiếng Pháp nên có một khoảng trống trước dấu hai chấm. Vì vậy, cách tốt nhất để mã hóa tiếng Pháp là đặt dấu hai chấm (có dấu cách trước) vào chuỗi dịch.

Không, chúng tôi không dịch sang tiếng Pháp. Nhưng đây là một ví dụ cho một quy tắc hành vi chung: Đặt dấu hai chấm trong chuỗi dịch, không phải trong mã UI.

Cách tiếp cận tối ưu là nhúng các ký tự trong chuỗi cho từng miền, vì điều đó thường đảm bảo rằng bối cảnh là chính xác, giả sử bạn đã thực hiện nghiên cứu của mình như những gì đối tượng mục tiêu của bạn mong đợi.

Mỗi quốc gia thường cung cấp một hướng dẫn về phong cách, trong đó quy định tất cả các vị trí 'chính xác' cho dấu câu. Vì vậy, khi tôi bắt đầu tìm ra cách tôi sẽ xử lý các trích dẫn cho các ngôn ngữ khác nhau cho một số công cụ thiết kế web, trước tiên tôi đã xem các hướng dẫn về phong cách như vậy.

Tuy nhiên, trong khi các ấn phẩm bằng văn bản có xu hướng làm theo hướng dẫn phong cách, thế giới trực tuyến lại hoàn toàn khác! Thông thường, một số lượng lớn các trang web châu Âu và Nam Mỹ không phải tiếng Anh sử dụng các trích dẫn theo phong cách Hoa Kỳ, trái ngược với các máy chém («») trong các hướng dẫn về phong cách của họ. Chỉ cho thấy mức độ thống trị của Hoa Kỳ đối với web sớm cho phép sử dụng ngôn ngữ trực tuyến trên toàn thế giới.

Tin tức và báo chí ngoại ngữ MIT : Trang chủ có liên kết đến hàng trăm trang web trực tuyến. Nhìn vào những điều này đã giúp tôi tìm ra cách tiếp cận tốt nhất cho tình huống khó xử của mình, đó là cung cấp phương tiện cho chủ sở hữu trang web để chọn một trong 19 bộ trích dẫn phổ biến nhất - kết hợp trích dẫn phù hợp với đối tượng mục tiêu của họ.

Chrome cố gắng tự động sử dụng hướng dẫn kiểu của một quốc gia, nhưng may mắn thay, nó có thể bị ghi đè bằng cách chỉ định ngôn ngữ trong thuộc tính lang của thẻ q . Điều này nhấn mạnh vấn đề với các phương pháp tự động không tính đến thế giới thực, mà dựa vào lý thuyết cho việc triển khai của họ.

Đối với OP, nghiên cứu các trang báo trực tuyến đó để xem những gì thực sự được sử dụng ở các quốc gia khác nhau, để bạn có thể thấy cách tiếp cận nào sẽ cho kết quả phù hợp hơn.

Mặc dù một số ngôn ngữ thường sử dụng một ký tự khác cho dấu hai chấm tiếng Anh, việc sử dụng trực tuyến có thể nhắm mục tiêu đối tượng được sử dụng cho dấu hai chấm đó. Ngoài ra, các địa phương khác nhau có thể có cách sử dụng khác nhau, yêu cầu chỉ định các chuỗi ngôn ngữ theo từng địa điểm đầy đủ, thay vì chỉ theo ngôn ngữ.

Khi tôi đang thực hiện quốc tế hóa của mình vài năm trước, nó đã hoạt động như thế này:

• Tin nhắn trong mã nguồn được viết bằng tiếng Anh

• Các thông điệp được dịch trong thời gian chạy bằng cách áp dụng một bản dịch (xuất hiện trong nguồn dưới dạng dịch ("chuỗi") hoặc thường là / "chuỗi"). Dự kiến ​​sẽ có một từ điển xây dựng sẵn các thông điệp và bản dịch.

• Khi dịch một thông điệp, khoảng trắng ở mỗi đầu được cắt bớt và dấu chấm câu được loại bỏ, như mọi chữ viết hoa. Sau khi dịch những gì còn lại, những thứ này đã được đặt lại.

• Để cung cấp thêm ngữ cảnh, đôi khi tôi đã thêm một nhận xét vào chuỗi, đó là một phần của quy trình dịch thuật để giúp tìm ra kết quả phù hợp nhất, nhưng sau đó nhận xét đã bị loại bỏ.

Vì vậy, với một thông báo như "Đĩa:", chuỗi "đĩa" đã được dịch thành, nói, "disquette", và sau đó được viết lại thành "Disquette:". Điều này làm giảm số lượng tin nhắn rất giống nhau.

Tôi chỉ làm điều này cho một số ít ngôn ngữ Tây Âu; có lẽ sẽ có vấn đề với những người kỳ lạ hơn. Tuy nhiên, tôi đang sử dụng ngôn ngữ kiểu kịch bản cho việc này để có thể sử dụng một số xử lý chuỗi cho bất kỳ vấn đề nào xảy ra: khi tôi cần dịch "G" (viết tắt của Green), nó xuất hiện trong nguồn ở bên trái (/ "Green" ), được dịch thành một cái gì đó như "vert" và rút gọn thành "V".

Tuy nhiên tôi không quen thuộc với các khung hiện tại và cách chúng có thể hoạt động; họ không cung cấp bất kỳ hướng dẫn để xử lý các loại vấn đề này?

Nó có thể phụ thuộc vào hệ thống bản địa hóa mà bạn sử dụng, nhưng có những thứ khác như nhau, cá nhân tôi sẽ tránh thêm bất kỳ dấu câu nào (trừ khi trong cụm từ tất nhiên, trong đó việc sử dụng nó bị sai ngữ pháp), bởi vì tôi cảm thấy chúng là một phần của cách trình bày , như cỡ chữ, v.v., và không thực sự là nội dung . Vì vậy, chúng tôi pha trộn những thứ khác nhau với phương pháp này.

Rốt cuộc, những từ và cụm từ giống nhau có thể cần thiết cả có dấu câu và không có dấu câu. Ví dụ. bạn có thể có "Enter subject:"chú thích bên cạnh hộp văn bản, nhưng cũng có thể "Enter subject"là tiêu đề cửa sổ.

Liệu nó có ý nghĩa để có cả hai dịch riêng?

Khi bạn quyết định rằng dấu hai chấm thực sự trông xấu và dư thừa trong giao diện người dùng, bạn sẽ phải truyền lại tất cả các phiên bản ngôn ngữ. Mà hơi ngớ ngẩn.

Tái bút "Các quy tắc cơ bản" được đưa ra bởi @bartc là hợp lệ theo bất kỳ cách nào - cho dù bạn có bao gồm dấu chấm câu trong chuỗi dịch hay không.

PPS. @paulkayuk cũng vậy, nêu lên một điểm tốt (trong bình luận của anh ấy) - rằng đặc thù văn hóa cũng nên được xem xét. Nếu bạn có những thứ như dấu chấm hỏi được nhân đôi bằng tiếng Tây Ban Nha, hãy đưa chúng vào bản dịch của bạn. Câu trả lời của tôi giả định dấu chấm câu đồng nhất, ngôn ngữ bất khả tri, bởi vì đó dường như là một phần gây tranh cãi.

Một tập tin ngôn ngữ ứng dụng không chỉ là một bản dịch từ giả. Đây là một quá trình trong đó bạn dịch các từ và "trình bày" đúng dấu của chúng trong ngữ cảnh đầy đủ ý nghĩa .

Hello?trong tiếng Tây Ban Nha là ¿Hola?tiếng Ả Rập مرحبا؟. Như bạn có thể thấy, bạn không thể lưu trữ một Hellohoặc Holahoặc مرحباsau đó trong UI chỉ cần làm một the_hello_text + "?". Nó sẽ không tạo ra đầu ra chính xác. Rõ ràng là dấu câu cần phải được chăm sóc tại tệp ngôn ngữ. Điều đó có nghĩa là việc GUI "thêm" dấu chấm hỏi hoặc dấu hai chấm ở cuối chuỗi không phải là mối quan tâm của GUI.

Dấu câu và mọi thứ phải nằm trong tệp quốc tế hóa, sẵn sàng để được đưa ra UI.

Điều duy nhất UI nên quan tâm , là cách trình bày chính xác văn bản sẵn sàng bị bỏ qua này , giống như căn chỉnh ngay nếu là ngôn ngữ RTL. Nhưng đó là một câu chuyện khác và không có gì để làm với các tệp ngôn ngữ quốc tế hóa văn bản đơn giản .