Quốc tế hóa: Những điều cần suy nghĩ?

Tôi đã lắng nghe bài nói chuyện của Jon Skeet tại Ngày phát hành StackOverflow cuối cùng và anh ấy khơi gợi sự tò mò của tôi về việc quốc tế hóa.

Giả sử tôi có một chương trình làm bánh quế, hoàn thành hoặc vẫn đang được tiến hành và tôi muốn phân phối nó đến các quốc gia khác. Những loại điều tôi cần phải lo lắng về việc quốc tế hóa? Một số cạm bẫy không rõ ràng nhưng dễ dàng là gì?

Điều rõ ràng nhất khiến mọi người chú ý là nhãn của bạn rất có thể sẽ có độ dài khác với phiên bản tiếng Anh. Điều này có thể chơi tàn phá với bố trí của bạn.

Bạn có thể kết thúc với hàng loạt khoảng trắng hoặc nhãn chen chúc và thậm chí tràn ra khoảng trống có sẵn.

Bạn cần làm cho bố cục của bạn linh hoạt và lưu chuyển bất kể kích thước của nội dung. Có một bố cục có thể đối phó với các độ phân giải màn hình khác nhau sẽ đi một chặng đường dài để giải quyết vấn đề này.

Vấn đề lớn khác là hỗ trợ ngôn ngữ từ phải sang trái. Điều này một lần nữa sẽ yêu cầu bố trí của bạn phải linh hoạt.

Nó không chỉ là các menu và hộp thoại cần dịch. Đó là tất cả các tài liệu hỗ trợ, tệp trợ giúp, mẹo công cụ và chú thích tiêu đề cửa sổ. Thường có nhiều văn bản hơn bạn nghĩ trong một ứng dụng và sẽ luôn có một vài chuỗi được thêm trực tiếp thay vì dưới dạng tài nguyên.

Định thời gian và định dạng ngày! Khi xử lý các ứng dụng có lịch trình ngày và thời gian trên các múi giờ, hãy đảm bảo rằng bạn thực hiện đúng.

Duy trì TẤT CẢ giá trị ngày và thời gian dưới dạng dấu thời gian vì chúng đại diện cho một điểm duy nhất trong thời gian. Theo dõi thêm các múi giờ vì bạn sẽ cần thông tin múi giờ để hiển thị chính xác dấu thời gian theo đúng định dạng cho người dùng.

Tôi đang làm việc trên một ứng dụng ngay bây giờ nơi người dùng ở Nhật Bản có thể lên lịch ngày và giờ cho người dùng chạy ứng dụng khách ở Idaho. Đảm bảo rằng khi người dùng thấy 3:00PMrằng họ biết 3:00PMmọi người đang nói về điều gì.

Hãy nhớ rằng chỉ vì một người ở một quốc gia cụ thể không có nghĩa là cô ấy biết ngôn ngữ đó. Ngôn ngữ và địa điểm là hai vấn đề khác nhau.

Số. Hầu hết Châu Âu, Nam Mỹ sử dụng dấu phẩy (10,23) làm dấu tách thập phân trong khi phần còn lại (Anh, Mỹ, v.v.) sử dụng khoảng thời gian (10.23).

Không phải lúc nào cũng dễ dàng ... Có rất nhiều điều cần xem xét, tùy thuộc vào mức độ phức tạp của phần mềm bạn đang phát triển và nơi bạn sẽ gửi nó. Trên thực tế, nó có thể kết thúc ở bất cứ đâu, vì vậy điều quan trọng là địa phương nào bạn sẽ chính thức hỗ trợ.

• Rõ ràng, có ngôn ngữ của các giao diện. Tất cả văn bản bạn sử dụng phải tương đối dễ dàng để thay đổi tương đương với ngôn ngữ khác. Giống như ai đó đã chỉ, chiều dài của nhãn sẽ thay đổi. Ví dụ, một cái gì đó được viết bằng tiếng Trung Quốc sẽ không có chiều rộng giống như một thứ được viết bằng tiếng Đức. Cho phép thêm rằng không chỉ giao diện cơ bản là để dịch, mà tất cả các bong bóng thông tin, các tệp trợ giúp nếu có, thông báo lỗi, có thể không ghi nhật ký tệp, nhưng nó phụ thuộc vào ứng dụng tôi đoán. Nếu ứng dụng của bạn hỗ trợ ngôn ngữ, trang web của bạn cũng có thể muốn theo kịp.
• Mã hóa ký tự. Thật tốt khi cung cấp nhiều ngôn ngữ, nhưng bạn sẽ làm thế nào? Nếu mọi thứ được lập trình với mã hóa ký tự hẹp / cơ bản, bạn sẽ gặp vấn đề với một số dấu và hầu hết các ngôn ngữ không sử dụng ký tự của chúng tôi. Hãy nghĩ về tiếng Hàn, hoặc tiếng Ả Rập. Tôi đoán ai đó sẽ phải sử dụng Unicode càng nhiều càng tốt.
• Bố trí widget / hướng cửa sổ. Ví dụ, nếu bạn chọn hỗ trợ tiếng Ả Rập, bạn sẽ cần phải suy nghĩ về một cách để ít nhiều lật giao diện của bạn. Họ đang đọc từ phải sang trái, vì vậy sẽ rất bình thường khi có nhãn ở bên phải của phần tử mà họ mô tả (ví dụ như hộp văn bản cho mục nhập).
• Định dạng số. Ở một số địa phương, có một dấu phẩy thay vì dấu chấm để tách phần phân số khỏi phần nguyên trong một số. Đó là một điều khá rõ ràng, nhưng tùy thuộc vào miền ứng dụng, có thể có nhiều thứ khác để xem xét. Là số âm giữa dấu ngoặc đơn hoặc có dấu '-' phía trước chúng? Hàng ngàn có tách biệt hay không, với một khoảng trắng hoặc bằng dấu phẩy? Là sự phân tách các chữ số luôn bằng 3, hay chỉ là nhóm đầu tiên bằng 3 và phần còn lại bằng 2? Bạn đang sử dụng số Ả Rập hoặc Ấn Độ, hoặc người khác?
• Định dạng ngày. Nó gần như phức tạp. Bạn có thể phải lưu trữ tên đầy đủ của các ngày trong tuần, của các tháng trong năm và tất cả chúng đều được rút ngắn. Họ đang sử dụng thứ tự nào (ngày, tháng, năm? Tháng, ngày, năm? Năm, tháng, ngày? V.v.).
• Định dạng thời gian. 24 giờ hay 12 giờ? ':' Hoặc 'h'? ':' hoặc là '.' Trong vài giây? Tôi không biết nhiều về định dạng thời gian, nhưng tôi đoán có rất nhiều cách để tôi hiển thị thời gian.
• Đồ họa! Nếu bạn có biểu tượng ... Bạn sẽ muốn xác minh không chỉ các chữ cái hoặc từ trên chúng vẫn có ý nghĩa đối với tất cả các địa phương, mà các biểu tượng bạn sử dụng cũng có ý nghĩa và vẫn được định hướng chính xác. Nếu một mũi tên chỉ trái trong phiên bản tiếng Anh, bạn có cơ hội nó sẽ trỏ phải trong phiên bản tiếng Ả Rập (nhưng không nhất thiết!). Nếu bạn đặt một dấu hiệu dừng lại như một hình bát giác màu đỏ trên biểu tượng của mình, mọi người ở một số địa phương sẽ không biết đó là gì, hoặc tệ hơn, họ sẽ tin rằng nó nên làm một số việc khác ngoài những gì bạn dự định và lập trình .
• Nếu bạn phải xử lý các địa chỉ trong hệ thống của mình, họ cũng sẽ gặp khó khăn ở một số nơi. Đau đầu tuyệt vời nếu bạn phải xác nhận chúng.
• Vân vân.

Hạnh phúc, có thư viện trong nhiều ngôn ngữ để chăm sóc một phần tốt của công việc. Khi bạn không có thư viện tốt để làm điều đó, có lẽ bạn sẽ muốn xác định tham số cho tất cả các ngôn ngữ của mình và xác định chi tiết chúng bằng các tệp XML hoặc các loại tệp cấu hình khác (hoặc trong cơ sở dữ liệu nếu bạn gửi một phần mềm bằng phần mềm hoặc nếu bạn không phiền khi thêm một dấu chân nhỏ).

Nó phụ thuộc rất nhiều vào nền tảng bạn đang sử dụng. .NET hỗ trợ các tệp Tài nguyên có thể thay đổi trong và ngoài tùy thuộc vào bản dựng của khách hàng.

Các vấn đề khác có thể hoặc không thể được hỗ trợ trong nền tảng của bạn bao gồm khả năng đảo ngược thứ tự nhãn và hộp văn bản (một số nền văn hóa thích nhãn ở bên phải). Những nền văn hóa tương tự có thể muốn tất cả các khối văn bản đọc từ phải sang trái.

Đừng quên các giá trị trong bảng tra cứu! Đặt tên trạng thái, mô tả loại, et al.

nếu bạn có các mô tả và tên trong các bảng tra cứu, ví dụ {OrderStatusId, OrderStatusName, OrderStatusDescription} chúng cũng sẽ cần được dịch.

Chọn một bản sao của "Quốc tế hóa .NET: Hướng dẫn của nhà phát triển để xây dựng các ứng dụng web và Windows toàn cầu" của Smith-Ferrier .

Gần đây tôi được giao nhiệm vụ suy nghĩ thấu đáo thông qua toàn bộ vấn đề i18n với bộ ứng dụng của chúng tôi.

Cuốn sách này đưa ra những vấn đề mà tôi không bao giờ có thể nghĩ đến.

Ngoài các cách trên, hãy xem xét các định dạng ngày, chính tả và kiểm soát hướng màn hình. Trong các báo cáo mà ngôn ngữ được đọc từ phải sang trái, bạn cần lo lắng về hướng thụt. Cuối tuần khác nhau giữa các quốc gia. Nếu bạn đang hiển thị lịch, bạn cần đảm bảo rằng cuối tuần hiển thị chính xác. Nếu bạn không sử dụng MS-Windows, hãy kiểm tra các tính năng trong HĐH máy khách liên quan đến việc xử lý các chuỗi đối chiếu để sắp xếp và hệ điều hành như thế nào. Thông báo lỗi phải được dịch cho người dùng khi chế độ không phải là tiếng Anh. Trong mã. Đối với phía cơ sở dữ liệu, bạn cần chọn mã ký tự chính xác. Điều này thay đổi từ cơ sở dữ liệu đến cơ sở dữ liệu và có thể ảnh hưởng đến so sánh ngày.