7

Tôi có ứng dụng khoa học miễn phí được hàng nghìn người sử dụng ở gần 100 quốc gia. Nhiều người đã đề nghị dịch miễn phí. Bây giờ D2009 làm cho việc này trở nên dễ dàng hơn (với các công cụ nội địa hóa tích hợp và bên ngoài, cộng với hỗ trợ Unicode gốc), tôi muốn thực hiện điều này cho một vài ngôn ngữ và tăng thêm lượng năng lượng người dùng sẽ hỗ trợ.Quy trình bản địa hóa ứng dụng Delphi 2009 của người dịch tự nguyện?

Tôi nghĩ rằng tôi sẽ phân phối bảng tính với danh sách chuỗi (hàng chục chứ không phải hàng trăm) để dịch, trả lại và so sánh các nội dung gửi trong cùng một ngôn ngữ từ 2-3 người dùng rồi làm việc giải quyết sự khác biệt theo sự đồng thuận. Sau đó, tôi sẽ kết hợp các bản địa hóa bằng cách sử dụng Môi trường dịch tích hợp và phân phối các bản cập nhật được bản địa hóa.

Có ai đã chuyển giao bản dịch cho người dùng không? Bất kỳ gotchas, D2009-cụ thể hay cách khác?

EDIT: Có ai đã so sánh hỗ trợ bản địa hóa được tích hợp vào D2009 so với dxgettext không?

Trả lời

6

Tôi chưa bao giờ là bạn của các công cụ bản địa hóa độc quyền cho các ứng dụng Phần mềm miễn phí hoặc Nguồn mở. Sử dụng dxgettext, cảng Delphi của GNU gettext trông giống như một lựa chọn tốt hơn nhiều với tôi:

  • tích hợp vào chương trình (thậm chí muộn hơn nhiều so phát triển của nó) là dễ dàng.
  • Việc trích xuất các chuỗi có thể dịch được thực hiện bằng các chương trình dòng lệnh và do đó dễ dàng được đưa vào một bản dựng tự động.
  • Một bản dịch mới có thể được thêm vào đơn giản bằng cách tạo một thư mục mới với cấu trúc chính xác, sao chép tệp dịch trống vào đó và bắt đầu dịch các chuỗi. Đây là điều mà mỗi người dùng có thể tự làm cho mình, không cần phải liên quan đến tác giả gốc để tạo bản dịch mới. Ngoài ra còn có sự hài lòng tức thì với quy trình này - khi chương trình được khởi động lại, bản dịch mới sẽ được hiển thị ngay lập tức.
  • Thay đổi bản dịch hiện có thậm chí còn dễ dàng hơn việc tạo bản dịch mới. Do đó, nếu người dùng tìm lỗi chính tả hoặc các lỗi khác hoặc cần cải thiện bản dịch, họ có thể sửa chúng một cách dễ dàng và gửi các thay đổi cho tác giả.
  • Phiên bản chương trình mới hoạt động với các bản dịch cũ, hệ thống làm giảm rất duyên dáng - các chuỗi mới và chưa được dịch được hiển thị đơn giản chưa được sửa đổi.
  • Bản dịch chỉ có thể được thực hiện bằng notepad, nhưng cũng có một số công cụ miễn phí để tạo và quản lý các tệp dịch; xem các liên kết trên trang dxgettext. Họ cũng được bản địa hóa và có một số lợi thế so với bảng tính:
    • Vị trí của chuỗi trong mã nguồn có thể được hiển thị (chỉ có ý nghĩa đối với ứng dụng nguồn mở).
    • Tỷ lệ chuỗi đã dịch được hiển thị.
    • Sửa đổi các chuỗi đã dịch cũng được tô sáng.
  • Toàn bộ hệ thống là hoàn thiện và tương lai - Tôi đã sử dụng dxgettext cho Delphi 4 chương trình, và không có thay đổi cần thiết cho Delphi 2009 thậm chí - các tệp dịch thuật luôn được mã hóa UTF-8.

Sử dụng bảng tính để dịch không có vẻ là giải pháp khả thi đối với tôi khi bạn có nhiều ngôn ngữ. Giả sử phiên bản chương trình mới thêm 2 chuỗi mới và thay đổi 10 chuỗi chỉ một chút - bạn sẽ không cần phải thêm chuỗi mới vào và đánh dấu chuỗi đã thay đổi trong tất cả vài chục tệp bảng tính và gửi lại cho người dịch của bạn? Sử dụng dxgettext bạn chỉ cần gửi tập tin po đã thay đổi cho tất cả chúng.

Edit:

Có một nhận xét thú vị về những vấn đề có thể có với dxgettext và thư viện. Tôi chưa bao giờ trải nghiệm điều này, vì tôi đã ngừng sử dụng chuỗi tài nguyên hoàn toàn. Phần lớn nhất của chương trình của chúng tôi là bằng tiếng Đức và chỉ một số ít bằng tiếng Anh hoặc được dịch ra nhiều thứ tiếng.

Thư viện nội bộ của chúng tôi sử dụng "_ (...)" xung quanh tất cả các chuỗi có thể dịch. Có định nghĩa ENGLISHUSEGETTEXT được đặt trên cơ sở từng dự án. Nếu ENGLISH hoặc USEGETTEXT được xác định, thì văn bản tiếng Anh được biên dịch thành các DCU, nếu không văn bản tiếng Đức được biên dịch thành các DCU. Nếu USEGETTEXT không được xác định "_()" được biên dịch dưới dạng hàm trả về tham số của nó, nghĩa là tra cứu bản dịch dxgettext được sử dụng.

+0

Cảm ơn bạn đã trả lời chi tiết - rất nhiều điều để suy nghĩ, đặc biệt là vì tôi thích trao quyền cho người dùng. Giải pháp này có hỗ trợ các ký tự nhiều byte không? – Argalatyr

+0

Tôi thấy "hỗ trợ Unicode đầy đủ" trên trang dxgettext, do đó trông giống như "có" đối với câu hỏi của tôi. – Argalatyr

+3

Tôi cũng ủng hộ dxgettext. Nhưng có một số gotchas bạn có thể sẽ chỉ tìm thấy khi dự án của bạn đã nâng cao: Thông thường, các bản dịch là toàn cầu, có nghĩa là đôi khi một bản dịch phù hợp với cụm từ ở một nơi của chương trình có thể không phù hợp ở một nơi khác. Hỗ trợ cho các thư viện cũng không rõ ràng: Tôi đã bắt đầu sử dụng "tên miền" cho mỗi thư viện, nhưng điều đó có nghĩa là tôi không thể sử dụng chuỗi tài nguyên ở đó vì sau đó tôi sẽ phải đăng ký lại tên miền trên toàn cầu. Nhưng nhìn chung tôi thực sự thích dxgettext. – dummzeuch

4

Tôi có ... Có thể có một số thách thức.

  • một chuỗi không có nghĩa là nhiều, nó cần một ngữ cảnh.
  • hệ quả, cùng một chuỗi có thể cần phải có nhiều bản dịch.
  • màn hình bất động sản: hãy cẩn thận với độ dài khác nhau tùy thuộc vào ngôn ngữ, ví dụ: tiếng Pháp có xu hướng tiết kiệm hơn tiếng Anh.
  • trừ khi bạn thành thạo một ngôn ngữ nhất định, bạn sẽ không thể đánh giá sự khác biệt.
+1

Cảm ơn - những điều này rất hữu ích. Vì hầu hết các chuỗi có văn bản gợi ý giải thích được liên kết với chúng và những văn bản đó cần phải được dịch, tôi đã nghĩ đến việc cung cấp chúng trong các cột được ghép nối của bảng tính. Une pierre, deux coups, n'est-ce pas? – Argalatyr

2

Tôi đã sử dụng TsiLang Translation Suite để cho phép người dùng cuối dịch. Tôi đã sửa đổi mã để cho phép mã hóa để nếu ai đó thực sự làm tốt công việc họ có thể bảo vệ tên của họ đối với một tệp dịch, nhưng nói chung ý tưởng là mọi người có thể chia sẻ bản dịch của họ và thêm/chỉnh sửa bất kỳ phần nào họ muốn. Cho rằng tất cả xảy ra trong ứng dụng và với khả năng hiển thị tức thì, nó hoạt động thực sự độc đáo.

2

Như bạn đã đề cập, D2009 đi kèm với các công cụ bản địa hóa. Tại sao không chỉ đơn giản là sử dụng chúng? AFAIK bạn có thể phân phối trình quản lý dịch bên ngoài (etm.exe). Bạn có cần gì nữa không?

Ngoài ra, bản địa hóa không chỉ là dịch văn bản. ETM cũng hỗ trợ dịch các tài nguyên .dfm.

+0

Tôi rất muốn xem những gì người khác nghĩ về điều này. Tôi bị cám dỗ bởi các công cụ D2009. Có một số điểm tuyệt vời liên quan đến dxgettext, nhưng sẽ hữu ích khi nghe từ những người đã thử cả hai. – Argalatyr

+0

@Argalatyr: Tôi đã thử ETM và IMHO đơn giản là khủng khiếp. Tôi sẽ không bao giờ đưa nó cho một lập trình viên phi dịch thuật cho các mục đích dịch thuật, các chuỗi dịch có thể bị chết đuối bởi tất cả các thuộc tính (không phải chuỗi thậm chí) mà nó hiển thị. Điều gì xảy ra nếu một số người có ý nghĩa tốt dịch alClient sang alKlient? Giao diện người dùng cũng không tốt cho việc dịch các mục đích, nó hướng đến quản lý dự án nhiều hơn là chỉnh sửa văn bản. Không phải mọi thứ đều tốt vì nó có trong hộp Delphi. – mghie

+0

@TOndrej: Điều chỉnh tất cả các DFM cho mục đích dịch thuật chỉ cần thiết vì VCL không có cách bố trí điều khiển động phù hợp với độ rộng văn bản thay đổi. Điều này đặt gánh nặng lên nhà phát triển/dịch giả, khi mã sẽ có thể tự xử lý nó. – mghie

1

Để hoàn chỉnh, dưới đây là một công cụ bản địa hóa Delphi khác được gọi là Delphi Localizer Gần đây tôi đã tìm thấy thiết kế đó được thiết kế và đánh bóng tốt. Công cụ này miễn phí cho mục đích thương mại ngoại trừ các dự án của Chính phủ (không chắc chắn lý do tại sao ngoại lệ).

FWIW Tôi đã sử dụng TsiLang Translation Suite trong quá khứ và hiện đang làm việc trên một dự án khác bằng cách sử dụng các công cụ bản địa hóa được cung cấp với DevExpress VCL. Sau đó tích hợp độc đáo với các thành phần của họ cũng như các thành phần của bên thứ ba.

+0

không tương thích với delphi 2009, xấu hổ, nhìn tốt và dễ sử dụng dxGetText – none