DeepL vs Google Translate vs AI: Tốt nhất cho các tệp .po?

Bạn xuất một tệp .pot từ plugin WordPress của mình, dán vài trăm chuỗi vào DeepL hoặc Google Translate, nhận lại một cột tiếng Đức gọn gàng, đưa nó vào tệp .po của bạn, biên dịch và triển khai. Sau đó, một người dùng báo cáo rằng trang giỏ hàng hiển thị %1$s thô nơi lẽ ra phải có tên sản phẩm, hoặc tệ hơn, dòng giá hiển thị You have 1 items trong mọi ngôn ngữ vì dạng số nhiều đã bị hỏng. Chất lượng bản dịch thì ổn. Cấu trúc bản dịch đã bị phá hủy.

Đó là điểm căng thẳng cốt lõi trong cuộc tranh luận DeepL vs Google Translate khi nguồn là tệp .po gettext chứ không phải một đoạn văn xuôi. Cả hai đều là công cụ đẳng cấp thế giới trong việc dịch các câu tự nhiên. Không công cụ nào được thiết kế để tôn trọng biến giữ chỗ printf, một mảng số nhiều Gettext hoặc sự phân biệt msgctxt. Chúng coi %1$s là lỗi đánh máy cần sửa và một dạng số nhiều hai hình thức như một câu đơn để làm phẳng. Đối với nội dung tiếp thị, điều đó không đáng chú ý. Đối với bản địa hóa phần mềm, nó phá vỡ các trang web.

Bài đăng này so sánh bản dịch máy cổ điển - DeepL và Google Translate - với một quy trình AI nhận biết ngữ cảnh được xây dựng đặc biệt cho gettext. Chúng ta sẽ xem xét các khía cạnh thực sự quan trọng đối với các tệp .po: xử lý biến giữ chỗ, các dạng số nhiều, ngữ cảnh, hỗ trợ tệp hàng loạt và chi phí. Nếu bạn muốn thảo luận sâu hơn về chất lượng LLM so với LLM, chúng tôi đã đề cập đến điều đó trong Chất lượng dịch thuật AI: Gemini vs GPT-4 vs DeepSeek. Ở đây, câu hỏi hẹp hơn và thực tế hơn: công cụ nào tốt nhất cho các tệp .po?

DeepL vs Google Translate: Chúng được xây dựng cho mục đích gì

Cả hai đều là công cụ dịch máy đa năng được tối ưu hóa cho đầu ra ngôn ngữ tự nhiên, trôi chảy. Cả hai đều không phân tích cú pháp định dạng tệp.

DeepL - Trôi chảy, nhưng không nhận biết định dạng

DeepL được ca ngợi rộng rãi vì có đầu ra nghe tự nhiên nhất, đặc biệt là đối với các ngôn ngữ châu Âu. Nhưng nó tiếp nhận văn bản, không phải cấu trúc. Hãy đưa cho nó một msgid .po chứa %1$s ordered %2$s và nó sẽ dịch các từ xung quanh các biến giữ chỗ trong khi thường xuyên sắp xếp lại, thêm khoảng trắng hoặc bỏ các token - bởi vì đối với DeepL, chúng chỉ là những ký tự lạ trong một câu.

Google Translate - Phạm vi phủ sóng rộng, cùng một điểm mù

Google Translate hỗ trợ nhiều ngôn ngữ hơn và là lựa chọn mặc định với ngân sách hạn chế đằng sau các plugin như GTranslate. Khả năng xử lý biến giữ chỗ của nó cũng không tốt hơn. Cả hai công cụ đều có cùng một hạn chế cơ bản: chúng tối ưu hóa sự trôi chảy của câu và không có mô hình nào về các quy tắc gettext.

Câu hỏi thực sự không phải là Chất lượng - Mà là Cấu trúc

Đối với các tệp .po, chất lượng ngôn ngữ thô là điều kiện tiên quyết. Điều phá vỡ quá trình sản xuất là tính toàn vẹn cấu trúc: liệu các biến có được giữ nguyên, liệu số nhiều có giữ được nhiều hình thức, liệu ngữ cảnh có được tôn trọng hay không. Đó là lúc một quy trình AI nhận biết gettext vượt trội hơn cả DeepL và Google Translate.

Tại sao các biến giữ chỗ và số nhiều làm hỏng bản dịch máy

Tệp .po không phải là văn xuôi. Nó là văn bản gần mã với các quy tắc nghiêm ngặt, và ba trong số các quy tắc đó thường xuyên đánh bại bản dịch máy cổ điển.

Làm biến dạng biến giữ chỗ và biến

Các chuỗi WordPress chứa đầy các biến giữ chỗ kiểu printf: %s, %d và các dạng vị trí như %1$s và %2$s. Các biến vị trí rất quan trọng vì một số ngôn ngữ sắp xếp lại câu và các số cho sprintf biết đối số nào đi đâu. Hãy xem bản dịch máy cổ điển làm gì với điều này:

// Source string in your .po file
$msg = sprintf( __( '%1$s left a comment on %2$s', 'mytheme' ), $user, $post );

// What DeepL / Google Translate often return (German):
// "%2$s hat einen Kommentar zu %1$s hinterlassen"  <- reordered, OK
// "% 1$ s hat einen Kommentar..."                   <- spaces injected, BROKEN
// "hat einen Kommentar hinterlassen"                <- placeholders dropped, BROKEN

Một khoảng trắng được chèn (% 1$ s) hoặc một token bị bỏ sót sẽ gây ra cảnh báo PHP hoặc in mã thô cho người dùng của bạn. Chúng tôi đi sâu vào chế độ lỗi này trong cách dịch tệp PO mà không làm hỏng các biến mã.

Các dạng số nhiều bị thu gọn

Số nhiều Gettext không phải là một chuỗi - chúng là một mảng được khóa bởi quy tắc số nhiều của ngôn ngữ. Tiếng Anh có hai hình thức; tiếng Ba Lan có ba; tiếng Ả Rập có sáu. Bản dịch máy cổ điển nhận msgid_plural dưới dạng hai câu riêng biệt và dịch chúng độc lập, không hề biết rằng chúng phải duy trì một tập hợp nhiều hình thức mạch lạc. Kết quả thường là một hình thức duy nhất bị trùng lặp, vì vậy 1 item và 5 items hiển thị giống hệt nhau.

msgid "%d item in your cart"
msgid_plural "%d items in your cart"
msgstr[0] ""
msgstr[1] ""
# A gettext-aware pipeline fills BOTH forms correctly with %d preserved.
# DeepL/Google translate each line in isolation and lose the plural relationship.

Ngữ cảnh (msgctxt) bị bỏ qua

Gettext sử dụng msgctxt để phân biệt các chuỗi giống hệt nhau - danh từ "Post" với động từ "Post", hoặc "Order" dưới dạng danh từ với động từ trong WooCommerce. Bản dịch máy cổ điển không bao giờ nhìn thấy trường ngữ cảnh đó, vì vậy nó đoán, và nó đoán theo cùng một cách mỗi khi chuỗi xuất hiện, bất kể vị trí nào.

Thiệt hại tích tụ trong thương mại. Danh mục WooCommerce đầy rẫy các chuỗi ngắn, mơ hồ - "Order", "Ship", "Free", "View" - nơi việc đọc sai sẽ tạo ra một nút có nội dung sai trong ngôn ngữ của khách hàng. Bởi vì DeepL và Google Translate dịch từng chuỗi một cách riêng biệt, chúng không thể sử dụng ngữ cảnh xung quanh mà gettext cố ý mã hóa. Một quy trình nhận biết định dạng đọc msgctxt giải quyết chính xác những sự mơ hồ này, đó là lý do tại sao nó quan trọng nhất trên các trang cửa hàng nơi bản dịch sai gây thiệt hại doanh số thực tế.

Phương pháp AI nhận biết ngữ cảnh cho các tệp .po

Một quy trình gettext được xây dựng có mục đích không chỉ dịch các từ - nó hiểu định dạng tệp và bảo vệ cấu trúc của nó. Đây là sự khác biệt cấp độ danh mục, và đó là lý do tại sao sự so sánh đúng không phải là DeepL vs Google Translate, mà là bản dịch máy cổ điển so với quy trình làm việc AI nhận biết định dạng.

Khóa cú pháp bảo vệ mọi Token

Kỹ thuật quyết định là Khóa cú pháp. Trước khi bất kỳ văn bản nào đến AI, mọi biến (%s, %1$s, {name}), thẻ HTML và token mã đều được khóa và giữ riêng. Mô hình chỉ xem và viết lại các từ có thể đọc được của con người. Sau khi dịch, các token đã khóa được khôi phục về vị trí chính xác của chúng. Việc làm biến dạng % 1$ s đơn giản là không thể xảy ra, bởi vì AI không bao giờ chạm vào biến giữ chỗ ngay từ đầu. Đây là mạng lưới an toàn mà bản dịch máy cổ điển thiếu về mặt cấu trúc - một điểm chúng tôi mở rộng trong dịch thủ công vs AI: AI có an toàn cho bản địa hóa WordPress không.

Hỗ trợ đầy đủ số nhiều và ngữ cảnh

Một quy trình nhận biết gettext đọc msgid_plural như một tập hợp và tạo ra mọi hình thức cần thiết theo quy tắc số nhiều của ngôn ngữ đích, giữ nguyên các biến giữ chỗ trong tất cả chúng. Nó cũng đọc msgctxt và sử dụng nó làm ngữ cảnh, để danh từ "Order" và động từ "Order" được dịch khác nhau và chính xác.

Tệp hàng loạt, Không phải Sao chép-Dán

DeepL và Google Translate là các công cụ dán hộp (hoặc API theo ký tự). Một quy trình .po trên đám mây tiếp nhận toàn bộ tệp - và với Smart Batching, các gói chuỗi WooCommerce 10MB+ được chia nhỏ, dịch song song và hợp nhất, trong khi phương pháp sao chép-dán sẽ bị hỏng rất lâu trước đó. Bạn tải lên một tệp và tải xuống .po + .mo + nhiều định dạng khác, thay vì ghép các cột bằng tay.

DeepL vs Google Translate vs AI nhận biết Gettext: Phán quyết

Đối với văn xuôi đơn thuần, DeepL và Google Translate rất xuất sắc. Đối với các tệp .po, các yếu tố quyết định sự an toàn sản xuất là biến giữ chỗ, số nhiều, ngữ cảnh và xử lý hàng loạt - và đó là nơi một quy trình nhận biết định dạng chiến thắng.

Bảng so sánh

Cách lựa chọn

Nếu bạn đang dịch một bài đăng blog hoặc trang tiếp thị, hãy chọn DeepL để có giọng văn tốt. Nếu bạn đang dịch một tệp .po hoặc .pot dành cho một trang WordPress đang hoạt động, độ trôi chảy không phải là yếu tố quyết định - mà là tính toàn vẹn cấu trúc. Một quy trình AI nhận biết gettext mang lại cho bạn cả hai: chất lượng ngôn ngữ mạnh mẽ và các biến giữ chỗ, số nhiều và ngữ cảnh vẫn còn nguyên vẹn cho đến khi biên dịch thành tệp .mo.

Cũng có một chi phí quy trình làm việc mà bảng trên đã đánh giá thấp. Chạy toàn bộ một plugin thông qua DeepL hoặc Google Translate có nghĩa là sao chép các cột chuỗi vào một ô, dán kết quả trở lại và kiểm tra lại thủ công từng biến giữ chỗ - một quy trình tẻ nhạt, dễ mắc lỗi và trở nên tồi tệ hơn với mỗi ngôn ngữ bổ sung. Một quy trình dựa trên tệp sẽ rút gọn điều đó thành một lần tải lên và tải xuống duy nhất, đồng thời trả về không chỉ .po mà còn cả .mo đã biên dịch và các định dạng khác trong một tệp ZIP, vì vậy tệp bạn triển khai là tệp mà AI đã tạo ra - không cần lắp ráp lại thủ công nơi có thể phát sinh lỗi mới.

Kết luận

Câu trả lời chân thật cho câu hỏi DeepL vs Google Translate đối với các tệp .po là bạn đang hỏi về những đối thủ sai. Cả hai đều là công cụ dịch văn xuôi tuyệt vời và cả hai đều mù về cấu trúc gettext - chúng làm biến dạng %1$s, làm phẳng số nhiều và bỏ qua msgctxt, bởi vì chúng chưa bao giờ được xây dựng để đọc một tệp dịch. Đối với bản địa hóa phần mềm, đó là sự khác biệt giữa một bản phát hành sạch sẽ và một trang giỏ hàng bị hỏng.

Một quy trình AI nhận biết ngữ cảnh với Khóa cú pháp thay đổi hoàn toàn sự so sánh. Nó đạt được sự trôi chảy mà bạn mong đợi từ DeepL hoặc Google Translate đồng thời đảm bảo rằng mọi biến, dạng số nhiều và ghi chú ngữ cảnh đều còn nguyên vẹn - để trang web được dịch của bạn hoạt động, chứ không chỉ đọc tốt.

Sẵn sàng dịch các tệp .po mà không làm biến dạng biến giữ chỗ hoặc làm hỏng số nhiều? Dùng thử SimplePoTranslate miễn phí - không yêu cầu thẻ tín dụng. Tải lên tệp .po, .pot, .json, hoặc .xliff của bạn và nhận bản dịch AI an toàn gettext trên gói miễn phí.