Gettext: Ý tưởng tốt cho ID tin nhắn có phải là văn bản tiếng Anh không?

Question

Chúng tôi đã sẵn sàng dịch trang web PHP của chúng tôi sang nhiều ngôn ngữ khác nhau và hỗ trợ gettext trong PHP giống như cách để đi.

Tất cả các hướng dẫn Tôi thấy khuyên bạn sử dụng các văn bản tiếng anh như ID tin nhắn, ví dụ:

gettext ("Hi there!")

Nhưng là thực sự là một ý tưởng tốt? Giả sử ai đó trong tiếp thị muốn thay đổi văn bản thành "Xin chào, y'all!". Sau đó, bạn không phải cập nhật tất cả các tập tin ngôn ngữ bởi vì chuỗi đó - mà thực sự là ID tin nhắn - đã thay đổi?

Tốt hơn là nên có một số loại ID chung, như "hello.message" và tệp bản dịch tiếng Anh?

Answer 1

Tôi sử dụng các ID có ý nghĩa như "welcome_back_1" là "welcome back, %1" v.v. Tôi luôn có tiếng Anh làm ngôn ngữ "cơ sở" của mình để trong trường hợp xấu nhất khi ngôn ngữ cụ thể không có ID thông báo, tôi mùa thu về tiếng Anh.

Tôi không thích sử dụng cụm từ tiếng Anh thực sự làm ID tin nhắn bởi vì nếu tiếng Anh thay đổi thì ID cũng vậy. Điều này có thể không ảnh hưởng đến bạn nhiều nếu bạn sử dụng một số công cụ tự động, nhưng nó làm tôi khó chịu. Tôi không thích sử dụng các mã đơn giản (như msg3975) vì chúng không có ý nghĩa gì cả, vì vậy việc đọc mã khó khăn hơn trừ khi bạn nhận xét về rác ở khắp mọi nơi.

Answer 2

Bạn chưa trả lời câu hỏi của riêng mình chưa? :)

Rõ ràng, nếu bạn dự định hỗ trợ i18n ứng dụng của mình, bạn nên xử lý tất cả các triển khai ngôn ngữ giống nhau. Nếu ai đó quyết định một chuỗi cần thay đổi, bạn thực hiện thay đổi tương tự trong tất cả các tệp ngôn ngữ. Siêu dữ liệu có đăng ký phải nhóm tất cả các tệp ngôn ngữ lại với nhau trong cùng một thay đổi. Nếu ngôn ngữ "mặc định" của bạn được xử lý khác nhau, điều đó khiến việc duy trì khó khăn hơn.

Answer 3

Lý do cho ID là tiếng Anh để ID được trả về nếu bản dịch không thành công vì bất kỳ lý do gì - bản dịch cho ngôn ngữ hiện tại và mã thông báo không khả dụng hoặc các lỗi khác. Điều đó tất nhiên giả định rằng nhà phát triển đang viết văn bản tiếng Anh gốc, chứ không phải một số tài liệu.

Ngoài ra nếu văn bản tiếng Anh thay đổi thì có lẽ các bản dịch khác cần được cập nhật?

Trong thực tế, chúng tôi cũng sử dụng ID thuần túy thay vì văn bản tiếng Anh, nhưng điều đó có nghĩa là chúng tôi phải thực hiện nhiều công việc bổ sung để mặc định thành tiếng Anh.

Answer 4

Tôi muốn đi xa như vậy để nói rằng bạn không bao giờ (đối với hầu hết các giá trị của không bao giờ) muốn sử dụng văn bản miễn phí làm chìa khóa cho bất cứ điều gì. Hãy tưởng tượng nếu SO sử dụng tiêu đề truy vấn như là chìa khóa cho trang này chẳng hạn. Nếu ai đó liên kết với nó, và sau đó tiêu đề được chỉnh sửa, liên kết không còn hợp lệ nữa.

Vấn đề của bạn là tương tự, ngoại trừ bạn cũng sẽ chịu trách nhiệm cho việc cập nhật tất cả các liên kết ...

Giống như Douglas Leeder đề cập, những gì bạn có thể muốn làm là sử dụng tiếng Anh như là ngôn ngữ mặc định (sao lưu), mặc dù một giao diện sử dụng tiếng Anh và một ngôn ngữ khác xen kẽ rất khó hiểu (nhưng cũng khá thú vị).

Answer 5

Tôi thật sự không đồng ý với câu trả lời của Richard Harrisons về câu trả lời của anh ấy là "cách duy nhất". Kính gửi người hỏi, đừng tin tưởng một câu trả lời cho biết đó là cách duy nhất, bởi vì "cách duy nhất" không tồn tại.

Dưới đây là một cách mà IMHO có một vài ưu điểm so với phương pháp Richards:

• Bắt đầu với việc sử dụng proto-phiên bản của chuỗi tiếng Anh như ban đầu.
• Không hiển thị những proto-strings nhưng tạo ra một tập tin bản dịch tiếng Anh Nontheless
• Sao chép proto-strings bản dịch cho đầu

Ưu điểm:

• đọc đang
• văn bản trong mã của bạn rất gần nếu không giống với chế độ xem của bạn hiển thị
• nếu bạn muốn thay đổi văn bản tiếng Anh, bạn không phải là chan ge chuỗi proto nhưng bản dịch
• nếu bạn muốn dịch cùng một thứ hai lần, chỉ cần viết một chuỗi proto hơi khác hoặc chỉ cần thêm 'phiên bản này và cái đó' và bạn vẫn có mã hoàn toàn có thể đọc được

Answer 6

Wow, tôi rất ngạc nhiên khi không ai ủng hộ việc sử dụng tiếng Anh làm chìa khóa. Tôi đã sử dụng phong cách này trong một vài dự án phần mềm, và IMHO nó hoạt động khá tốt. Khả năng đọc mã là rất tốt, và nếu bạn thay đổi một chuỗi tiếng Anh, nó trở nên rõ ràng rằng thông điệp cần phải được xem xét để tái dịch (đó là một điều tốt).

Trong trường hợp bạn chỉ sửa lỗi chính tả hoặc thực hiện một số thay đổi khác chắc chắn không yêu cầu dịch, việc cập nhật ID cho chuỗi đó trong tệp tài nguyên là một vấn đề đơn giản.

Điều đó nói rằng, tôi hiện đang đánh giá xem có nên thực hiện theo cách này để chuyển I18N sang một dự án mới hay không, vì vậy rất tốt khi nghe một số suy nghĩ về lý do tại sao nó không phải là một ý tưởng hay.

Answer 7

Trong một từ không làm điều này.

Cùng một từ/cụm từ trong tiếng Anh thường có thể có nhiều ý nghĩa và mỗi nghĩa là một bản dịch khác.

Xác định id ghi nhớ cho chuỗi của bạn và xử lý tiếng Anh như một ngôn ngữ khác.

Đồng ý với các áp phích khác có số id trong mã là một cơn ác mộng về khả năng đọc mã.

Ex kỹ sư địa hóa

Answer 8

Ngoài việc cân nhắc ở trên, có rất nhiều trường hợp bạn muốn "chìa khóa" (msgid) để thể khác với văn bản gốc (bằng tiếng Anh). Ví dụ: trong chế độ xem HTML, tôi có thể muốn nói [yyyy] nơi đích và nhãn của thẻ liên kết đó phụ thuộc vào ngôn ngữ của người dùng. Ví dụ. nó có thể là một liên kết đến một mạng xã hội, và ở Mỹ nó sẽ là Facebook nhưng ở Trung Quốc nó sẽ là Weibo. Vì vậy, các MsgIds có thể là một cái gì đó như socialSiteUrl và socialSiteLabel.

Tôi sử dụng kết hợp.

Đối với các chuỗi cơ bản mà tôi không nghĩ sẽ có xung đột/thay đổi/ý nghĩa lạ, tôi sẽ tạo khóa giống như tiếng Anh.

Answer 9

Vào cuối ngày, người dịch sẽ có thể ngồi xuống và thay đổi văn bản cho mọi ngôn ngữ (để chúng phù hợp với ý nghĩa) mà không cần phải liên quan đến lập trình viên đã thực hiện công việc của mình.

Điều này làm cho tôi cảm thấy như là câu trả lời thích hợp là sử dụng một phiên bản sửa đổi của gettext nơi bạn đặt chuỗi như

_(id, backup_text, context) 

_('ABOUT_ME', 'About Me', 'HOMEPAGE') 

bối cảnh này là không bắt buộc

tại sao như thế này? vì bạn cần phải xác định văn bản trong hệ thống bằng cách sử dụng ID duy nhất không phải là văn bản tiếng Anh có thể được lặp lại ở nơi khác.

Bạn cũng nên giữ bản sao lưu, id và ngữ cảnh trong cùng một vị trí trong mã của mình để giảm chênh lệch.

của id cũng phải có thể đọc được, trong đó mang lại vấn đề từ đồng nghĩa và lặp lại sử dụng (thậm chí như id), chúng ta có thể thêm tiền tố id như thế này "HOMEPAGE_ABOUT_ME" hoặc "MAIL_LETTER", nhưng

1. người quên để làm điều này ngay từ đầu và thay đổi nó sau này là một vấn đề
2. của nó linh hoạt hơn cho hệ thống để có thể nhóm cả bởi id và bối cảnh

đó là lý do tôi cũng nói thêm biến bối cảnh tại kết thúc

văn bản sao lưu có thể được khá nhiều bất cứ điều gì, thậm chí có thể "[ABOUT_ME @ văn bản HOMEPAGE không tải, xin vui lòng liên hệ với example@example.com]"

Nó sẽ không làm việc với các chương trình chỉnh sửa gettext hiện như "poedit", nhưng tôi nghĩ bạn có thể xác định tên biến tùy chỉnh cho các bản dịch như chỉ "t()" mà không có dấu gạch dưới lúc bắt đầu.

Tôi biết rằng gettext cũng có hỗ trợ cho các ngữ cảnh, nhưng nó không được tài liệu hóa hay sử dụng rộng rãi.

P.S. Tôi không chắc chắn về thứ tự biến tốt nhất để thực thi mã tốt và có thể mở rộng để các đề xuất được hoan nghênh.

Answer 10

Có rất nhiều điều cần xem xét và trả lời không dễ dàng như vậy.

Sử dụng đồng bằng tiếng Anh

Ưu

• dễ dàng để viết và đọc mã
• Trong hầu hết các trường hợp, nó hoạt động ngay cả khi không chạy chức năng dịch trong mã

Nhược điểm

• lập trình viên liên quan phải được copywriter cũng tốt :)
• Bạn cần phải viết văn bản chính xác đúng hoàn toàn bằng tiếng Anh, ngay cả trong trường hợp đó ngôn ngữ đầu tiên bạn cần phải chạy là cái gì khác (tức là chúng ta đang bắt đầu lof của dự án bằng tiếng Séc và chúng tôi đang bản địa hóa chúng thành EN sau này).
• Trong nhiều trường hợp, bạn cần phải sử dụng ngữ cảnh. Nếu bạn không làm điều đó từ begginig, có rất nhiều công việc để thêm chúng sau này. Để giải thích: Trong tiếng Anh, một từ có thể có nhiều khúc cua khác nhau - và bạn cần sử dụng ngữ cảnh để phân biệt chúng - và không phải lúc nào cũng dễ dàng như vậy (thứ tự = thứ tự sắp xếp, hoặc nó có thể là đơn đặt hàng).
• Có thể rất khó để sửa lỗi tiếng Anh sau trong quá trình này. Việc sửa đổi các chuỗi nguồn sẽ thường dẫn đến mất các cụm từ đã dịch. Sẽ rất bực bội khi dịch sang 3 ngôn ngữ khác nhau chỉ vì bạn đã chỉnh sửa tiếng Anh.

Sử dụng phím

Ưu

• Bạn có thể sử dụng chức năng nền tảng nội địa hóa ngay cả đối với ngôn ngữ tiếng Anh. I E. chúng tôi đang sử dụng nền tảng Crowdin đáng yêu. Có rất nhiều công cụ hữu ích - hay đúng hơn là một quy trình hoàn chỉnh - để quản lý bản dịch: bỏ phiếu cho các bản dịch khác nhau, lịch sử dịch thuật, bảng thuật ngữ (giúp giữ bản dịch/ngôn ngữ mạch lạc), kiểm chứng, phê duyệt, vv. mượt hơn.

• Nó dễ dàng hơn để gửi văn bản Engish cho proofreading vv Thông thường, nó không phải là một ý tưởng tốt để cho copywriter sửa đổi mã của bạn trực tiếp :)

Nhược điểm

• More thiết lập dự án phức tạp.
• Khó sử dụng% d,% s, v.v.