Các bạn có nghĩ rằng quốc tế hóa chỉ nên được thực hiện ở cấp mã hay nó cũng nên được thực hiện trong cơ sở dữ liệu.Quốc tế hóa trong cơ sở dữ liệu
Có bất kỳ mẫu thiết kế hoặc thực tiễn được chấp nhận nào để quốc tế hóa cơ sở dữ liệu không?
Nếu bạn cho rằng đó là vấn đề về mã thì bạn có sử dụng tệp Tài nguyên để tra cứu một khóa được trả về từ cơ sở dữ liệu không?
Cảm ơn
Quốc tế hóa mở rộng đến cơ sở dữ liệu vì cột của bạn sẽ có thể giữ dữ liệu. NText, NChar, NVarchar thay vì Text, Char, Varchar.
Theo như giao diện người dùng của bạn, đối với nhãn không thay đổi, tệp tài nguyên là phương pháp tốt để sử dụng.
Phụ thuộc rất nhiều vào những gì bạn đang lưu trữ trong cơ sở dữ liệu của mình. Lấy ví dụ từ một dự án gần đây tôi đã được, một tiêu đề phim được nhập vào một trang web của khách hàng và chỉ hiển thị cho khách hàng đó là trò chơi công bằng để lưu trữ như trong cơ sở dữ liệu. Mặt khác, mã lỗi máy chiếu, vì máy khách có thể xem nó, cũng như bởi các trung tâm hoạt động mạng có thể ở các quốc gia khác nhau, nên được lưu trữ dưới dạng mã lỗi (và hỗ trợ dữ liệu, như giờ đèn và tiêu đề của bộ phim đang được hiển thị) có thể được dịch ở cấp gui tùy thuộc vào cài đặt ngôn ngữ của người xem.
Nếu bạn đề cập đến việc làm cho ứng dụng của bạn hỗ trợ nhiều ngôn ngữ ở cấp độ giao diện người dùng thì có nhiều khả năng hơn. Nếu các nhãn không bao giờ thay đổi, trừ khi bạn phát hành một phiên bản mới, thì các tệp tài nguyên được nhúng trong bản thực thi hoặc bản lắp ráp chính là đặt cược tốt nhất của bạn, vì chúng hoạt động nhanh hơn. Nếu nhãn của bạn, mặt khác, cần phải được điều chỉnh trong thời gian chạy bởi người sử dụng, sau đó lưu trữ các bản dịch trong cơ sở dữ liệu là một lựa chọn tốt. Theo như chính mã, tên của các bảng & trường trong cơ sở dữ liệu, chúng tôi giữ chúng bằng tiếng Anh càng nhiều càng tốt, vì tiếng Anh là tiêu chuẩn "thực tế" cho người CNTT.
@hova bao gồm các kỹ thuật, nhưng điều bạn có thể muốn xem xét là hỗ trợ hệ thống hiển thị ngôn ngữ bạn không hiểu.
Một cách để đối phó với điều này là phải có tiếng Anh làm ngôn ngữ mặc định và cài đặt người dùng chuyển sang ngôn ngữ khác. Bằng cách đó, người dùng hỗ trợ của bạn có thể đăng nhập và xem hệ thống một cách tự nhiên (giả sử tiếng Anh là ngôn ngữ đầu tiên của họ) và người dùng thực tế của bạn có thể xem hệ thống bằng ngôn ngữ đầu tiên của họ. IMO, dữ liệu phải luôn là 'tự nhiên' - bằng ngôn ngữ của người dùng.
Điều gì làm tăng thêm một điểm thú vị nữa - liệu hệ thống của bạn có cho phép nhiều ngôn ngữ cài đặt qua biên giới không? Theo kinh nghiệm của tôi, đối với giao diện người dùng có, nhưng đối với dữ liệu thì không. Để lấy một ví dụ nhỏ về định dạng địa chỉ, một lá thư cho một bên thứ ba của Pháp từ một hệ thống Thụy Sĩ vẫn phải có một địa chỉ định dạng Thụy Sĩ thay vì một địa chỉ của Pháp, vì nó phải đi qua hệ thống bưu chính Thụy Sĩ trước.
Nếu khách hàng của bạn là người Nhật và muốn nhìn thấy tên của họ trong Kanji và Katakana (và đôi khi trong hầu hết các trang chính thức Gaiji), bạn phải lưu trữ chúng dưới dạng Unicode. Không có cách nào xung quanh đó.
Thậm chí những thứ như địa chỉ rất khác nhau giữa Hoa Kỳ và Nhật Bản. Một lược đồ sẽ không cắt nó cho cả hai.
Thực ra, bạn sai về điều định dạng địa chỉ. Liên minh Bưu điện Quốc tế yêu cầu điều cuối cùng trong địa chỉ là tên quốc gia và được gạch dưới. Tất cả hệ thống bưu chính của Thụy Sĩ cần phân tích cú pháp là tên quốc gia. –