Làm thế nào để địa phương hóa đúng số?

Những lưu ý nào tôi cần lưu ý trong khi bản địa hóa các số trong ứng dụng front-end của mình?

Ví dụ: Trong tiếng Bồ Đào Nha Brazil (pt-BR), chúng tôi chia hàng ngàn dấu chấm và số thập phân bằng dấu phẩy. Trong tiếng Anh Mỹ (en-US) thì ngược lại. Trong pt-BR, chúng tôi trình bày các chữ số cách nhau bởi hàng ngàn, giống như en-US. Nhưng đọc về tiếng Anh Ấn Độ (en-IN) ngày hôm nay tôi đã bắt gặp viên ngọc này:

Hệ thống đánh số Ấn Độ được ưa thích để phân nhóm chữ số. Khi được viết bằng từ hoặc khi được nói, các số nhỏ hơn 100.000 / 100 000 được thể hiện giống như trong tiếng Anh chuẩn. Các số bao gồm và hơn 100.000 / 100 000 được thể hiện trong một tập hợp con của hệ thống đánh số Ấn Độ.

https://en.wikipedia.org/wiki/Indian_English#Numbering_system

Nghĩa là:

1000000 units in pt-BR are formatted 1.000.000
1000000 units in en-US are formatted 1,000,000
1000000 units in en-IN are formatted 10,00,000

Bên cạnh dấu phẩy và dấu chấm và các dấu tách cụ thể khác, có vẻ như mặt nạ cũng là một mối quan tâm hợp lệ.

Những lưu ý nào khác tôi nên biết trong khi bản địa hóa các số trong ứng dụng front-end của mình? Đặc biệt nếu tôi đang hiển thị số cho các bộ ký tự không phải là tiếng Latin?

Hầu hết các ngôn ngữ lập trình và khung đã có một cơ chế làm việc hợp lý mà bạn có thể sử dụng cho việc này.

Ví dụ: hệ sinh thái C # có không gian tên System.Globalization , cho phép bạn chỉ định Culturebạn muốn:

Console.WriteLine(myMoneyValue.ToString("C", "en-US"));

Đây không phải là thứ mà bạn muốn phát minh lại. Sử dụng các tính năng quốc tế hóa được cung cấp bởi ngôn ngữ hoặc khung yêu thích của bạn.

Một số câu trả lời xuất sắc ở đây đã có, nhưng họ không đề cập đến một điều mà tôi nghĩ là quan trọng không nên quên: đảm bảo bất cứ nơi nào định dạng số diễn ra, rõ ràng (hoặc có thể được kiểm soát) những gì đầu ra được sử dụng cho:

• Khi nó dành cho giao diện người dùng, định dạng cục bộ phải được áp dụng

• khi số sẽ được ghi vào một tệp, hoặc được gửi qua mạng hoặc một dạng khác trong đó số cần ở dạng có thể đọc được bằng máy , hãy đảm bảo rằng nó không được định dạng theo văn hóa hiện tại, nhưng theo một cài đặt cố định (ví dụ, trong môi trường .NET, sử dụng InvariantCulture).

Mặt khác, bạn gặp vấn đề khi số được viết hoặc gửi bằng văn hóa A và đọc hoặc nhận bằng văn hóa B.

Theo kinh nghiệm của tôi, đây là một trong những trở ngại lớn nhất trong việc nội địa hóa các con số đúng cách: trong nỗ lực tập trung định dạng và chuyển đổi số, mọi người bắt đầu tạo các hàm chung, có thể sử dụng lại để định dạng và sau đó bắt đầu sử dụng chúng trên toàn bộ địa điểm. Tuy nhiên, ngay khi người ta cần các số ở định dạng chuỗi có thể đọc được bằng máy ở một nơi khác trong chương trình, thì cần có hai biến thể: định dạng cục bộ và định dạng không cục bộ. Điều này gây ra rủi ro cao khi trộn lẫn hai hình thức chuyển đổi (đặc biệt là khi nhà phát triển và máy thử nghiệm có cài đặt ngôn ngữ mặc định tương tự như cài đặt "cố định" được sử dụng cho định dạng không phải UI, nhưng một phần của cơ sở người dùng thì không).

Phụ lục: vấn đề này có thể trở nên thực sự khó chịu trong các tình huống không rõ ràng trước nếu số sẽ được xử lý bằng máy hoặc bởi một người (hoặc cả hai) sau đó. Ví dụ, như một phần của đầu ra của tệp nhật ký. Trong những trường hợp như vậy, có lẽ tốt nhất là tuân theo tiêu chuẩn "trung tính" không sử dụng dấu phân cách ngoại trừ điểm dưới dạng dấu phân cách thập phân.

Nội địa hóa đúng là khá khó khăn. Hầu hết các hệ sinh thái lập trình đều cố gắng tìm giải pháp cho việc bản địa hóa, nhưng theo kinh nghiệm của tôi, tất cả chúng đều bị phá vỡ ít nhiều. Do đó tôi sẽ đề nghị:

• Đừng cố tự động hóa nội địa hóa. Nó sẽ không luôn luôn hoạt động. Rất khó để bạn phát hiện ra các vấn đề và gây khó chịu cho người dùng của bạn.

• Hãy nhất quán: không trộn lẫn các ngôn ngữ khác nhau và các quy ước định dạng, ví dụ: dấu phân cách thập phân kiểu Brasil trong văn bản tiếng Anh.

• Hoàn toàn hỗ trợ một tập hợp các địa phương nhất định. Làm việc cùng với các dịch giả của bạn để tìm ra định dạng thích hợp cho ngày và số. Bạn có thể sẽ tạo ra bộ công cụ bản địa hóa của riêng bạn, mặc dù hầu hết các vấn đề (nhưng không phải tất cả) có thể được ủy quyền cho một thư viện hiện có.

• Thực hiện các lựa chọn định dạng đơn giản có thể định cấu hình theo từng người dùng: định dạng cho ngày và thời gian, dấu tách thập phân, tiền tệ ưa thích, Số. Điều này đặc biệt hữu ích cho khách du lịch, người nước ngoài hoặc những người khác cần kết hợp nhiều địa phương hoặc văn hóa độc lập với ngôn ngữ.

Một cân nhắc quan trọng: Bạn nên quyết định bao nhiêu là đủ. Bởi vì nếu bạn đi xuống hố thỏ cố gắng bản địa hóa một cách hoàn hảo, nó sẽ ngày càng trở nên phức tạp.

Lấy một nhãn điển hình như "Bạn đã chọn n mục." Điều này đọc sai nếu chỉ có một mục được chọn. Giải pháp xấu xí nhưng thực dụng là viết "Bạn đã chọn n mục." Nhưng nếu bạn muốn làm điều đó một cách chính xác, bạn cần hai văn bản khác nhau tùy thuộc vào n. Nếu bạn cố gắng làm điều này ở nhiều địa phương, nó sẽ nhanh chóng trở nên thực sự phức tạp, vì các ngôn ngữ khác nhau có ngữ pháp khác nhau. Một số ngôn ngữ có cách chia khác nhau cho một, hai và nhiều mục, v.v. Vì lý do này, những người biết sẽ luôn phàn nàn rằng các khung nội địa hóa hiện tại là không đủ.

Nhưng bạn phải chọn các trận đánh của mình, và quyết định mức độ tinh vi nào là đủ. Đối với nhiều mục đích, một thư viện nội địa hóa tiêu chuẩn để định dạng số và ngày là đủ.

Bạn không thể nhận thức được tất cả các cảnh báo của ngôn ngữ. Bạn đang nói về những con số, nhưng có số nhiều, giới tính, đối chiếu. Bạn cần biết họ tồn tại và dựa vào công việc rộng rãi được thực hiện bởi những người khác, đặc biệt là các dự án ICU và CLDR.

Hầu hết các ngôn ngữ hiện đại thực hiện một số hoặc tất cả các tính năng của các dự án này, nhưng ngay cả khi chúng không có, đọc về các dự án này sẽ cho bạn ý tưởng tốt về những gì cần tìm kiếm.

http://site.icu-project.org

http://cldr.unicode.org

Cập nhật

Công cụ khảo sát CLDR cung cấp quyền truy cập vào tất cả các mẫu. Điều đó sẽ chỉ cho bạn cách định dạng một số trong ngôn ngữ và khu vực nhất định. Ví dụ: tiếng Bồ Đào Nha (Bồ Đào Nha):

http://st.unicode.org/cldr-apps/v#/pt_PT/Number_Formatted_Potypes/

Và nếu bạn thực sự muốn kiểm tra tất cả dữ liệu (và có thể sử dụng nó), bạn có thể tải xuống CLDR ở định dạng JSON từ GitHub:

https://github.com/unicode-cldr/cldr-json#cldr-json

Thông tin thêm về tải xuống ở đây:

http://cldr.unicode.org/index/doads

Chà, trong khi tôi hài lòng với tất cả các câu trả lời ở đây, tôi không thực sự hài lòng với từng câu trả lời riêng biệt để đánh dấu một câu trả lời đúng.

Cho đến nay, đây là những gì chúng ta nên biết khi bản địa hóa các số:

Đối với con người :

• Hàng ngàn dải phân cách không phải lúc nào cũng phân tách ở hàng ngàn. Xem trường hợp Ấn Độ trong câu hỏi;
• Hàng ngàn và số thập phân nhân vật thay đổi văn hóa để văn hóa. Trong tiếng Đức, hàng ngàn người được phân chia bằng cách sử dụng khoảng trắng, ví dụ, trong khi bằng tiếng Anh, nó là dấu phẩy và tiếng Bồ Đào Nha là dấu chấm;
• Chúng tôi không có thông tin nếu có sự khác biệt có liên quan giữa các ngôn ngữ từ trái sang phải và phải sang trái;
• Cung cấp một bộ nội địa hóa được hỗ trợ cụ thể và làm cho nó rõ ràng cho người dùng của bạn;
• Cho phép người dùng của bạn thay đổi nội địa hóa mặc định thành một trong những bản địa hóa được hỗ trợ và họ sẽ rất vui và gửi cho bạn những chiếc bánh rất biết ơn, vì bạn là một vị thần hào phóng. :);

Đối với máy tính :

• Hãy nhớ rằng các máy không khoan dung và phải luôn nhận được cùng định dạng trong khi xê-ri hóa và khử nối tiếp một số;
• Gắn bó với một định dạng duy nhất cho nó;
• Sử dụng định dạng cần thiết tối thiểu có thể. Tránh hàng ngàn phân tách, số thập phân phải đủ để tuần tự hóa và khử tuần tự.

Dành cho nhà phát triển :

• (như được đề xuất bởi @hyde bên dưới): Sử dụng thư viện hiện có để bản địa hóa;
• Nếu bạn có thể, hãy sử dụng các trình kiểm tra gốc và chỉ định các trường hợp kiểm thử bản địa hóa / quốc tế hóa, nếu không thì tin tưởng vào thư viện;
• Hãy nhớ rằng nội địa hóa là một vấn đề chủ yếu được giải quyết. Mỗi ngôn ngữ chính có một thư viện, bản địa hoặc bên ngoài, có thể bản địa hóa số, ngày và thời gian;