Cách xác định phạm vi tích hợp dịch thuật cho ứng dụng doanh nghiệp hiện có
Lên kế hoạch dịch thuật trong ứng dụng doanh nghiệp. Xác định nội dung, ngôn ngữ, khâu duyệt, quy tắc dữ liệu, cách xử lý lỗi và kiểm thử nghiệm thu trước khi yêu cầu báo giá.
Hãy bắt đầu với một công việc trọn vẹn mà nhóm của quý vị cần thực hiện bằng một ngôn ngữ khác. Sau đó xác định dịch thuật nằm ở đâu trong công việc đó. Cách này cho nhà cung cấp phần mềm một cơ sở ước tính rõ ràng hơn so với một yêu cầu thêm nút dịch.
Phạm vi cần bao quát văn bản, con người, dữ liệu và kết quả. Phạm vi cũng cần giải thích điều gì xảy ra khi dịch không thành công. Hãy dùng các bước dưới đây để chuẩn bị phạm vi đó trước khi chọn giải pháp kỹ thuật.
Chọn một quy trình cho bản phát hành đầu tiên
Ghi rõ văn bản nguồn đến từ đâu và bản dịch đã duyệt phải được đưa đến đâu. Ví dụ, một nhân viên hỗ trợ có thể cần đọc tin nhắn đến và soạn câu trả lời bằng ngôn ngữ của khách hàng. Đây là một yêu cầu minh họa, không phải báo cáo về một hệ thống Vavus đã được cài đặt.
Liệt kê từng bước: mở tin nhắn, yêu cầu dịch, đọc bản gốc bên cạnh kết quả, chỉnh sửa câu trả lời và phê duyệt để gửi. Quyết định việc dịch sẽ bắt đầu tự động hay chỉ khi nhân viên chọn.
Giữ bản phát hành đầu tiên ở quy mô nhỏ. Kiểm thử một màn hình và một công việc kinh doanh rõ ràng sẽ dễ hơn kiểm thử mọi trường văn bản trong ứng dụng.
Xác định nhu cầu về nội dung và ngôn ngữ
Lập danh sách các trường cần dịch. Tách riêng nhãn ngắn, văn bản tự do, tài liệu và giọng nói. Chúng có thể cần cách xử lý và kiểm thử khác nhau. Đồng thời liệt kê các trường phải giữ nguyên, chẳng hạn như số đơn hàng và mã sản phẩm.
Nêu rõ ngôn ngữ nguồn và ngôn ngữ đích, kể cả các biến thể theo vùng. Ghi lại độ dài văn bản thông thường và khối lượng dự kiến mỗi ngày. Hỏi xem dịch vụ được đề xuất hỗ trợ những tổ hợp ngôn ngữ và định dạng đầu vào nào.
Ngữ cảnh có thể quan trọng đối với văn bản ngắn. Ví dụ, API dịch văn bản của DeepL hỗ trợ một tham số ngữ cảnh có thể ảnh hưởng đến bản dịch mà không dịch chính phần ngữ cảnh đó. Tài liệu của DeepL cũng cho biết các mục văn bản riêng biệt trong cùng một yêu cầu không dùng chung ngữ cảnh. [1] Phạm vi của quý vị cần nêu rõ ngữ cảnh hữu ích sẽ lấy từ đâu.
Xác định thuật ngữ và khâu duyệt của con người
Thu thập các thuật ngữ mà doanh nghiệp của quý vị thường dùng. Bao gồm bản dịch ưu tiên, tên sản phẩm và những từ cần giữ nguyên. Giao cho một người duy trì danh sách này.
Một số dịch vụ dịch thuật hỗ trợ bảng thuật ngữ. Google Cloud Translation mô tả bảng thuật ngữ của mình là một từ điển tùy chỉnh giúp dùng nhất quán thuật ngữ chuyên ngành. [2] Hãy kiểm tra tính năng này với đúng các cặp ngôn ngữ và dịch vụ quý vị chọn. Bảng thuật ngữ không chứng minh rằng toàn bộ tin nhắn là chính xác.
Quyết định những kết quả nào cần người duyệt có chuyên môn ngôn ngữ. Cho người duyệt truy cập văn bản gốc. Đặt một bước phê duyệt rõ ràng trước khi văn bản dành cho khách hàng được gửi đi hoặc xuất bản.
Đặt quy tắc về dữ liệu và quyền truy cập
Mô tả những thông tin mà quy trình xử lý. Dùng ví dụ giả lập trong các lần thử nghiệm ban đầu. Tránh sao chép hồ sơ khách hàng thật vào bản dùng thử chỉ để xem một nút có hoạt động hay không.
Hỏi văn bản sẽ được xử lý ở đâu, ứng dụng sẽ lưu những gì, ai có thể đọc và khi nào dữ liệu bị xóa. Đưa cả nhật ký và bản sao lưu vào cuộc trao đổi này. Xác nhận điều khoản hiện hành của nhà cung cấp và các công cụ kiểm soát có trong gói dịch vụ đã chọn.
Bản thân một giao diện tùy chỉnh không làm cho dịch vụ dịch bên ngoài trở nên riêng tư hay hoạt động ngoại tuyến. Nếu dự án của quý vị cần xử lý cục bộ, hãy nêu yêu cầu đó ngay từ đầu và kiểm thử toàn bộ luồng dữ liệu theo yêu cầu đó.
Lên kế hoạch cho độ trễ và lỗi
Ghi rõ thời gian phản hồi dự kiến và việc nhân viên cần làm nếu dịch vụ không khả dụng. Ứng dụng nên hiển thị trạng thái rõ ràng, chẳng hạn như đang chờ, sẵn sàng để duyệt hoặc thất bại. Giữ lại văn bản gốc.
Đề nghị nhà phát triển phân biệt lỗi tạm thời với lỗi cần thay đổi. Ví dụ, DeepL hướng dẫn thử lại sau một khoảng chờ đối với lỗi vượt giới hạn tần suất, còn khi đã dùng hết hạn mức thì cần một cách xử lý khác. [3] Các yêu cầu lặp lại không được tạo ra thao tác nghiệp vụ trùng lặp, chẳng hạn như gửi cùng một câu trả lời hai lần.
Thống nhất về cảnh báo mức sử dụng và người chịu trách nhiệm hỗ trợ. Tính cả phí dịch vụ, bảo trì và các thay đổi trong tương lai khi so sánh chi phí dự án.
Viết kiểm thử nghiệm thu trước khi phát triển
Chọn các ví dụ tiêu biểu cho từng cặp ngôn ngữ cần thiết. Bao gồm tin nhắn dài, ký tự đặc biệt, trường bị thiếu và các thuật ngữ trong danh sách đã duyệt. Kiểm thử toàn bộ công việc, từ bản ghi nguồn đến kết quả đã lưu hoặc đã gửi.
Đặt tiêu chí đạt mà con người có thể kiểm tra: mã sản phẩm được giữ nguyên, bản dịch chưa duyệt không thể gửi đi, yêu cầu thất bại được hiển thị và người duyệt có thể quay lại bản gốc. Nhờ một người duyệt có chuyên môn đánh giá ý nghĩa và giọng điệu. Ghi lại lỗi và lặp lại đúng các bài kiểm thử đó sau mỗi thay đổi.
Chuẩn bị yêu cầu báo giá rõ ràng
Gửi quy trình, các trường mẫu, cặp ngôn ngữ, khối lượng ước tính, quy tắc dữ liệu và kiểm thử nghiệm thu. Đánh dấu từng mục là bắt buộc khi ra mắt hay có thể để cho bản phát hành sau. Đề nghị nêu các giả định và hạng mục loại trừ bằng văn bản.
Vavus cung cấp dịch vụ xác định phạm vi bằng văn bản cho các dự án tùy chỉnh. [4] Hãy dùng trang báo giá để mô tả ứng dụng hiện có của quý vị và công việc quý vị muốn cải thiện. Phương án tích hợp, triển khai và kiểm thử được đề xuất cần được xác nhận trong phạm vi dự án của quý vị.