Tình huống
Bạn là chủ sở hữu của một cửa hàng trực tuyến, đặt tại Ba Lan. Phần lớn khách hàng của bạn đến từ Ba Lan và họ nói tiếng Ba Lan. Nhưng bạn cũng muốn bán sản phẩm của mình ra nước ngoài và khách hàng quốc tế của bạn chủ yếu nói tiếng Anh. Vì vậy, bạn muốn cửa hàng trực tuyến của mình có sẵn bằng cả tiếng Ba Lan và tiếng Anh . Bạn cũng mong đợi rằng các sản phẩm của mình sẽ bán chạy ở Pháp, vì vậy bạn dự đoán rằng bạn sẽ phải chuẩn bị một tiếng Pháp phiên bản của cửa hàng (và có thể cả tiếng Tây Ban Nha quá, vì tại sao không?).
Bạn muốn người dùng của mình có thể chuyển từ phiên bản tiếng Ba Lan
sang phiên bản tiếng Anh và trở lại.
Và rõ ràng là bạn muốn chi tiết sản phẩm chuyển từ tiếng Ba Lan sang tiếng Anh.
Làm thế nào để bạn tạo một ứng dụng web đa ngôn ngữ?
Có hai loại văn bản trong ứng dụng của bạn. Một là tĩnh dữ liệu:nhãn nút, tiêu đề bảng, đồ họa (thường chứa văn bản). Cái kia là do người dùng xác định dữ liệu, chẳng hạn như tên sản phẩm, giá sản phẩm, mô tả sản phẩm, v.v. Dữ liệu thường được lấy từ cơ sở dữ liệu.
Dữ liệu tĩnh là những gì bạn muốn viết dưới dạng chuỗi ký tự trong đầu ra của mình. Dữ liệu do người dùng xác định là dữ liệu mà bạn lấy từ cơ sở dữ liệu của mình.
Hôm nay tôi sẽ không nói về dữ liệu tĩnh. Bất kỳ khuôn khổ web hợp lý nào sẽ xử lý quá trình quốc tế hóa dữ liệu tĩnh. Tham khảo tài liệu về khung ứng dụng web của bạn để biết thêm chi tiết. Tìm kiếm các từ khóa như “quốc tế hóa”, “i18n”, “bản địa hóa” hoặc “bản dịch”.
Hôm nay tôi sẽ nói về cấu trúc cơ sở dữ liệu mà chúng ta thường sử dụng ở đây tại e-point để xử lý dữ liệu đa ngôn ngữ. Trong cơ sở dữ liệu cho cửa hàng của bạn, bạn có thể có product bảng lưu trữ thông tin về tất cả các sản phẩm có sẵn trong cửa hàng.
product bảng có các cột như name , description và price . Khi dịch thông tin sản phẩm sang các ngôn ngữ khác, bạn chỉ phải dịch một số cột. Ở đây bạn sẽ chỉ dịch name và description , nhưng price không thay đổi khi bạn chuyển đổi ngôn ngữ.
Khi chúng tôi thêm hỗ trợ cho nhiều ngôn ngữ, chúng tôi sẽ thêm một bảng mới có tên là language_version , nơi lưu trữ tất cả các phiên bản ngôn ngữ có sẵn trong cửa hàng. Chúng tôi thường thêm một cột có tên là code và một cái tên là is_default (với một ràng buộc thích hợp:chỉ có một phiên bản có thể là phiên bản mặc định).
Tiếp theo, chúng tôi tách product bảng thành hai bảng:bảng product và bảng product_lv . Đối với mỗi sản phẩm, sẽ có một hàng trong product bảng và nhiều hàng trong product_lv bàn; một hàng cho mỗi phiên bản ngôn ngữ. Bảng product_lv chỉ chứa các cột phải được dịch:name và description . Các cột không phụ thuộc vào ngôn ngữ (như price , bởi vì bạn bán với cùng một mức giá bất kể khách hàng của bạn nói tiếng Anh hay tiếng Ba Lan) hãy ở trong bảng product .
Chúng tôi làm tương tự cho mọi bảng có chứa dữ liệu đã dịch. Dữ liệu đã dịch chuyển đến table_lv bảng, dữ liệu không phụ thuộc vào ngôn ngữ vẫn nằm trong bảng chính.
Ưu và nhược điểm
Một nhược điểm rõ ràng là tất cả các hoạt động tạo, truy xuất, cập nhật hoặc xóa (CRUD) trở nên phức tạp hơn một chút. Bạn luôn phải kết hợp với một bảng phiên bản ngôn ngữ bổ sung để có được mô tả phù hợp.
Ưu điểm của thiết kế này là bạn không phải thay đổi giản đồ cơ sở dữ liệu của mình khi bạn thêm phiên bản ngôn ngữ mới. Tôi không nói rằng việc thêm một phiên bản ngôn ngữ mới là dễ dàng. Sau cùng, bạn phải dịch TẤT CẢ các mô tả sản phẩm. Đây là một thách thức về mặt tổ chức nhưng theo quan điểm cơ sở dữ liệu thì khá dễ dàng:rất nhiều phụ trang.
Làm cách nào để bạn thiết kế cơ sở dữ liệu đa ngôn ngữ của mình?
