Dịch các mẫu Elementor & Divi mà không làm hỏng bố cục
Bạn đã làm mọi thứ đúng cách. Bạn đã mua một theme cao cấp, tìm thấy tệp .po, dịch nó cẩn thận và tải tệp .mo lên thư mục ngôn ngữ của bạn. Các chuỗi trong phần tiêu đề của theme được cập nhật chính xác. Chân trang hiển thị bằng tiếng Tây Ban Nha. Quy trình thanh toán WooCommerce của bạn đã được bản địa hóa. Nhưng rồi bạn mở trang chủ và mọi tiêu đề, nút, và khối văn bản được xây dựng bằng Elementor vẫn còn bằng tiếng Anh.
Bạn kiểm tra tệp .po. Bạn có thể thấy các chuỗi tiếng Anh trong mã. Bạn dịch lại. Không có gì thay đổi. Bạn xóa bộ nhớ cache. Không có gì thay đổi. Bạn tự nhủ có gì đó bị hỏng cho đến khi một người nào đó trên diễn đàn nhẹ nhàng chỉ ra: Elementor (và Divi, Beaver Builder, cũng như Bricks) không lưu trữ nội dung trong các tệp .po. Chúng chưa bao giờ làm như vậy. Bạn đã và đang cố gắng giải quyết một vấn đề mà không thể giải quyết bằng phương pháp bạn đang sử dụng.
Hướng dẫn này giải thích tại sao nội dung của trình tạo trang về mặt kiến trúc lại khác với nội dung của theme và plugin, hai cách để dịch nó, và cách giữ nguyên cấu trúc widget trong quá trình dịch để các bố cục được thiết kế cẩn thận của bạn không bị phá vỡ.
Tại sao Elementor và Divi không sử dụng tệp .po
Các tệp .po lưu trữ các chuỗi nằm trong mã – các lệnh gọi __( 'Shop', 'mytheme' ) rải rác trong các template PHP. Công cụ xây dựng WP-CLI có thể trích xuất các chuỗi này thành một template .pot, người dịch làm việc trên các tệp .po, và các tệp .mo đã được biên dịch sẽ được tải khi chạy.
Nội dung trình tạo trang thì khác. Khi bạn nhập "Chào mừng đến cửa hàng của chúng tôi" vào một widget tiêu đề của Elementor, văn bản đó không nằm trong bất kỳ tệp PHP nào. Nó được lưu dưới dạng JSON (Elementor) hoặc một khối shortcode (Divi) trong bảng wp_postmeta, được liên kết với bài đăng mà bạn đã đặt nó.
Nội dung trình tạo trang thực sự nằm ở đâu
Elementor lưu trữ cây widget của mỗi trang trong postmeta dưới khóa _elementor_data. Mở bất kỳ bài đăng nào trong cơ sở dữ liệu và bạn sẽ tìm thấy một mảng JSON mô tả mọi phần, cột và widget, với các cài đặt và nội dung nội tuyến:
{
"id": "a1b2c3",
"elType": "widget",
"widgetType": "heading",
"settings": {
"title": "Welcome to our store",
"size": "xl",
"header_size": "h1"
}
}
Divi lưu trữ nội dung trang của nó dưới dạng shortcode được nhúng trong post_content:
[et_pb_section][et_pb_row][et_pb_column type="4_4"]
[et_pb_text]Welcome to our store[/et_pb_text]
[/et_pb_column][/et_pb_row][/et_pb_section]
Bricks, Beaver Builder và Oxygen tuân theo cùng một mẫu với định dạng riêng của chúng. Không có nội dung nào trong số này từng được các tệp .po / .mo chạm tới.
Những gì thực sự nằm trong tệp .po
Bản thân plugin trình tạo trang có các chuỗi UI – nhãn nút trong trình chỉnh sửa, thông báo lỗi, thông báo quản trị. Chúng nằm trong các tệp .po và được dịch bởi các tệp .mo của bạn trong wp-content/languages/plugins/. Đây thường là lý do tại sao mọi người bối rối: họ dịch các chuỗi "Elementor" và thấy giao diện người dùng của trình chỉnh sửa bằng tiếng Tây Ban Nha, nhưng nội dung thực tế họ xây dựng bằng các widget đó vẫn bằng tiếng Anh.
Sự khác biệt này cũng là nguyên nhân gốc rễ của một nửa số yêu cầu hỗ trợ trong hướng dẫn khắc phục sự cố bản dịch không hiển thị của chúng tôi – người đọc mong đợi các tệp .mo ảnh hưởng đến nội dung họ thấy ở giao diện người dùng, nhưng nội dung đó nằm trong cơ sở dữ liệu, chứ không phải trong mã.
Những gì tệp .po thực sự bao gồm trên một trang web dùng Page Builder
Hãy để tôi vạch ra ranh giới rõ ràng giữa hai loại để bạn biết chính xác từng loại tệp xử lý cái gì.
Tệp .po / .mo dịch
- Các chuỗi template của theme:
get_template_part, văn bản được mã hóa cứng trongheader.php,footer.php,functions.php. - Các chuỗi UI của plugin: thanh toán WooCommerce, nhãn quản trị Yoast, nhãn trường Contact Form 7.
- Giao diện người dùng plugin trình tạo trang: nút chỉnh sửa Elementor, thông báo xác nhận lưu Divi.
- Các chuỗi động mà plugin hiển thị ra giao diện người dùng: WooCommerce "Thêm vào giỏ hàng", "Hết hàng", tổng giỏ hàng.
Tệp .po / .mo KHÔNG dịch
- Văn bản tiêu đề, đoạn văn, nút được nhập vào các widget Elementor.
- Chú thích hình ảnh, hiệu ứng di chuột, tiêu đề accordion bên trong các module Divi.
- Nội dung trong các template có thể tái sử dụng, các phần toàn cầu, các khối đã lưu.
- Nhãn CSS tùy chỉnh hoặc script nội tuyến bên trong các widget của builder.
Đây là lý do tại sao tài liệu của các tác giả theme về dịch thuật đúng về mặt kỹ thuật nhưng thường vô dụng đối với người dùng cuối. Hướng dẫn của chúng tôi về cách bản địa hóa bất kỳ theme WordPress nào bao gồm khía cạnh theme một cách kỹ lưỡng – bài đăng này tiếp tục từ điểm kết thúc của bài đó.
Hai cách để bản địa hóa Page Builder
Có chính xác hai cách để dịch nội dung trình tạo trang và cả hai đều có những đánh đổi thực sự.
Cách Một: Nhân bản trang theo từng ngôn ngữ
Sử dụng một plugin đa ngôn ngữ như WPML, Polylang, hoặc TranslatePress. Nó tạo một bản sao của mỗi trang cho mỗi ngôn ngữ. Trong Elementor, bạn nhân bản toàn bộ bố cục và thay đổi văn bản trên mỗi bản sao. Trong Divi, bạn sao chép khối shortcode và dịch văn bản giữa các thẻ.
Ưu điểm: Mỗi ngôn ngữ có thể có bố cục được thiết kế độc lập (hữu ích khi văn bản dịch dài hơn và làm hỏng thiết kế gốc của bạn). Tương thích hoàn toàn với trình chỉnh sửa trực quan của trình tạo trang.
Nhược điểm: Mở rộng tuyến tính – 5 ngôn ngữ có nghĩa là công việc bố cục tăng gấp 5 lần. Bất kỳ thay đổi thiết kế nào cũng phải được áp dụng 5 lần. Cơ sở dữ liệu phát triển nhanh. Việc lưu vào bộ nhớ cache trở nên khó khăn hơn.
Cách Hai: Lớp dịch chuỗi
Một số plugin (Polylang Pro, module String Translation của WPML, TranslatePress) có thể hiển thị các chuỗi riêng lẻ bên trong các widget của trình tạo trang để dịch, sau đó hoán đổi chúng tại thời điểm hiển thị. Bạn duy trì một bố cục và plugin dịch các chuỗi tại chỗ.
Ưu điểm: Một nguồn duy nhất cho bố cục. Các thay đổi thiết kế áp dụng ở mọi nơi.
Nhược điểm: Linh hoạt thấp hơn khi văn bản dịch thay đổi độ dài đáng kể. Một số widget (những widget phức tạp với nội dung lồng nhau, danh sách động, biểu mẫu) không hiển thị chuỗi một cách rõ ràng. Chi phí hiệu suất cho mỗi lần hiển thị.
So sánh Polylang vs WPML vs TranslatePress của chúng tôi bao gồm chi tiết hơn các ưu nhược điểm của từng plugin.
Giữ an toàn cho cấu trúc Widget trong quá trình dịch
Dù bạn chọn cách nào, nội dung đã dịch phải giữ nguyên cấu trúc của builder. Nếu người dịch của bạn loại bỏ một shortcode Elementor, thay thế một thuộc tính dữ liệu, hoặc sắp xếp lại các thẻ lồng nhau, widget sẽ hiển thị bị lỗi.
Các vùng nguy hiểm của Elementor
Các widget Elementor nhúng shortcode và thẻ động bên trong cài đặt văn bản. Trường tiêu đề của một widget tiêu đề có thể chứa:
Welcome to <strong>our</strong> [user_name] store
[user_name] đó là một thẻ động – Elementor thay thế nó bằng tên người dùng đã đăng nhập khi hiển thị. Nếu bản dịch làm hỏng nó, bạn sẽ thấy "[user_name]" theo nghĩa đen được hiển thị cho người dùng.
Các biểu tượng bên trong nút sử dụng các thuộc tính class không được dịch. Văn bản thay thế của hình ảnh được lưu trữ riêng biệt với URL hình ảnh. Bố cục cột sử dụng các cài đặt cụ thể theo điểm ngắt (title_mobile, title_tablet) cần được xử lý riêng.
Lồng shortcode của Divi
Các shortcode của Divi lồng vào nhau rất sâu: [et_pb_section][et_pb_row][et_pb_column][et_pb_text]. Một người dịch coi khối đó là văn bản thuần túy sẽ mã hóa dấu ngoặc vuông, dịch các giá trị thuộc tính hoặc làm mất các thẻ đóng. Bất kỳ điều nào trong số này đều làm hỏng module và Divi sẽ từ chối hiển thị nó.
Mẫu an toàn
Đối với bất kỳ builder nào, bản dịch phải:
- Phân tích cú pháp định dạng widget (JSON cho Elementor, AST shortcode cho Divi).
- Duyệt cây để xác định chỉ các trường văn bản hiển thị cho người dùng.
- Khóa các shortcode, thẻ động, thuộc tính HTML và CSS nội tuyến.
- Chỉ gửi các bề mặt văn bản đến người dịch cùng với ngữ cảnh.
- Chèn lại văn bản đã dịch vào cấu trúc gốc.
Đây là nguyên tắc tương tự mà công cụ của chúng tôi áp dụng cho các tệp .po. Hướng dẫn dịch các tệp .po mà không làm hỏng các biến mã trình bày chi tiết các mẫu %s và placeholder – tương đương với shortcode và thẻ động trong trình tạo trang.
Quy trình làm việc kết hợp thực sự hiệu quả
Đối với hầu hết các nhóm, giải pháp thực tế là kết hợp cả hai phương pháp.
Bước 1: Dịch giao diện người dùng Theme và Plugin qua tệp .po
Xuất các tệp .pot từ theme và các plugin chính của bạn (WooCommerce, Yoast, giao diện người dùng trình tạo trang). Dịch chúng một lần thông qua một dịch giả đám mây tôn trọng định dạng .po. Đặt các tệp .mo đã biên dịch vào wp-content/languages/. Điều này xử lý 80% các chuỗi giao diện của trang web của bạn với chi phí bảo trì liên tục gần như bằng không.
Bước 2: Chọn Plugin đa ngôn ngữ cho nội dung động
Cài đặt Polylang hoặc WPML cho nội dung bài đăng, trang và sản phẩm. Cấu hình cấu trúc URL (/es/, /fr/) và các thẻ hreflang. Điều này cung cấp cho bạn cơ sở hạ tầng cho nội dung cơ sở dữ liệu theo từng ngôn ngữ.
Bước 3: Nhân bản các mẫu trình tạo trang của bạn một cách có chọn lọc
Đối với các trang đích có lượng truy cập cao, trang chủ và nội dung marketing chủ chốt, hãy nhân bản trang đó bằng từng ngôn ngữ và dịch các widget theo cách thủ công. Bạn có toàn quyền kiểm soát thiết kế ở những nơi quan trọng.
Bước 4: Sử dụng Dịch chuỗi cho các khối lặp lại
Đối với các phần toàn cầu, các mẫu có thể tái sử dụng và các lời kêu gọi hành động ở chân trang xuất hiện trên mọi trang, hãy sử dụng tính năng dịch chuỗi của plugin đa ngôn ngữ của bạn. Cập nhật ở một nơi, hoán đổi khi hiển thị.
Bước 5: Thực hiện kiểm tra chất lượng
Nội dung trình tạo trang đã dịch phải hiển thị mà không làm dịch chuyển bố cục. Các ngôn ngữ dài hơn (tiếng Đức, tiếng Nga) làm hỏng chiều rộng nút. Các ngôn ngữ ngắn hơn (tiếng Trung, tiếng Nhật) để lại khoảng trắng khó xử. Kiểm tra từng mẫu theo từng ngôn ngữ trước khi triển khai.
Các cạm bẫy thường gặp và cách tránh chúng
Một vài cạm bẫy xuất hiện trong mọi dự án bản địa hóa trình tạo trang.
Văn bản thay thế hình ảnh không dịch
Cả Elementor và Divi đều lưu trữ văn bản thay thế theo từng phiên bản widget, không phải trong Thư viện media. Dịch hình ảnh gốc không dịch được văn bản thay thế trong mọi widget sử dụng nó. Cập nhật văn bản thay thế trong mỗi trang đã nhân bản.
Biểu mẫu và trường tùy chỉnh
Các biểu mẫu liên hệ được nhúng trong các widget của trình tạo trang có các chuỗi riêng (nhãn, phần giữ chỗ, thông báo xác thực). Xem hướng dẫn của chúng tôi về cách dịch Gravity Forms và Contact Form 7 để biết về phía biểu mẫu.
Các Widget và Mẫu toàn cầu
Các thay đổi đối với một mẫu toàn cầu sẽ lan truyền đến mọi trang sử dụng nó, bao gồm cả các bản sao đã dịch. Điều này có thể hữu ích hoặc gây thảm họa tùy thuộc vào việc bạn muốn nội dung được chia sẻ hay riêng biệt. Quyết định rõ ràng cho từng mẫu.
Hết hạn bộ nhớ đệm bản dịch
Các trình tạo trang lưu trữ HTML được hiển thị một cách mạnh mẽ. Sau khi dịch, hãy xóa tất cả bộ nhớ đệm bao gồm bộ nhớ đệm CSS của Elementor (Elementor > Công cụ > Tạo lại CSS) và bộ nhớ đệm CSS tĩnh của Divi.
Tổng kết
Dịch một trang web được xây dựng bằng Elementor hoặc Divi không khó hơn dịch một theme tĩnh – nó chỉ đòi hỏi một mô hình tư duy đúng đắn. Các chuỗi của theme và plugin nằm trong các tệp .po và được chuyển đi qua các tệp .mo. Nội dung trình tạo trang nằm trong cơ sở dữ liệu và được chuyển đi qua các plugin đa ngôn ngữ hoặc nhân bản thủ công. Nhầm lẫn giữa hai cách này là nguồn gốc phổ biến nhất của sự thất vọng "tại sao bản dịch của tôi không hoạt động".
Quy trình làm việc hiệu quả nhất là nhàm chán: các tệp .mo tĩnh cho mọi thứ nằm trong mã, plugin đa ngôn ngữ cho nội dung trang và quản lý thủ công cho các trang đích có giá trị cao. Không có công cụ đơn lẻ nào xử lý cả ba, và bất kỳ ai hứa hẹn điều ngược lại đều đang bán cho bạn một thứ gì đó.
Sẵn sàng dịch các tệp
.pocủa theme và plugin của bạn mà không làm hỏng cấu trúc widget? Dùng thử SimplePoTranslate miễn phí – không yêu cầu thẻ tín dụng. Tải lên.po, tải xuống bản dịch an toàn, thả vàowp-content/languages/.