Cách bản địa hóa ứng dụng di động

Nếu bạn đang tìm cách bản địa hóa một ứng dụng di động, bạn thường không chỉ cần “mẹo dịch thuật”. Bạn cần một quy trình làm việc an toàn cho việc phát hành, bao quát các chuỗi trong ứng dụng, bố cục, quy tắc số nhiều, hỗ trợ từ phải sang trái, ảnh chụp màn hình và siêu dữ liệu trên cửa hàng mà không làm hỏng sản phẩm.

Đây chính là điểm khác biệt then chốt: bản địa hóa ứng dụng di động không chỉ là dịch văn bản. Đó là việc điều chỉnh ứng dụng, trang sản phẩm và quy trình kiểm thử chất lượng cho từng thị trường mục tiêu. Apple cho biết App Store hiện có mặt tại 175 khu vực và 40 ngôn ngữ, trong khi Android 13 đã giới thiệu tùy chọn ngôn ngữ riêng cho từng ứng dụng ở cấp hệ thống. Nói cách khác, cả hai nền tảng lớn hiện nay đều coi việc lựa chọn ngôn ngữ là một phần cốt lõi của trải nghiệm sản phẩm, chứ không phải là một yếu tố phụ.

Hướng dẫn này sẽ trình bày các bước thực tế dành cho các nhóm phát triển iOS và Android.

Tóm tắt nhanh:

• Phân biệt rõ bản địa hóa trong ứng dụng với bản địa hóa trên App Store và Google Play.
• Tách riêng các chuỗi văn bản trước khi dịch bất cứ thứ gì.
• Xử lý số nhiều, biến, ngày tháng, tiền tệ và hỗ trợ từ phải sang trái ngay từ đầu.
• Kiểm thử với ngôn ngữ giả lập trước khi phát hành bản dịch thực tế.
• Bản địa hóa cả ảnh chụp màn hình và tài sản trên cửa hàng, không chỉ phần mô tả.

Bản địa hóa ứng dụng di động thực sự bao gồm những gì

Công việc bản địa hóa thường chia thành hai hướng chính.

1. Bản địa hóa trong ứng dụng

Đây là phần sản phẩm chính:

• Chuỗi giao diện người dùng
• Thông báo lỗi và nội dung hướng dẫn người dùng mới
• Ngày tháng, giờ, số, tiền tệ và đơn vị đo lường
• Chuỗi văn bản có tính đến số nhiều và giới tính
• Mở rộng bố cục và hành vi từ phải sang trái
• Hình ảnh hoặc biểu tượng chứa văn bản hoặc ý nghĩa về hướng

Apple khuyến nghị rõ ràng nên sử dụng Xcode, Foundation APIs, Auto Layout, hỗ trợ Unicode, danh mục tài sản đã bản địa hóa và các biểu tượng nhận biết hướng để chuẩn bị ứng dụng cho thị trường toàn cầu. Android cũng khuyến nghị sử dụng tài nguyên nhận biết ngôn ngữ, hỗ trợ ngôn ngữ ứng dụng và bố cục nhận biết từ phải sang trái thay vì văn bản và vị trí được mã hóa cứng.

2. Bản địa hóa trang giới thiệu trên cửa hàng

Đây là cách người dùng khám phá ứng dụng của bạn:

• tên ứng dụng
• phụ đề hoặc mô tả ngắn
• mô tả đầy đủ
• từ khóa
• ảnh chụp màn hình
• video xem trước ứng dụng hoặc video quảng bá

Hãy coi đây là một phần nội dung riêng biệt. Một ứng dụng được bản địa hóa tốt vẫn có thể hoạt động kém nếu trang sản phẩm chung chung, chưa dịch hoặc hình ảnh không phù hợp với thị trường mục tiêu.

Bắt Đầu Với Quốc Tế Hóa, Không Phải Dịch Thuật

Dịch thuật là bước cuối cùng trong một quy trình bắt đầu từ cấu trúc.

Tách riêng chuỗi văn bản và giữ một ngôn ngữ dự phòng đầy đủ

Trên Android, Google cảnh báo rằng tệp res/values/strings.xml mặc định của bạn phải định nghĩa mọi chuỗi văn bản mà ứng dụng cần. Nếu tệp mặc định không đầy đủ và thiết bị chạy ở một ngôn ngữ không được hỗ trợ, ứng dụng có thể không tải được và hiển thị lỗi với nút Buộc đóng. Đó là lý do tại sao bản địa hóa bắt đầu từ việc quản lý tài nguyên, không phải chọn ngôn ngữ.

Đối với iOS, Apple khuyến nghị tách riêng văn bản và hình ảnh hiển thị với người dùng khỏi mã thực thi để có thể bản địa hóa dưới dạng tệp tài nguyên. Trong quy trình làm việc hiện đại của Apple, string catalogs là phương pháp được khuyên dùng trong Xcode 15 trở lên cho các chuỗi văn bản có chứa số nhiều.

Quy tắc thực tế:

• không bao giờ mã cứng văn bản giao diện trong view hoặc controller
• giữ một ngôn ngữ nguồn chuẩn duy nhất
• đảm bảo mọi chuỗi hiển thị với người dùng đều có khóa, ngữ cảnh và giá trị dự phòng ổn định
• thêm chú thích cho dịch giả đối với các chuỗi dễ gây hiểu nhầm

Một ví dụ nhỏ sẽ giúp hình dung dễ hơn.

Android thường bắt đầu với tệp strings.xml mặc định:

<!-- Nút kêu gọi hành động chính trên màn hình thanh toán. Giữ ngắn gọn. -->
<string name="checkout_cta">Thanh toán ngay</string>
<string name="welcome_title">Chào mừng trở lại, %1$s</string>

Sau đó giao diện sẽ đọc tài nguyên thay vì mã cứng tiếng Anh:

Text(text = stringResource(R.string.checkout_cta))

Trên các nền tảng của Apple, Xcode 15+ thường quản lý ý tưởng tương tự trong string catalog. Một đoạn trích đơn giản từ Localizable.xcstrings có thể như sau:

{
  "sourceLanguage": "en",
  "strings": {
    "Pay now": {
      "localizations": {
        "en": { "stringUnit": { "value": "Pay now" } },
        "fr": { "stringUnit": { "value": "Payer maintenant" } }
      }
    }
  }
}

Bạn không cần phải ghi nhớ định dạng tệp này. Bài học thực tiễn đơn giản hơn: mọi chuỗi hiển thị với người dùng đều cần một nguồn dữ liệu duy nhất, đủ ngữ cảnh cho biên dịch viên và một phương án dự phòng an toàn khi bản dịch cho một ngôn ngữ chưa đầy đủ.

Nếu ứng dụng của bạn cũng sử dụng các tệp ngôn ngữ có cấu trúc, hướng dẫn của chúng tôi về Các công cụ dịch JSON tốt nhất năm 2026 sẽ giúp bạn cân nhắc về tự động hóa và bảo toàn định dạng.

Nếu bạn muốn một công cụ trực tiếp cho các tệp tài nguyên ứng dụng, OpenL JSON Translator là lựa chọn đáng tham khảo. Công cụ này được thiết kế để dịch các tệp .json mà không làm hỏng khóa hoặc cấu trúc, đúng như những gì bạn cần khi chuỗi ứng dụng được lưu trong các tệp bản địa hóa có thể đọc bằng máy. Quy trình rất đơn giản: tải lên tệp JSON xuất ra từ ứng dụng, CMS hoặc quy trình bản địa hóa của bạn, chọn ngôn ngữ đích và tải về tệp JSON đã dịch với cấu trúc giữ nguyên. Theo trang giới thiệu sản phẩm, công cụ này hỗ trợ hơn 100 ngôn ngữ và các tệp lên đến 50 MB, rất phù hợp cho các nhóm bản địa hóa ứng dụng xử lý nội dung có cấu trúc.

Hỗ trợ lựa chọn ngôn ngữ ở cấp ứng dụng

Người dùng ngày càng mong muốn có thể chọn ngôn ngữ ứng dụng riêng biệt với ngôn ngữ thiết bị.

Trên các nền tảng của Apple, người dùng có thể chọn ngôn ngữ ưu tiên cho từng ứng dụng độc lập với ngôn ngữ thiết bị. Trên Android, Android 13 đã bổ sung cài đặt ngôn ngữ riêng cho từng ứng dụng, và Google khuyến nghị nên bật hỗ trợ tự động cho từng ứng dụng hoặc tích hợp bộ chọn ngôn ngữ của bạn với các API chính thức.

Điều này ảnh hưởng trực tiếp đến sản phẩm thực tế. Người dùng song ngữ hoặc đa ngữ có thể để điện thoại ở chế độ tiếng Anh nhưng lại muốn sử dụng ứng dụng mua sắm, ngân hàng hoặc giao hàng bằng một ngôn ngữ khác. Nếu ứng dụng của bạn ép buộc sử dụng một mô hình ngôn ngữ duy nhất, bạn đang tạo ra sự bất tiện ngay cả trước khi chất lượng dịch thuật trở thành vấn đề.

Sử dụng hệ thống bản địa hóa của nền tảng

Hãy kiềm chế việc tự xây dựng một hệ thống bản địa hóa song song trừ khi bạn thực sự cần.

Đối với hầu hết các nhóm, hệ thống mặc định của nền tảng là đủ:

• iOS: string catalogs, Localizable.strings, .stringsdict, Foundation formatters, Auto Layout
• Android: res/values/, thư mục tài nguyên theo ngôn ngữ, LocaleConfig, setApplicationLocales(), supportsRtl

Hạ tầng bản địa hóa tùy chỉnh chỉ hợp lý ở quy mô rất lớn, nhưng nó cũng làm tăng chi phí vận hành. Hãy bắt đầu với hệ thống gốc, chỉ mở rộng khi bạn thực sự gặp khó khăn.

Bản địa hóa những phần mà hầu hết các nhóm đều bỏ sót

Các nhóm thường chỉ dịch các câu hiển thị mà bỏ qua các cơ chế sản phẩm xung quanh.

Số nhiều, biến và ngữ pháp

Quy tắc số nhiều không phải lúc nào cũng giống nhau. Quy tắc số nhiều của Unicode CLDR định nghĩa các nhóm như zero, one, two, few, many, và other, và mỗi ngôn ngữ lại sử dụng các nhóm khác nhau. Apple lưu ý rằng trong quy trình .stringsdict cũ, chỉ cần có nhóm other, nhưng nếu bỏ qua các nhóm đặc thù của ngôn ngữ thì vẫn có thể tạo ra kết quả sai ngữ pháp. Android và iOS đều dựa vào xử lý số nhiều theo ngôn ngữ vì lý do này.

Đây là điểm mà dịch máy đơn giản thường thất bại:

• 1 file và 2 files rất dễ trong tiếng Anh
• Các ngôn ngữ Slav thường cần nhiều hơn hai dạng số nhiều
• Một số ngôn ngữ thay đổi cả danh từ, động từ hoặc các từ xung quanh cùng lúc

Đừng bao giờ xây dựng giao diện số nhiều bằng cách ghép các đoạn như "You have " + count + " messages". Hãy sử dụng tài nguyên số nhiều của nền tảng.

Dưới đây là cấu trúc tối thiểu trên mỗi nền tảng.

Android:

<plurals name="files_remaining">
  <item quantity="one">Còn lại %1$d tệp</item>
  <item quantity="other">Còn lại %1$d tệp</item>
</plurals>

Text(text = pluralStringResource(R.plurals.files_remaining, count, count))

Ví dụ .stringsdict cũ trên iOS:

<plist version="1.0">
<dict>
  <key>%#@files@</key>
  <dict>
    <key>NSStringLocalizedFormatKey</key>
    <string>%#@files@</string>
    <key>files</key>
    <dict>
      <key>NSStringFormatSpecTypeKey</key>
      <string>NSStringPluralRuleType</string>
      <key>NSStringFormatValueTypeKey</key>
      <string>d</string>
      <key>one</key>
      <string>Còn lại %d tệp</string>
      <key>other</key>
      <string>Còn lại %d tệp</string>
    </dict>
  </dict>
</dict>
</plist>

Từ Xcode 15 trở đi, Apple khuyến nghị xử lý số nhiều trong string catalog thay vì .stringsdict, nhưng nguyên tắc vẫn giữ nguyên: cung cấp cho nền tảng một mẫu thông điệp và để hệ thống tự chọn dạng ngôn ngữ phù hợp.

Để tìm hiểu thêm về các quy tắc kiểm soát placeholder và chuỗi có cấu trúc, hãy xem Cách dịch tài liệu kỹ thuật mà không làm hỏng mã.

Ngày tháng, số, tiền tệ và đơn vị

Apple khuyến nghị rõ ràng nên sử dụng các API của Foundation để định dạng ngày tháng, độ dài, trọng lượng, giá cả và ký hiệu tiền tệ theo từng ngôn ngữ. Nguyên tắc tương tự cũng áp dụng trên Android: hãy định dạng dữ liệu bằng các API nhận biết ngôn ngữ thay vì cố định dấu câu, dấu thập phân hoặc thứ tự đơn vị.

Những lỗi phổ biến bao gồm:

• 03/04/2026 có thể mang ý nghĩa khác nhau ở các khu vực khác nhau
• cố định ký hiệu đô la cho các thị trường không dùng USD
• 1,234.56 hiển thị sai ở các ngôn ngữ dùng dấu phẩy làm dấu thập phân
• đơn vị đo lường hiển thị theo hệ thống không phù hợp

Nếu ứng dụng của bạn có các tính năng như lên lịch, thanh toán, khung thời gian giao hàng hoặc phân tích dữ liệu, thì đây là một phần của bản địa hóa, không chỉ là làm đẹp giao diện.

Mở rộng bố cục và hỗ trợ ngôn ngữ viết từ phải sang trái

Tiếng Anh thường ngắn gọn. Tiếng Đức thì dài hơn. Tiếng Ả Rập và tiếng Do Thái lại đọc từ phải sang trái. Một bố cục trông ổn bằng tiếng Anh có thể bị vỡ nghiêm trọng ở các ngôn ngữ khác.

Apple khuyến nghị kiểm thử với các ngôn ngữ giả lập, bao gồm cả ngôn ngữ giả lập đọc từ phải sang trái và ngôn ngữ giả lập có độ dài gấp đôi, trước khi bạn nhập các bản dịch thực tế. Android khuyến nghị sử dụng start và end thay vì left và right, bật android:supportsRtl="true", và kiểm thử bố cục RTL trực tiếp trên thiết bị với chế độ Force RTL.

Danh sách kiểm tra của bạn ở đây rất đơn giản:

• cho phép nút và nhãn mở rộng kích thước
• tránh sử dụng vùng chứa văn bản cố định chiều rộng cho các thành phần UI quan trọng
• phản chiếu giao diện người dùng theo hướng khi phù hợp
• kiểm tra biểu tượng, dấu mũi nhọn, luồng tiến trình và carousel ở chế độ RTL
• kiểm thử văn bản trộn hướng như giao diện tiếng Ả Rập với tên sản phẩm hoặc mã khuyến mãi bằng chữ Latinh

Hình ảnh, biểu tượng, ảnh chụp màn hình và video

Hướng dẫn bản địa hóa của Apple nhấn mạnh một điểm quan trọng mà nhiều nhóm thường bỏ qua: hình ảnh cũng có thể được bản địa hóa. Điều này bao gồm bộ hình ảnh, bộ biểu tượng và hướng của các biểu tượng tùy chỉnh. Nếu ảnh chụp màn hình của bạn chứa giao diện tiếng Anh, văn bản tiếng Anh trên banner, hoặc mũi tên chỉ từ trái sang phải, thì chính ảnh chụp màn hình đó chưa được bản địa hóa.

Điều này đặc biệt quan trọng đối với màn hình giới thiệu, thẻ hướng dẫn và tài sản trên App Store. Người dùng không tách biệt “hình ảnh tiếp thị” với “ngôn ngữ sản phẩm”. Họ đánh giá toàn bộ trải nghiệm cùng một lúc.

Bản địa hóa riêng trang App Store và Google Play của bạn

Đây là nơi nhiều nhóm bị mất lượt cài đặt dù đã làm tốt phần trong ứng dụng.

Yêu cầu của App Store cần lên kế hoạch

Apple khuyến nghị nên bản địa hóa metadata trong App Store Connect, bao gồm mô tả ứng dụng, từ khóa, bản xem trước ứng dụng và ảnh chụp màn hình. Apple cũng cho biết bạn có thể hiển thị tối đa 10 ảnh chụp màn hình trên trang sản phẩm của mình, và tối đa 3 bản xem trước ứng dụng cho mỗi kích thước thiết bị và ngôn ngữ được hỗ trợ. Bản xem trước ứng dụng có thể dài tối đa 30 giây, và ảnh chụp màn hình càng quan trọng hơn khi không có bản xem trước, bởi vì một đến ba ảnh chụp màn hình đầu tiên có thể xuất hiện trong kết quả tìm kiếm.

Điều này có hai ý nghĩa:

1. Những ảnh chụp màn hình đầu tiên của bạn là tài sản giúp tăng khả năng được tìm thấy, không chỉ đơn thuần là tài liệu hướng dẫn.
2. Bạn nên bản địa hóa ảnh chụp màn hình và bản xem trước cho các thị trường ưu tiên hàng đầu thay vì sử dụng lại tài sản tiếng Anh ở mọi nơi.

Yêu cầu của Google Play cần lưu ý

Google Play cũng xem việc bản địa hóa danh sách ứng dụng là một quy trình riêng biệt. Play Console cho phép bạn thêm văn bản bản địa hóa, ảnh chụp màn hình theo ngôn ngữ và các tài sản đồ họa đã được bản địa hóa. Nếu bạn chỉ thêm bản dịch văn bản mà không có tài sản đồ họa bản địa hóa, Google cho biết các hình ảnh mặc định theo ngôn ngữ gốc vẫn sẽ được hiển thị.

Google cũng lưu ý rằng nếu bạn không thêm bản dịch danh sách cửa hàng của riêng mình, người dùng có thể thấy bản dịch tự động kèm theo thông báo rằng nó được tạo tự động. Điều này hữu ích như một phương án dự phòng, nhưng không phải là chiến lược thâm nhập thị trường hiệu quả.

Một tính năng hiện tại đặc biệt đáng chú ý: Play Console cho biết bạn có thể liên tục dịch các chuỗi ứng dụng bằng mô hình Gemini mà không mất phí. Cụ thể hơn, Google nói rằng điều này áp dụng cho các chuỗi ứng dụng từ strings.xml trong các gói ứng dụng được tải lên bản nháp phát hành, và bạn có thể xem trước các bản dịch được tạo ra trong trình giả lập tích hợp trước khi xuất bản. Đây là cách mạnh mẽ để tăng tốc độ bao phủ dịch lần đầu, nhưng vẫn nên có bước kiểm tra lại bởi con người đối với các luồng quan trọng.

Xây dựng quy trình phát hành và kiểm thử chất lượng (QA)

Một quy trình bản địa hóa tốt không chỉ là dịch nhanh hơn mà còn là giảm thiểu những bất ngờ khi phát hành.

Bước 1. Lựa chọn thị trường mục tiêu một cách có chủ đích

Đừng bắt đầu với ý tưởng “dịch mọi thứ sang 20 ngôn ngữ”.

Hãy bắt đầu với:

• tỷ lệ tải xuống hiện tại của bạn
• các quốc gia bạn đang hỗ trợ tích cực
• phạm vi thanh toán, pháp lý và hỗ trợ khách hàng
• liệu bạn có thể bản địa hóa cả ứng dụng và trang giới thiệu trên cửa hàng cùng lúc không

Phát hành hoàn chỉnh cho một thị trường thường hiệu quả hơn là phát hành nửa vời cho năm thị trường.

Bước 2. Chuẩn bị tài nguyên sẵn sàng cho bản địa hóa

Trước khi bắt đầu dịch, hãy đóng băng và chuẩn bị:

• chuỗi nguồn kèm ngữ cảnh
• danh sách ảnh chụp màn hình theo từng thị trường
• bảng thuật ngữ và quy tắc đặt tên sản phẩm
• quy tắc sử dụng placeholder
• hướng dẫn giới hạn ký tự cho nội dung trên cửa hàng
• người chịu trách nhiệm kiểm duyệt theo từng thị trường

Nếu ứng dụng sử dụng nhiều kho lưu trữ hoặc nhiều định dạng tệp, hãy chuẩn hóa cách đặt tên và trích xuất ngay từ đầu.

Bước 3. Kiểm thử với ngôn ngữ giả lập trước

Trên các nền tảng của Apple, hãy sử dụng ngôn ngữ giả lập có độ dài gấp đôi và ngôn ngữ viết từ phải sang trái. Trên Android, hãy kiểm thử các thị trường chưa hỗ trợ, chế độ Force RTL và cài đặt ngôn ngữ ứng dụng. Việc này giúp phát hiện:

• nút bị cắt ngắn
• tiêu đề bị che khuất
• văn bản bị ẩn
• căn chỉnh sai
• chuỗi chưa được bản địa hóa
• giả định trái/phải bị mã hóa cứng

Đây là một trong những bước kiểm thử chất lượng rẻ nhất mà bạn có thể thực hiện.

Bước 4. Thực hiện kiểm thử ngôn ngữ trên thiết bị thực tế

Sau khi các bản dịch đã được tích hợp:

• kiểm tra các luồng quan trọng bằng từng ngôn ngữ mục tiêu
• so sánh hành vi giữa ngôn ngữ hệ thống và ngôn ngữ ứng dụng
• xác minh cách xử lý số nhiều và các chỗ chèn dữ liệu
• kiểm tra thanh toán, ngày tháng và địa chỉ
• rà soát ảnh chụp màn hình và mô tả ứng dụng trên cửa hàng tại thị trường địa phương

Nếu một lỗi ảnh hưởng đến quá trình giới thiệu người dùng mới, thanh toán, xác minh danh tính hoặc thông báo, hãy coi đó là lỗi chặn phát hành.

Danh sách kiểm tra cho sprint bản địa hóa đầu tiên

Nếu đây là lần triển khai nghiêm túc đầu tiên của bạn, hãy giữ sprint đủ nhỏ để hoàn thành trọn vẹn:

• Chọn 1 địa phương mục tiêu, không phải 10.
• Đóng băng chuỗi nguồn cho một nhánh phát hành.
• Xuất tất cả chuỗi onboarding, thanh toán, tài khoản và thông báo kèm chú thích ngữ cảnh.
• Chụp các ảnh màn hình bạn muốn bản địa hóa cho App Store và Google Play.
• Thực hiện một lượt giả lập bản địa hóa trước khi gửi văn bản thật cho dịch giả.
• Dịch chuỗi ứng dụng và nội dung mô tả cửa hàng trong cùng một sprint.
• Nhập lại bản dịch và kiểm tra chuyển đổi ngôn ngữ ứng dụng trên cả iOS và Android.
• QA 5 hành trình người dùng hàng đầu trên thiết bị thực tế.
• Cập nhật ảnh màn hình, video xem trước ứng dụng và metadata cửa hàng cho cùng một địa phương.
• Phát hành lên TestFlight hoặc kênh nội bộ trước, sau đó theo dõi ticket hỗ trợ và báo cáo sự cố.

Danh sách kiểm tra này được cố ý thu hẹp. Một địa phương với trải nghiệm ứng dụng mượt mà và tài sản cửa hàng đồng bộ sẽ dạy bạn nhiều hơn rất nhiều so với một lần ra mắt vội vã trên nhiều thị trường.

Ví dụ thực tế

Những ý tưởng cốt lõi ở trên không chỉ là lý thuyết.

DoorDash xây dựng dịch thuật như một vấn đề nền tảng

Năm 2022, DoorDash cho biết họ đã dịch hơn một triệu chuỗi văn bản sang bốn ngôn ngữ và giảm thời gian tích hợp ngôn ngữ mới từ hàng giờ làm việc của lập trình viên xuống chỉ còn một lệnh trong vòng một phút. Bài học thú vị không chỉ nằm ở quy mô mà còn ở cấu trúc: DoorDash đã tách biệt chuỗi tĩnh và chuỗi động, bổ sung hỗ trợ thuật ngữ và hướng dẫn phong cách, đồng thời xây dựng các biện pháp kiểm soát để ngăn chuỗi chưa dịch lọt qua.

Trong bài đăng blog ngày 2 tháng 2 năm 2026, DoorDash cho biết nền tảng tích hợp mới của họ hiện đang hỗ trợ đăng ký ở tất cả các thị trường DoorDash và giúp triển khai quốc tế nhanh chóng với khả năng bản địa hóa liền mạch. Đó chính là hình mẫu của bản địa hóa trưởng thành: quy trình làm việc có thể tái sử dụng, linh hoạt theo vùng miền và giảm các giải pháp tạm thời riêng lẻ.

Meta xem bản địa hóa vừa là vấn đề ngôn ngữ vừa là vấn đề dung lượng ứng dụng

Meta cho biết khoảng 57% người dùng Facebook trên Android và 49% người dùng Facebook trên iOS sử dụng ứng dụng bằng ngôn ngữ khác tiếng Anh. Trong cùng bài viết, Meta cho biết việc loại bỏ các tệp dịch đi kèm đã giúp tiết kiệm tới 16,6 MB trên ứng dụng iOS và cho phép Android bổ sung gần một chục ngôn ngữ mới mà không làm tăng kích thước ứng dụng.

Bài học rút ra rất hữu ích ngay cả với các nhóm nhỏ: bản địa hóa có hệ quả về kỹ thuật. Nó ảnh hưởng đến kích thước nhị phân, quá trình tải lúc chạy, cách phân phối bản dịch và cơ chế phát hành, chứ không chỉ là viết nội dung.

Danh sách kiểm tra cuối cùng trước khi phát hành

Hãy sử dụng danh sách này như một bước kiểm tra cuối cùng:

• Tất cả các chuỗi hiển thị cho người dùng đều được tách riêng.
• Các tài nguyên dự phòng mặc định đã đầy đủ.
• Số nhiều và các trình giữ chỗ sử dụng hỗ trợ bản địa hóa gốc của nền tảng.
• Ngày, giờ, số, tiền tệ và đơn vị đều nhận biết theo ngôn ngữ địa phương.
• Bố cục RTL và văn bản pha trộn hướng đã được kiểm tra.
• Văn bản mô tả trên cửa hàng đã được bản địa hóa cho các thị trường mục tiêu.
• Ảnh chụp màn hình và bản xem trước đã được bản địa hóa cho các ngôn ngữ ưu tiên.
• Tính năng chọn ngôn ngữ trong ứng dụng hoạt động đúng trên iOS và Android.
• Kiểm tra chất lượng ngôn ngữ đã bao phủ các hành trình người dùng quan trọng nhất.

Suy nghĩ cuối cùng

Cách đơn giản nhất để nghĩ về bản địa hóa ứng dụng di động là: dịch sản phẩm, bản địa hóa trải nghiệm và kiểm tra bản phát hành.

Nếu bạn làm việc này lần đầu, đừng đặt mục tiêu phủ sóng toàn cầu hoàn hảo ngay từ ngày đầu. Hãy chọn một hoặc hai ngôn ngữ chiến lược, bản địa hóa ứng dụng và trang cửa hàng cùng lúc, thực hiện kiểm tra chất lượng nghiêm túc và học hỏi từ việc sử dụng thực tế. Nếu bạn đã quản lý các tệp tài nguyên và nội dung dành cho nhà phát triển, hãy kết hợp quy trình này với Cách Dịch Tài Liệu Kỹ Thuật Mà Không Làm Hỏng Mã và Các Trình Dịch JSON Tốt Nhất Năm 2026.

Nếu bạn chỉ thực hiện một hành động trong tuần này, hãy làm như sau: chọn 1 ngôn ngữ, chạy 1 lần giả lập bản địa hóa, và bản địa hóa 1 trang App Store hoặc Google Play tương ứng. Bài kiểm tra ba phần đó sẽ cho bạn biết nhiều hơn về mức độ sẵn sàng của mình so với việc dịch song song hai mươi ngôn ngữ.

Nếu bạn cần một bản nháp nhanh cho nội dung ứng dụng, ảnh chụp màn hình hoặc tệp ngôn ngữ có cấu trúc, hãy dùng tự động hóa để tăng tốc bản nháp, sau đó luôn giữ bước kiểm tra chất lượng thủ công trước khi phát hành. Đó là phần bảo vệ niềm tin của người dùng và ngăn chặn việc “đã dịch nhưng chưa thực sự bản địa hóa” khi ra mắt.

Tài liệu tham khảo

• Apple Developer. Địa phương hóa. https://developer.apple.com/localization/
• Apple Developer. Tạo trang sản phẩm của bạn. https://developer.apple.com/app-store/product-page/
• Apple Developer. Tải lên bản xem trước ứng dụng và ảnh chụp màn hình. https://developer.apple.com/help/app-store-connect/manage-app-information/upload-app-previews-and-screenshots
• Apple Developer. Địa phương hóa chuỗi chứa số nhiều. https://developer.apple.com/documentation/xcode/localizing-strings-that-contain-plurals
• Apple Developer. Kiểm thử ứng dụng đã quốc tế hóa của bạn. https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPInternational/TestingYourInternationalApp/TestingYourInternationalApp.html
• Apple Developer. Get it right (to left). https://developer.apple.com/videos/play/wwdc2022/10107/
• Android Developers. Địa phương hóa ứng dụng của bạn. https://developer.android.com/guide/topics/resources/localization
• Android Developers. Tùy chọn ngôn ngữ cho từng ứng dụng. https://developer.android.com/guide/topics/resources/app-languages
• Android Developers. Hỗ trợ các ngôn ngữ và văn hóa khác nhau. https://developer.android.com/training/basics/supporting-devices/languages
• Google Play Console Help. Dịch và địa phương hóa ứng dụng của bạn. https://support.google.com/googleplay/android-developer/answer/9844778?hl=en
• Google Play Console Help. Tạo và thiết lập ứng dụng của bạn. https://support.google.com/googleplay/android-developer/answer/9859152?hl=en
• Unicode CLDR. Quy tắc số nhiều. https://cldr.unicode.org/index/cldr-spec/plural-rules
• DoorDash Engineering. Xây dựng nền tảng dịch DoorDash sang nhiều ngôn ngữ. https://careersatdoordash.com/blog/building-a-platform-to-translate-doordash-into-multiple-languages/
• DoorDash Engineering. Unified Dasher Onboarding: Nền tảng mô-đun để mở rộng toàn cầu. https://careersatdoordash.com/blog/doordash-unified-dasher-onboarding-a-modular-platform-to-scale-globally/
• Engineering at Meta. Language packs: Giải pháp địa phương hóa di động của Meta. https://engineering.fb.com/2022/05/09/android/language-packs/