Làm cách nào để tạo chuỗi từ các mẫu có thể dịch trên tất cả các trang chúng xuất hiện?

Tôi có một số cuộc gọi đến t()trong tệp * .tpl.php. Ví dụ, giả sử tôi đang nói về sản phẩm và tệp sản phẩm.tpl.php.

Các chuỗi trong các mẫu không được nhận ra cho đến khi chúng thực sự được sử dụng. Có một chủ đề trên Drupal.org về điều đó và tôi thấy nó là chính xác. Đáng buồn thay, nếu tôi đi đến, giả sử, http://example.com/pl/product/200 , thì chuỗi đó sẽ được lưu trong {locales_source}bảng với locationtrường được đặt thành /pl/product/200.

Tôi cần người dùng của mình có thể dịch bằng công cụ dịch tại chỗ của mô đun máy khách , để họ thực sự có thể thấy những gì họ đang dịch, có nó trong ngữ cảnh phù hợp. Với vị trí nguồn được đặt thành /pl/product/200, sản phẩm có ID 200 là sản phẩm duy nhất mà chuỗi được hiển thị được dịch. Và tệ hơn nữa, nếu tôi có thể buộc người dùng dịch trên sản phẩm cụ thể đó, tôi cũng cần họ để có thể dịch sang tiếng Nga và không có sản phẩm nào được đặt ở vị trí /ru/product/PID.

Có cách nào để định dạng lại chuỗi vị trí trong cơ sở dữ liệu, để hiển thị tất cả các chuỗi trên tất cả các sản phẩm, tất cả các ngôn ngữ trong công cụ l10n_client không?

Tôi đã thử đặt nó thành:

• ; sites/default/themes/mytheme/product.tpl.php,
• sites/default/themes/mytheme/product.tpl.php,
• sites/default/modules/mymodule/mymodule.module (mô-đun tạo dữ liệu theo chủ đề)

Nhưng nó chỉ làm cho chúng vô hình cho công cụ dịch thuật.

Tôi khá chắc chắn rằng đó không phải là một lỗi trong Máy khách bản địa hóa , nó hiển thị chuỗi nơi nó đã nói chuỗi này xảy ra. Và có vẻ như "nó cũng hoạt động" cho hệ thống dịch thuật Drupal 7 - cũng đã được thảo luận và báo cáo, và không có gì thay đổi. Vì vậy, đây không phải là một báo cáo lỗi, tôi chỉ hỏi làm thế nào với những gì chúng ta phải làm việc với.

Tôi đang nói về các văn bản không liên quan gì đến mô-đun dữ liệu hoạt động. Tôi không muốn dịch các sản phẩm, chỉ là các chuỗi mẫu không liên quan gì đến chính sản phẩm, như Trước - Tiếp theo trên mẫu thư viện ảnh sản phẩm.

Ví dụ: mô-đun trả về 15 hình thu nhỏ và công việc của chủ đề là hiển thị 5 lần. Và các liên kết trước / tiếp theo cần altvà titlethuộc tính. Đã dịch. Nhưng mô-đun của tôi không biết điều đó. Và không bao giờ nên cần.

Yêu cầu của bạn:
Để trang web của tôi hoạt động với nhiều ngôn ngữ
như một người dùng được xác thực,
tôi cần có thể dịch ngay lập tức bất kỳ và tất cả các cuộc gọi dịch được tìm thấy trong cơ sở mã của trang web của tôi đã được thực hiện với chức năng t ().

Là mô tả yêu cầu thậm chí gần với những gì bạn yêu cầu?

Trình thu thập thông tin

Giống như ai đó đã nói - về mặt lý thuyết, một trình thu thập thông tin có thể đi qua toàn bộ trang web để buộc đăng ký tất cả các cuộc gọi t (). Nhưng 1) trình thu thập thông tin không biết trang nào sẽ thu thập dữ liệu; 2) do đó chúng tôi không tìm cách duy trì danh sách các trang để thu thập thông tin; 3) chúng tôi không muốn sử dụng trình thu thập thông tin. Ồ Chỉ là, eww. Đúng?

Vấn đề

1. Chúng tôi không có một danh sách tất cả các chuỗi dịch.
2. Drupal / PHP là một ngôn ngữ động không giống như C được biên dịch. Vì vậy, chúng ta không thể đi và nói ví dụ: biên dịch toàn bộ cơ sở mã này, sau đó tìm cho tôi tất cả các phiên bản của hàm này t(), sau đó đăng ký các phiên bản đó trong cơ sở dữ liệu, sau đó dịch tất cả các phiên bản đã đăng ký t()trong một lần. Tôi không nghĩ là một lựa chọn chúng ta có trên bàn của chúng tôi.
3. Một công cụ phân tích mã tĩnh sẽ bất lực vì lý do tương tự trình thu thập thông tin sẽ bất lực. Tôi tìm thấy điều này t()trong tập tin này. Tuyệt quá! URL nào được sử dụng trong? Bối cảnh là gì?

Tấn công vấn đề với các công cụ hiện tại (Drupal và một số mô-đun đóng góp) và với các ràng buộc hiện tại (dựa trên các cuộc gọi chủ đề thời gian thực -> tệp mẫu -> t()cuộc gọi), trông giống như một con hẻm không lối thoát ở đây. Chúng ta có thể cần phải suy nghĩ một chút ra khỏi hộp.

Những gì chúng tôi cần

1. Chúng tôi cần một nguồn dữ liệu, một mô hình, cho tôi biết chúng tôi có chuỗi dịch thuật hiện tại nào và bối cảnh của chúng là gì -
2. Mô hình dữ liệu chủ động. Mô hình dữ liệu hiện tại là phản ứng (mô hình được cập nhật bất cứ khi nào có cuộc gọi t()xảy ra). Chúng ta cần một mô hình dữ liệu chủ động - một mô hình trong đó ứng dụng quan tâm đến việc tìm kiếm các t()thể hiện trước khi chúng thực sự được thực thi bởi khách hàng.
3. Chúng ta cần bối cảnh. t()một mình không cắt nó - bởi vì - chúng tôi không biết chúng tôi đang dịch 'foo', nhưng ngôn ngữ đích chúng tôi đang dịch phụ thuộc vào URL nơi t()xảy ra. Ngay cả khi chúng ta có thể mã hóa ngôn ngữ đích vào t()cuộc gọi, giả sử sử dụng cuộc gọi trình bao bọc, nó sẽ không hoạt động cho mục đích của bạn.

Tôi đã xác định một số công cụ mà - nếu chúng ta có chúng - sẽ giúp ích cho vấn đề của chúng ta. Với các công cụ này, chúng tôi có thể đi vào mô hình dữ liệu và nói: cung cấp cho tôi tất cả các chuỗi được bao bọc trong t()đó chưa được phổ biến. Bây giờ chèn các bản dịch. Cảm ơn bạn.

Và lần tiếp theo khách hàng đến, các bản dịch được đưa ra.

Làm thế nào chúng ta sẽ ... xây dựng những công cụ này?

Những ràng buộc

1. Ngôn ngữ đích không thể có trên mẫu, được quyết định bởi URL. Giả sử chuỗi phải hỗ trợ bất kỳ ngôn ngữ nào.
2. Chuỗi dịch không thể có trên mẫu. Bản dịch sẽ nằm trong cơ sở dữ liệu.

Bây giờ tôi đã đưa ra vấn đề nhiều suy nghĩ hơn và xác định một số thách thức và ràng buộc, tôi có thể suy nghĩ về việc xem xét bất kỳ giải pháp nào có sẵn ngoài đó hoặc thực hiện bất kỳ giải pháp tùy chỉnh nào.

Giải pháp động não

Tôi cần một cái gì đó gắn kết "mọi thứ" với nhau. Thế còn ... một thực thể?

• Một thực thể có thể giữ sản phẩm cần được dịch.
• Các thực thể có thể cung cấp mối quan hệ - chất keo - giữa sản phẩm cần dịch và bối cảnh của nó.
• Thực thể có thể chỉ định nói, trong một trường, vị trí URL mặc định của sản phẩm.
• Mã thông báo có thể được sử dụng để chỉ định vị trí thay thế (ngôn ngữ?) Mà sản phẩm sẽ xuất hiện.
• Các thực thể cung cấp cho chúng ta mô hình dữ liệu chủ động mà chúng ta cần và bối cảnh của nó. Đến lượt nó cho phép chúng ta thực hiện những việc như: đi vào cơ sở dữ liệu, lấy tất cả các thực thể sản phẩm và nếu không có chuỗi dịch cho các trường X, Y và Z, hãy tạo các chuỗi dịch đó.

Khi khách hàng lấy /pl/product/200, bạn thực hiện một chuyến đi đến db, tìm kiếm sản phẩm 200 và lấy sản phẩm đã có sẵnpl bản dịch . Bạn có một tiêu đề và trường chú thích cho sản phẩm đó là tốt? Các bản dịch nên có.

Lưu ý rằng tôi rất mơ hồ và chung chung ở đây về mặt mô-đun dịch thuật bạn đang sử dụng. Bạn rất có thể kết thúc bằng cách sử dụng mô-đun dịch của riêng bạn - rất có thể đây là trường hợp. Tất cả các mô hình dịch thuật mà tôi đã thấy trong Drupal cho đến nay (kể từ D7, chưa nhìn vào D8) đều phản ứng, không chủ động.

Tóm lại

Về lý thuyết, các công cụ để xây dựng những gì bạn cần có, các thực thể là thành phần chính sẽ gắn kết mọi thứ lại với nhau: - dữ liệu (chuỗi dịch), - ngôn ngữ đích. Đừng phải thuộc về Thực thể, tốt nhất là từ vựng phân loại, nói về ngôn ngữ sản phẩm. hoặc có thể là một phân loại chung cho các thực thể khác là tốt. - Bối cảnh. URL mà thực thể xuất hiện trên. URL sẽ chứa mã thông báo và lần lượt mã thông báo sẽ tham chiếu phân loại ngôn ngữ đích.

Với ba thành phần bạn có thể nói: Lấy tất cả các productthực thể, đi đến URL aliastrường, nhận mã thông báo phân loại, chuyển qua tất cả các kết hợp thuật ngữ có thể, trình bày tất cả các kết hợp cho người dùng hiện tại bằng cách sử dụng một hình thức xấu xí rất lớn - hoặc, AJAX - và biểu mẫu nhiều bước (đại loại như vậy) và khi người dùng hiện đang đăng nhập dịch các ngôn ngữ khác nhau cho sản phẩm 200, hãy lưu những ngôn ngữ đó vào cơ sở dữ liệu

Ở đâu đó trong cơ sở dữ liệu có thể là trường API trường trong thực thể, trường cài đặt thuộc về từng thực thể (không chính xác là API trường, nhưng nó vẫn có thể chứa dữ liệu) hoặc một bảng riêng mà bạn sử dụng cho mục này. Tôi nghĩ rằng việc lưu dữ liệu vào Thực thể sẽ giữ cho cả mã và dữ liệu gọn gàng và dễ dàng hơn.

Xây dựng nó: giải pháp có thể

• D8MI (Sáng kiến ​​đa ngôn ngữ Drupal 8)
• Mã tùy chỉnh: bản dịch "lập chỉ mục" được cung cấp trong các mẫu bằng t () bằng cách truy vấn theo chương trình và hiển thị các gói có sẵn và triển khai móc chủ đề liên quan của chúng.

Mã giả

Foreach thực thể (loại x),
Tìm tất cả các ngôn ngữ (phân loại hoặc ngôn ngữ cốt lõi được liên kết với sản phẩm), Kết xuất
thực thể,
- để phát hiện chuỗi dịch thuật của nó
- kết xuất cuộc gọi theme (), xử lý lớp trình bày đa ngôn ngữ của sản phẩm, không phải mô hình dữ liệu sản phẩm.

Kết quả:
- Cuộc gọi đầu tiên để kết xuất mẫu thực thể trong mỗi ngôn ngữ trả về cài đặt ngôn ngữ mặc định cho mỗi cuộc gọi.
- Các tham số t () trên mẫu hiện được lưu trong bộ nhớ cache trong Drupal và sẵn sàng để dịch (cho từng phiên bản ngôn ngữ, không phải cho từng phiên bản sản phẩm).
- Người dùng với vai trò dịch thuật của người dùng hiện có thể chuyển sang giao diện dịch và dịch tất cả các tham số t () có sẵn cho từng ngôn ngữ.
- Chủ sở hữu trang web không cần đợi khách hàng truy cập từng trang sản phẩm hoặc truy cập từng trang sản phẩm theo cách thủ công, vì điều này đã được thực hiện theo chương trình cho anh ta.

Câu hỏi mở:
- Bối cảnh là gì? Nếu tôi thực hiện một cuộc gọi đến chủ đề () theo chương trình cho mỗi gói thực thể của sản phẩm, thì nó có ghi lại vị trí mà cuộc gọi được thực hiện không? Nó có ghi lại URL của nút không? Có thể thay đổi bối cảnh của người Viking không? Bối cảnh được ghi lại ở đâu? Điều gì xảy ra khi bạn có các mẫu "động" - tức là khi bạn có nhiều hơn một mẫu cho mỗi sản phẩm và cách bạn phát hiện các biến thể đó?

Như mọi khi, lý thuyết hóa và mã giả chỉ tốt cho việc động não. Nhưng trong quá trình phát triển, chúng ta hầu như không biết những gì chúng ta thực sự chống lại cho đến khi chúng ta bắt đầu tạo mẫu. Vì vậy, đã đưa ra một vài ràng buộc, giải pháp khả thi và các vấn đề hoặc câu hỏi có thể - bây giờ tôi có thể tiến hành thực hiện một bằng chứng về khái niệm hoặc nguyên mẫu làm việc. Một số câu hỏi mở ở trên chỉ có thể được trả lời theo cách này và là nguyên mẫu sớm nhất của chúng tôi (bất kể thành công hay thất bại), chúng tôi có thể bắt đầu trả lời một số câu hỏi đó - hoặc thay đổi cách tiếp cận hoàn toàn. Hãy theo dõi ~

Ok, Dành thêm một chút thời gian với mô đun dịch thuật thực thể & ứng dụng khách để bản địa hóa cùng một kịch bản. Vì câu trả lời này hoàn toàn khác với câu trả lời trước của tôi, nên thêm vào dưới dạng nhận xét riêng biệt:

1. Bản dịch được thêm cho một ngôn ngữ trong một / nút đầu tiên có sẵn cho tất cả các nút.

   Đây là một ví dụ:

   • Nếu tôi thêm sản phẩm mới cùng loại với nid 200 và truy cập vào bản dịch pl thì nút mới (giả sử pl / sản phẩm / 204), tôi sẽ thấy chuỗi dịch tương tự trong pl / sản phẩm / 200.

   • Chỉ khác là nó không xuất hiện trong Máy khách bản địa hóa. Chúng tôi có thể yêu cầu tính năng này trong hàng đợi vấn đề của mô-đun, tuy nhiên nó sẽ gây ra nhiều nhầm lẫn hơn vì bản dịch không dành riêng cho trang hiện tại và sẽ ảnh hưởng đến tất cả các trang (ví dụ cả pl / sản phẩm / 200 & pl / sản phẩm / 204).

   • Nếu hai nút được tạo bởi hai người khác nhau và người sau muốn thay đổi bản dịch, thì họ phải sử dụng bản dịch giao diện.

2. Chuỗi có sẵn trong máy khách Bản địa hóa cho ngôn ngữ đầu tiên bạn truy cập cho cùng một nút

   Đây là một ví dụ:

   • Nếu tôi thêm sản phẩm mới nid 199 và tạo bản dịch cho ngôn ngữ 'pl' (nid 200) và dịch cho ngôn ngữ 'rs' (nid 201), bạn chỉ có thể thấy chuỗi trên trang 'pl', không phải trên trang 'rs'. Một lần nữa, điều này trông giống như một hạn chế trong mô đun máy khách Bản địa hóa.

Cách tiếp cận của bạn để thêm chuỗi dịch trên cấp độ tệp mẫu hoặc mô-đun có thể hoạt động cho giao diện người dùng dịch giao diện, nhưng không phải máy khách Bản địa hóa.

Rõ ràng khi bạn có phiên bản tiếng Nga của sản phẩm 200, đó sẽ là một nút mới, ví dụ / ru / sản phẩm / 201 nơi bạn có thể dịch bằng ứng dụng Localization client.

Chỉ cần một suy nghĩ: Tìm kiếm một chuỗi có thể được dịch cho tất cả các ngôn ngữ trong giao diện người dùng dịch giao diện và yêu cầu khách hàng dịch cấp độ sản phẩm khi thực sự cần thiết. Đây là một ví dụ:

"Đây là sản phẩm của thanh danh mục"

và nếu chúng tôi chắc chắn rằng khác với 'foo' & 'bar' có thể phổ biến, chúng tôi có thể thêm

$vars['product_title'] = t('This is product @product of category @category')

trong tiền xử lý.

và tệp .tpl.php sẽ là

<?php t($product_title, array('@product' => t('foo'),  '@category' => t('bar')); ?>

AFAIK với trình trích xuất mẫu Dịch, bạn có thể trích xuất chuỗi trong tất cả các lệnh gọi của bạn đến t()hàm.

Trình trích xuất mẫu dịch thuật cung cấp giao diện trình trích xuất mẫu dịch thuật Gettext dựa trên web và dòng lệnh cho Drupal cũng như API có thể sử dụng lại để tìm kiếm các chuỗi có thể dịch và lỗi dịch. Công cụ này được sử dụng dưới mui xe tại http://localize.drupal.org/ cũng như để phục vụ như một máy phân tích cú pháp cho các bản phát hành dự án Drupal.org.

Đọc này Làm thế nào để dịch một mô-đun?