Lập Luận Ủng Hộ và Phản Đối i18n Dựa Trên Trình Biên Dịch

Nếu bạn đã xây dựng các ứng dụng web hơn một thập kỷ, bạn sẽ biết rằng Quốc tế hóa (i18n) luôn là một điểm gây khó khăn. Đây thường là công việc không ai muốn làm — trích xuất chuỗi, quản lý các tệp JSON, và lo lắng về các quy tắc số nhiều.

Gần đây, một làn sóng mới các công cụ i18n "dựa trên trình biên dịch" đã xuất hiện, hứa hẹn sẽ làm biến mất những khó khăn này. Lời mời gọi thật hấp dẫn: Chỉ cần viết văn bản trong các component của bạn, và để công cụ build lo phần còn lại. Không cần khóa, không cần import, chỉ đơn giản là ma thuật.

Nhưng như với tất cả các trừu tượng trong kỹ thuật phần mềm, ma thuật luôn đi kèm với một cái giá.

Trong bài blog này, chúng ta sẽ khám phá sự chuyển dịch từ các thư viện khai báo sang các phương pháp dựa trên trình biên dịch, những khoản nợ kiến trúc ẩn mà chúng mang lại, và lý do tại sao cách "nhàm chán" có thể vẫn là cách tốt nhất cho các ứng dụng chuyên nghiệp.

Lịch Sử Ngắn Gọn về Dịch Thuật

Để hiểu chúng ta đang ở đâu, chúng ta phải nhìn lại nơi chúng ta đã bắt đầu.

Khoảng năm 2011–2012, cảnh quan JavaScript rất khác biệt. Các bundler như chúng ta biết ngày nay (Webpack, Vite) chưa tồn tại hoặc còn trong giai đoạn sơ khai. Chúng ta phải dán các script lại với nhau ngay trong trình duyệt. Trong thời kỳ này, các thư viện như i18next đã ra đời.

Chúng giải quyết vấn đề theo cách duy nhất có thể vào thời điểm đó: Từ điển thời gian chạy (Runtime Dictionaries). Bạn tải một đối tượng JSON khổng lồ vào bộ nhớ, và một hàm sẽ tra cứu các khóa ngay lập tức. Cách này đáng tin cậy, rõ ràng và hoạt động ở mọi nơi.

Tiến tới ngày nay. Chúng ta có các trình biên dịch mạnh mẽ (SWC, các bundler dựa trên Rust) có thể phân tích Cây Cú Pháp Trừu Tượng (AST) trong vài mili giây. Sức mạnh này đã sinh ra một ý tưởng mới: Tại sao chúng ta phải quản lý khóa thủ công? Tại sao trình biên dịch không thể nhìn thấy đoạn văn bản "Hello World" và thay thế nó cho chúng ta?

Và thế là i18n dựa trên trình biên dịch ra đời.

Sức Hấp Dẫn của Trình Biên Dịch (Cách Tiếp Cận "Phép Thuật")

Có một lý do khiến cách tiếp cận mới này đang trở thành xu hướng. Đối với một nhà phát triển, trải nghiệm này thật tuyệt vời.

1. Tốc Độ và "Dòng Chảy"

Khi bạn đang tập trung, việc dừng lại để nghĩ tên biến (home_hero_title_v2) sẽ làm gián đoạn dòng chảy công việc của bạn. Với cách tiếp cận trình biên dịch, bạn chỉ cần gõ <p>Welcome back</p> và tiếp tục. Không có sự cản trở nào.

2. Nhiệm Vụ Cứu Hộ Di Sản

Hãy tưởng tượng bạn thừa kế một codebase khổng lồ với 5.000 component và không có bản dịch nào. Việc bổ sung hệ thống dựa trên khóa thủ công sẽ là một cơn ác mộng kéo dài hàng tháng. Công cụ dựa trên trình biên dịch hoạt động như một chiến lược cứu hộ, ngay lập tức trích xuất hàng ngàn chuỗi mà bạn không cần phải chạm vào bất kỳ file nào thủ công.

3. Thời Đại AI

Đây là một lợi ích hiện đại mà chúng ta không nên bỏ qua. Các trợ lý lập trình AI (như Copilot hoặc ChatGPT) tự nhiên tạo ra JSX/HTML tiêu chuẩn. Chúng không biết sơ đồ khóa dịch thuật cụ thể của bạn.

• Khai báo: Bạn phải viết lại đầu ra của AI để thay thế văn bản bằng các khóa.
• Trình biên dịch: Bạn chỉ cần sao chép-dán mã của AI, và nó hoạt động ngay.

Kiểm Tra Thực Tế: Tại Sao "Phép Thuật" Lại Nguy Hiểm

Mặc dù "phép thuật" rất hấp dẫn, nhưng sự trừu tượng này lại bị rò rỉ. Dựa vào công cụ xây dựng để hiểu ý định của con người sẽ tạo ra sự mong manh về kiến trúc.

1. Sự Mong Manh Dựa Trên Phán Đoán (Trò Chơi Đoán)

Trình biên dịch phải đoán đâu là nội dung và đâu là mã.

• className="active" có được dịch không? Nó là một chuỗi.
• status="pending" có được dịch không?
• Có phải <MyComponent errorMessage="An error occurred" /> được dịch không?
• Có phải một ID sản phẩm như "AX-99" được dịch không?

Bạn không thể tránh khỏi việc "đấu tranh" với trình biên dịch, thêm các chú thích cụ thể (như // ignore-translation) để ngăn nó phá vỡ logic ứng dụng của bạn.

2. Giới Hạn Cứng của Dữ Liệu Động

Việc trích xuất của trình biên dịch dựa trên phân tích tĩnh. Nó phải nhìn thấy chuỗi ký tự nguyên văn trong mã của bạn để tạo ra một ID ổn định. Nếu API của bạn trả về một chuỗi mã lỗi như server_error, bạn không thể dịch nó bằng trình biên dịch vì trình biên dịch không biết chuỗi đó tồn tại tại thời điểm xây dựng. Bạn buộc phải xây dựng một hệ thống "chỉ chạy thời gian thực" phụ trợ chỉ dành cho dữ liệu động.

3. "Bùng Nổ Chunk" và Hiện Tượng Thác Nước Mạng

Để cho phép tree-shaking, các công cụ trình biên dịch thường chia nhỏ bản dịch theo từng component.

• Hệ quả: Một trang hiển thị với 50 component nhỏ có thể kích hoạt 50 yêu cầu HTTP riêng biệt cho các đoạn dịch nhỏ. Ngay cả với HTTP/2, điều này tạo ra một chuỗi yêu cầu mạng khiến ứng dụng của bạn cảm thấy chậm chạp so với việc tải một gói ngôn ngữ duy nhất được tối ưu hóa.

4. Chi phí hiệu năng khi chạy

Để làm cho bản dịch phản ứng (để chúng cập nhật ngay lập tức khi bạn chuyển đổi ngôn ngữ), trình biên dịch thường chèn các hook quản lý trạng thái vào mọi component.

• Chi phí: Nếu bạn render một danh sách gồm 5.000 mục, bạn sẽ khởi tạo 5.000 hook useState và useEffect chỉ để xử lý văn bản. Điều này tiêu tốn bộ nhớ và chu kỳ CPU mà các thư viện khai báo (thường sử dụng một Context provider duy nhất) có thể tiết kiệm được.

Cái bẫy: Bị khóa nhà cung cấp

Đây có thể coi là khía cạnh nguy hiểm nhất của i18n dựa trên trình biên dịch.

Trong một thư viện khai báo, mã nguồn của bạn chứa ý định rõ ràng. Bạn sở hữu các khóa. Nếu bạn chuyển đổi thư viện, bạn chỉ cần thay đổi phần import.

Trong cách tiếp cận dựa trên trình biên dịch, mã nguồn của bạn chỉ là văn bản tiếng Anh. "Logic dịch thuật" chỉ tồn tại bên trong cấu hình plugin xây dựng. Nếu thư viện đó ngừng được duy trì, hoặc nếu bạn vượt quá khả năng của nó, bạn sẽ bị mắc kẹt. Bạn không thể dễ dàng "eject" vì bạn không có bất kỳ khóa dịch nào trong mã nguồn của mình. Bạn sẽ phải tự tay viết lại toàn bộ ứng dụng để di chuyển sang giải pháp khác.

Mặt khác: Rủi ro của phương pháp khai báo

Công bằng mà nói, cách khai báo truyền thống cũng không hoàn hảo. Nó có những "cạm bẫy" riêng.

1. Địa ngục Namespace: Bạn thường phải quản lý thủ công các tệp JSON nào sẽ được tải (common.json, dashboard.json, footer.json). Nếu bạn quên một tệp, người dùng sẽ thấy các khóa thô.
2. Tải quá mức: Nếu không cấu hình cẩn thận, rất dễ vô tình tải tất cả các khóa dịch của bạn cho tất cả các trang ngay lần tải đầu tiên, làm phình to kích thước gói của bạn.
3. Trôi đồng bộ: Thông thường các khóa vẫn còn trong file JSON dù component sử dụng chúng đã bị xóa. Các file dịch của bạn sẽ ngày càng phình to, chứa đầy các "khóa ma."

Giải pháp Trung gian của Intlayer

Đây là nơi các công cụ như Intlayer cố gắng đổi mới. Intlayer hiểu rằng dù compiler rất mạnh mẽ, nhưng phép thuật ngầm lại nguy hiểm.

Intlayer cung cấp một lệnh transform độc đáo. Thay vì chỉ làm phép thuật trong bước build ẩn, nó thực sự có thể viết lại mã component của bạn. Nó quét văn bản và thay thế bằng các khai báo nội dung rõ ràng trong codebase của bạn.

Điều này mang lại cho bạn lợi ích của cả hai thế giới:

1. Độ chi tiết: Bạn giữ bản dịch gần với các component của mình (cải thiện tính mô-đun và tree-shaking).
2. An toàn: Bản dịch trở thành mã rõ ràng, không phải là phép thuật ẩn trong thời gian build.
3. Không bị khóa: Vì mã được chuyển đổi thành cấu trúc khai báo tiêu chuẩn trong repo của bạn, bạn không giấu logic trong một plugin webpack.

Kết luận

Vậy, bạn nên chọn gì?

Nếu bạn là một Junior Developer, một Nhà sáng lập đơn lẻ, hoặc đang xây dựng MVP: Phương pháp dựa trên compiler là một lựa chọn hợp lệ. Nó cho phép bạn di chuyển cực kỳ nhanh. Bạn không cần phải lo lắng về cấu trúc file hay các khóa. Bạn chỉ cần xây dựng. Nợ kỹ thuật là vấn đề của "Bạn trong tương lai."

Nếu bạn đang xây dựng một Ứng dụng Chuyên nghiệp, Cấp Doanh nghiệp: Phép thuật thường là một ý tưởng tồi. Bạn cần kiểm soát.

• Bạn cần xử lý dữ liệu động từ backend.
• Bạn cần đảm bảo hiệu suất trên các thiết bị cấu hình thấp (tránh hiện tượng hook bị quá tải).
• Bạn cần đảm bảo rằng bạn không bị khóa vào một công cụ build cụ thể mãi mãi.

Đối với các ứng dụng chuyên nghiệp, Quản lý Nội dung Khai báo (như Intlayer hoặc các thư viện đã được thiết lập) vẫn là tiêu chuẩn vàng. Nó tách biệt các mối quan tâm của bạn, giữ cho kiến trúc của bạn sạch sẽ, và đảm bảo rằng khả năng đa ngôn ngữ của ứng dụng không phụ thuộc vào một trình biên dịch "hộp đen" đoán ý định của bạn.