Tôi đã viết tài liệu này để giúp đỡ bạn tránh làm nhiều lỗi mà tôi đã làm khi bắt đầu dịch.
Mỗi phần có dấu là Mẹo Địch!
Một người thật sự có khéo léo thì trọng công cụ mình. Rất may mán là hiện thời chúng ta có một số công cụ địa phương hóa tốt lắm. Để dịch một tập tin .po, bạn cần phải có:
Bộ trình công cụ thông dịch gettext được sử dụng trên khắp thế giới để địa phương hóa phần mềm. Bạn có thể kiểm tra xem có phiên bàn gettext nào bằng gõ vào thiết bị cuối:
gettext --v'
Hiện thời có:
gettext (GNU gettext) 0.14.3'
nhưng mà vì mục nhập này sẽ trở thành cũ hơn, bạn hãy kiểm tra phiên bàn mới nhất là gì. Nếu bạn có một phiên bản cũ, hay không có phiên bản nào, bạn hãy cài đặt phiên bản gettext mới nhất. Fink không luôn liệt kê phiên bản mới nhất, thì hãy kiểm tra thông tin tại địa chỉ ấy:
http://ftp.gnu.org/gnu/gettext/
và tải phiên bản mới nhất xuống đó, rồi cài đặt nó.
tài liệu hướng dẫn gettext: completing gettext installation: cài đặt xong gettext
Có thể sử dụng bất cứ trình hiệu chỉnh văn bản nào.
bạn có thể đơn giản hóa công việc nhiều bằng cách sử dụng một trình hiệu chỉnh .po chuyên dụng. Hiện thời có:
đã làm nhiều việc quan trọng để giúp đỡ chúng ta. Thì cũng có công bố:
Ba điều đầu công bố trong wiki này, hay từ Dự án Translate tại Sourceforge.
Dùng po4a và Translate Toolkit, có thể chuyển đổi gần bất cứ khuôn dạng nào sang hay từ khuôn dạng .po, có lẽ gồm dạng hữu cơ...
Cũng xem nhiều phần khác của wiki này, để tìm tiềm năng khóa và thông tin hữu ích về nhiều khía cạnh của khác nhau của công việc thông dịch. Người dịch có nhiều kinh nghiệm đã mất lâu khi đóng góp cùng wiki này, để tiết kiệm thời gian và tránh sự khó cho chúng ta. Mọi ý kiến hay kinh nghiệm về thông dịch, vui lòng thêm vào wiki này mà tiềm năng dùng chung của chúng ta.
Chúng ta thử tìm hiểu xem công việc thông dịch nhé....
Một tập tin PO (Portable Object: đối tượng có thể mang) là một định dạng được tạo dành cho hành động cần thiết của chúng ta: lấy thông tin và di chuyển nó sang nơi khác. Bạn có thể dùng mọi trình biên soạn văn bản, lập gần mọi bộ ký tự (dù UTF-8 là an toàn nhất vì lý do khác), ngay cả cho con chó ăn nó, và nó sẽ vẫn còn kết thức chính xác là cùng điều trước ... một tập tin văn bản: chỉ chữ thôi.
Sự khác duy nhất giữa tập tin văn bản thường và tập tin .po là khối dòng đầu và cấu trúc của khối chuỗi. Trước bạn đóng góp một tập tin dịch xong, cần phải kiểm tra xem không có lỗi nào còn lại, gồm lỗi về cấu trúc này. Hơn nữa, khi bạn đóng góp tập tin .po cùng Dự án Thông dịch thì trình rô-bốt sẽ kiểm tra lại tập tin, và nó thử ra các dòng đầu một cách chính xác, thì hữu ích để biết cách lập cho đúng. Như thế thì sẽ tránh cần phải đóng góp lại tập tin ấy, và tránh rô-bốt từ chối nó với sự sửa -- mà có thể làm bực tức một chút.
Đây là một khối dòng đầu chưa lập:
# SOME DESCRIPTIVE TITLE. # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER # This file is distributed under the same license as the PACKAGE package. # FIRST AUTHOR <EMAIL@ADDRESS>, YEAR. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "POT-Creation-Date: 2003-07-24 09:35+0200\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" "Language-Team: LANGUAGE <LL@li.org>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=CHARSET\n" "Content-Transfer-Encoding: 8bit\n"
Bình thường, bạn sẽ gặp một khối hoàn thành chưa lập, như khối này, trong một tập tin chưa dịch chuỗi nào cả, một tập tin PO Template (mẫu) có phần mở rộng .pot
Rất dễ dàng để chuyển đổi tập tin .pot sang .po! Chỉ đơn giản điền đầy đủ khối dòng đầu, và thay đổi phần mở rộng thành .po. Xong rồi.
Khi bạn cập nhật một tập tin đã dịch một cách bộ phận, hay tập tin đã dịch cũ, thì có lẽ sẽ gặp một số dòng đầu vẫn còn chưa lập, hay quá hạn.
Vậy luôn luôn cần phải kiểm tra khối dòng đầu: hãy làm việc này trước hết, hãy làm nó sau hết (trước đệ trình tập tin dịch xong) thì bạn sẽ tránh sự khó.
Có hai dòng đầu có lẽ không xuất hiện trong khối ấy, nhưng mà tốt hơn nếu có. Bạn có thể tự thêm hai dòng ấy:
"Report-Msgid-Bugs-To: \n"
và
"Plural-Forms: nplurals=INTEGER; plural=EXPRESSION\n"
thế ở dưới đây chúng ta có một khối dòng đầu hoàn thành (hãy ghi chú vị trí của hai dòng đầu thêm):
# SOME DESCRIPTIVE TITLE. # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER # This file is distributed under the same license as the PACKAGE package. # FIRST AUTHOR <EMAIL@ADDRESS>, YEAR. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2003-07-24 09:35+0200\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" "Language-Team: LANGUAGE <LL@li.org>\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=CHARSET\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=INTEGER; plural=EXPRESSION\n"
Mỗi dòng đầu làm một việc có ích, vì vậy chúng ta sẽ xem từng dòng:
# SOME DESCRIPTIVE TITLE.
cung cấp thông tin nhanh về tên của gói phần mềm này. Ở đây thì bạn hãy gõ tên của chương trình (không phải số phiên bản). Trong lời thí dụ bên dưới, tôi sẽ sử dụng chương trình Tuxpaint (một chương trình vẽ/sơn rất tốt cho đứa bé) và ngôn ngữ tôi, Việt ngữ.
# Vietnamese translation of TuxPaint.
Ghi chú rằng mọi dòng đầu này có một dấu thăng # và một dấu cách trước thông tin ấy. Trình kiểm tra, gồm rô-bốt, chỉ chấp nhận dấu đúng, vì hai dấu này là tin hiệu gettext của dòng đầu thông tin. Trình gettext thật phân tách thông tin này, và toàn tập tin. Như thế thì, khi chúng ta bảo đảm định dạng là đúng, sẽ không phải mất thời gian sửa lỗi khi trình gettext không phân tách được tập tin ấy.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
Trong trường hợp gói nào tại Dự án Thông dịch thì phần mềm thường là phần mềm nguồn mở, phần mềm tự do. Cho phần mềm loại này, thông tin thường là (dùng năm này):
# Copyright © 2005 Free Software Foundation, Inc.
Nếu bạn có truy cập được ký hiệu bản quyền © một cách hơi dễ dàng trong bố trị bàn phím hay tính năng gõ ký tự đặc biệt, khi gõ nó thì hình như nghề nghiệp hơn.
Đôi khi gặp một tập tin có dòng đầu bản quyền sở hữu: một người nào đó đã tạo, và có quyền yêu sách tập tin ấy (lấy thí dụ):
# Copyright © 2001-2005 Nguyễn Thị Hoa.
Trong trường hợp ấy thì bạn phải theo dòng đầu đã có. Đừng sửa đổi nó.
Nếu tập tin của bạn có phải có dòng đầu bản quyền sở hữu, và trình rô-bốt từ chối nó vì không có dòng đầu bản quyền Tổ chức Phần mềm Tự do, như thế thì bản chỉ đơn giản hãy viết thư điện tử cho người điều hợp của Dự án Thông dịch tại:
translation AT iro d0t umontreal d0t ca1)
vì vấn đề ấy thuộc về dự án, không phải thuộc về bạn, dù đôi khi chúng ta có cảm thấy phật lòng khi tập tin mình bị từ chối vì có lỗi không phải của mình. Điều hợp viên cần phải lập một tùy chọn cho mỗi tập tin loại ấy, để tránh rô-bố từ chối nó khi bạn, hay người dịch khác, đệ trình nó lần kế tiếp. Hơn nữa, mỗi lúc chúng ta có thể đóng góp thời gian hay kinh nghiệm, chúng ta giúp nhau.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
Dòng đầu này có chưa lập chỉ nếu bạn là người thứ nhất để dịch tập tin ấy. Nếu nó đã được dịch, ngay cả bộ phận, trước đó, thì sẽ có ở đây tên của mỗi người dịch trước, trên từng dòng. Vậy nếu chỉ có một người dịch (tôi sẽ sử dụng tên mình):
# Clytie Siddall <clytie@máy_chủ_nào.net.au>, 2005.
Tuy nhiên, nếu đã có người dịch trước, sẽ có nhiều dòng đầu người dịch. Lấy thí dụ:
# pclouds <pmây@máy_chủ_khác.com>, 2002. # Tran Minh Thanh <tmt@yahhooo.com>, 2004. # Clytie Siddall <clytie@máy_chủ_nào.net.au>, 2005.
Vậy về lý thuyết, tập tin có thể chứa rất nhiều dòng đầu loại này, riêng từng, nhưng mà trong thực hành, thường gặp một đến năm dòng đầu.
Đừng sửa đổi dòng đầu người dịch trước nào, chỉ hãy chèn dòng đầu mình bên dưới dòng đầu người dịch trước mới nhất. Những dòng đầu người dịch này bảo đảm mọi người đã cố dịch tập tin này thì cả hai được thừa nhận, và nhận trách nhiệm làm cộng việc của mình.
#
Có lẽ bạn xem một dòng đầu rỗng giữa hai phần khối đầu tập tin. Nó cho bạn đọc khối này một cách dễ hơn. Bạn không cần làm gì ở đây.
#, fuzzy
Hãy ghi chú rằng tại đầu dòng này, có một dấu phẩy sau dấu thăng #. Hai dấu này đều ngú ý là trình gettext đọc dòng đầu này như là thông tin về các khối chuỗi trong tập tin ấy. Nếu tập tin có dòng đầu này thì vẫn còn chứa chuỗi chưa dịch hay/và chuỗi có lỗi trong nó. Trình biên soạn .po có lẽ sẽ tự động loại bỏ nó một khi bạn đã dịch xong tập tin ấy, hoặc nếu bạn đang sử dụng một trình biên soạn văn bản thường mà không phải được thiết kế để quản lý những dòng đầu .po, thì bạn có thể tự loại bỏ nó. Chỉ xóa bỏ toàn dòng. Xong rồi.
Chuỗi mờ là chuỗi chưa dịch hay không đúng. Trình gettext quyết định đánh dấu ấy ở đâu, đựa vào (lấy thí dụ) nếu mọi dấu nháy kép, mọi biến và mọi ký tự ngắt dòng trong mỗi chuỗi của cặp thì khớp với nhau hay không. Nó sé cũng quyết định nó bằng cách kiểm tra nếu chuỗi từ điển nào do trình msgmerge đệ nghị thì khớp chuỗi gốc hay không. Mỗi chuỗi mờ có dấu mờ: cần phải kiểm tra nó một cách cẩn thận. Có thông tin thêm về tiến trình ấy xuống trang này.
Tài liệu hướng dẫn gettext: fuzzy strings: chuỗi mờ
msgid "" msgstr ""
Cặp chuỗi rỗng này ngụ ý cho trình gettext, tôi giả sử, cấu trúc của các chuỗi trong tập tin ấy. Chuỗi msgid (MeSsaGe ID: mã nhận diện thông điệp) là đoạn trong ngôn ngữ gốc, còn chuỗi msgstr (MeSsaGeS TRanslated) là bản dịch.
Tập tin xuất thì phải chứa mỗi cặp chuỗi, “được bao bằng dấu nháy kép”. Đừng sửa đổi dòng đầu này.
"Project-Id-Version: PACKAGE VERSION\n"
Ở đây, phiên bản gói có phải là quan trọng: cần phải theo dõi dòng đầu này khi cập nhật tập tin nào.
Trình rô-bốt của Dự án Thông dịch cần thiết tên của chương trình và phiên bản có định giới bằng một dấu cách, không phải bằng một dấu gạch dưới hay dấu gạch nối. Trong cách ấy, dòng đầu này khác với tên tập tin gốc.
Tên tập tin gốc: tuxpaint-2.1pre
"Project-Id-Version: Tuxpaint 2.1pre\n"
Hãy nhớ để sửa đổi dòng đầu này mọi khi cập nhật tập tin nào
Bạn nên sử dụng tất cả thông tin trong phần phiên bản của tên tập tin: 0.03a2, 2.01b, 0-03.2pre2, có phải là thông tin có ích về giai đoạn phát triển của gói này.
Nếu bạn đang sử dụng chương trình nào đã dịch mình, hãy nhớ để kiểm tra phiên bản và thông tin tại nơi Mạng của nó, để quyết định nếu trình ấy ổn định chưa. Nếu bạn chọn giúp đỡ thử nghiệm một chương trình nào đó, hay lắm! với điều kiện là bạn không ngờ nó có ổn định hoàn thành hay cung cấp sự hỗ trợ kỹ thuật. Còn những lập trình viên và người khác đóng góp cùng với bạn bằng cách thử nghiệm, có phải sẽ vui lòng thỏa luận chương trình ấy và hỗ trợ nhau trong hộp thư chung của trình ấy.
"Report-Msgid-Bugs-To: \n"
Bình thường, lập trình viên bỏ sót hay không điền vào dòng đầu này, mà làm phiền chúng ta, vì nó là địa chỉ liên lạc để sử dụng khi một chuỗi ngôn ngữ gốc là không đúng (thiếu dấu, thiếu từ, cú pháp hay gõ/chính tả sai), hoặc khi chúng ta chưa hiểu một chuỗi nào đó đủ khá để dịch nó.
Có mất thời gian nhiều nếu chúng ta cần phải trở về trang nhóm chúng ta tại Dự án Thông dịch, nhắp vào tên tập tin ấy để đi tới miền văn bản của nó (trang dành cho nó tại dự án ấy), rồi tìm kiếm trang chủ của chương trình, hoặc thông tin liên lạc khác nào. Thường cần phải Google trong một thời gian để tìm nó.
Khi bạn tìm được địa chỉ liên lạc ấy, vui lòng điền nó vào tập tin của bạn. Vậy người kế tiếp, có thể bạn , sẽ không cần phải mất thời gian để tìm kiếm nó. Ý kiến tốt là đệ nghị lập trình viên điền vào dòng đầu này.
Đã tìm biết một số điều hữu ích về địa chỉ thông báo:
bug-TÊN_GÓI@gnu(chấm)org
owner(a-còng)bugs(chấm)debian(chấm)org
có tên tập tin là chủ đề, và thận thư bắt đầu với:
Package: TÊN_TẬP_TIN Version: SỐ_PHIÊN_BẢN Severity: wishlist Tags: l10n, patch
"POT-Creation-Date: 2004-07-24 09:35+0200\n"
Tập tin .pot là tập tin gốc, chưa dịch, thì ngày ấy là lúc trình gettext tạo phiên bản tập tin này. Tập tin đã cập nhật sẽ có ngày tạo .po.
Thông tin này không quan trọng cho bạn (đừng sửa đổi nó), trừ:
bạn sẽ cần phải kiểm tra xem ngày sửa đổi (ngày khi bạn hiệu chỉnh tập tin này) là sau ngày tạo: nếu không thì trình gettext hay rô-bốt sẽ nói «Không phải!» và đúng vậy. Chúng ta người dịch chưa tìm biết cách đảo ngược thời gian.
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
Dòng đầu này chưa điền trong tập tin .pot gốc, vì chưa sửa đổi (dịch) nó. Trong một tập tin đã cập nhật thì sẽ có một ngày sửa đổi. Chúng ta chỉ cần phải nhớ:
để cập nhật ngày nào trước khi đệ trình tập tin dịch xong
Một trình biên soạn tập tin .po có lẽ sẽ tự động cập nhật ngày nào. Bạn có thể tự làm như thế trong bất cứ giai soạn nào. Trong trình BBEdit (Mac OSX) có thể tạo một mục bản chú giải dùng biến strftime (chỉ hãy lưu nó và sử dụng nó, không cần phải hiểu cách hoặt động):
"PO-Revision-Date: #LOCALTIME %F %R%z#\n"
Mục này, nếu trình hay hệ thống của bạn có thể thay thế giá trị strftime, sẽ hiển thị dòng đầu này đúng cho bạn, tại bất cứ nơi nào trên khắp thế giới. Trong trường hợp tôi, khi viết câu này thì xem:
"PO-Revision-Date: 2005-05-25 16:08+0930\n"
Hãy ghi chú thứ tự ngày ấy: năm-tháng-ngày, năm có bốn số tự, tháng có hai số và ngày cũng có hai số. Thì cần phải gồm số không đi trước khi số ấy nhỏ hơn số mười, như trong tháng hiện có: 05 (tháng năm).
Ghi chú số hiệu giờ thế giới. Nó nói là múi giờ tôi (thành phố Adelaide tại Úc, thời gian Trung Úc, không phải thời gian Mùa Hè) là 9.5 giờ, chín giờ nửa, sau giờ thế giợi (GMT hay UTC: 00:00).
Nếu bạn không có trình như BBEdit có thể thay thế giá trị strftime cho bạn thì cần phải nhớ để điền múi giờ mình ở đây. Cần phải nhớ để gõ số không đi trước nếu, như trong trường hợp tôi, chỗ bạn nhỏ hơn mười giờ sau hay trước UTC.
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
Khi bạn là người dịch duy nhất thì tên bạn sẽ xuất hiện cả hai trong dòng đầu Người Dịch Thứ Nhất, và đây trong dòng đầu Người Dịch Cuối Cùng, mà có lẽ sẽ làm cho bạn cảm thấy như là Người Dịch Có Thể Duy Nhất.
Bạn chỉ hãy điền tên và địa chỉ thư vào đây, lần nữa, nhưng mà đừng gồm năm, như trong dòng đâù Người Dịch Thứ Nhất, vì Ngày sửa đổi .po có cung cấp nó.
Nếu có tên của người dịch trước điền vào đây, bạn cần phải sửa đổi nó để hiển thị tên bạn. Hãy chắc chắn có tên người dịch trước ấy trong phần thứ nhất của khối đầu (người dịch thứ nhất, thứ hai, thứ ba v.v.).
Vậy trong trường hợp tôi, dòng đầu này sẽ hiển thị”
"Last-Translator: Clytie Siddall <clytie@máy_chủ_nào.net.au>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
Ở đây có nơi công nhận nhóm ngôn ngữ bạn cho các sứ cố gắng của họ. Nó cũng cung cấp một địa chỉ liên lạc thêm cho người nào viết cho bạn về bản dịch. Nó thật có ích khi địa chỉ thư điện tử trở thành cũ, khi người nào dụ lịch hay thay đổi chi tiết.
Nhóm ngôn ngữ của bạn sẽ là tên của ngôn ngữ, và đôi khi của dự án. Địa chỉ sẽ thường là hộp thư chung nhóm. Vậy trong trường hợp tôi, dòng đầu này là:
"Language-Team: Vietnamese <gnomevi-list@lists.máy_chủ_đó.net>\n"
hay
"Language-Team: Gnome-Vi <gnomevi-list@lists.máy_chủ_đó.net>\n"
"MIME-Version: 1.0\n"
Để tìm lời nghĩa của nhiều từ cấu tạo và kỹ thuật Mạng, bạn thăm gia trang tôi nhé: Những từ cấu tạo bằng chữ đầu của những từ khác thường nhất của Mạng . Tôi sẽ cố cập nhật nó một cách đều đặn.
Dòng đầu phiên bản MIME thường đã điền vào rồi. Bạn không cần làm gì. Hay quá, phải không?
"Content-Type: text/plain; charset=CHARSET\n"
Đây thật sự là quan trọng. Dòng đầu này lập bộ ký tự cho ngôn ngữ bạn. UTF-8 (Unicode: mã hoàn thành) là tùy chọn tốt nhất, nhưng mà nếu ngôn ngữ bạn cần thiết bộ ký tự khác, hãy điền nó vào đây. Cho ngôn ngữ tôi:
"Content-Type: text/plain; charset=UTF-8\n"
Unicode là tuyệt vời! Dễ hơn rất nhiều để có thể quên về các mã chữ khó quá cũ ấy ... Lúc này chỉ cần mọi hệ điều hành hỗ trợ Unicode một cách tốt hơn.
"Content-Transfer-Encoding: 8bit\n"
Dòng đầu này cũng nên đã điền vào rồi. Nếu chưa, bạn hãy gõ 8bit, cách mã hóa có thể quản lý UTF-8 và bộ ký tự phức tạp khác trong khi truyền. Bạn không muốn bản dịch đã làm việc nhiều của tôi sẽ bị hỏng trong khi đệ trình nó, hoặc khi nó được gởi cho lập trình viên.
"Plural-Forms: nplurals=INTEGER; plural=EXPRESSION\n"
Thường dòng đầu này không có trong khối đầu tập tin, nhưng mà nên gồm nó. Khi bạn gặp chuỗi số nhiều (plural: diễn tả nhiều người hay điều) thì dòng đầu số nhiều này bảo đảm có số trường đúng cần gõ chuỗi đã dịch. Số này biến thay từ một ngôn ngữ đến ngôn ngữ khác. Cho ngôn ngữ tôi:
"Plural-Forms: nplurals=1; plural=0\n"
vì Việt ngữ không có hình dạng số nhiều về ý nghĩa đó. Một quyển, hai quyển. Nhưng mà bạn nên xem tập hợp đại từ...
Một số ngôn ngữ có vài hình dạng số nhiều. Một chuỗi gốc (msgid) số nhiều hình như đây:
msgid "Found and replaced %d occurrence." msgid_plural "Found and replaced %d occurrences."
vì Anh ngữ, ngôn ngữ gốc trong tập tin này, có phải có hình dạng số nhiều về ý nghĩa này. Nếu ngôn ngữ bạn hành vi cùng với Anh ngữ thì bạn sẽ gặp hai trường msgstr để gõ, như dưới:
msgid "Found and replaced %d occurrence." msgid_plural "Found and replaced %d occurrences." msgstr[0] "" msgstr[1] ""
nhưng mà trong trường hợp tôi, nó nên là:
msgid "Found and replaced %d occurrence." msgid_plural "Found and replaced %d occurrences." msgstr[0] "Đã tìm được và thay thế %d lần"
Nếu dòng đầu số nhiều trong tập tin bạn được lập cho đúng thì bạn sẽ gặp trường gõ bản dịch (msgstr) số đúng và kiểu đúng. Vậy nó hữu ích lắm.
Bạn hãy hỏi người chủ nhóm về dòng đầu số nhiều đúng cho ngôn ngữ bạn, rồi điền nó vào khối đầu của mọi tập tin .po: nó sẽ tiết kiệm thời gian và tránh sự khó cho bạn.
Cũng có thể thỏa thuận thiết kê số nhiều, và bất cứ điều về dịch nào, trong hộp thư chung Dự án Thông dịch, một nơi rất tốt để hỏi câu và chia kinh nghiệm.
Các dòng đầu ấy là tất cả cần điền. Hết rồi. Mọi dòng đầu này có tiết kiệm thời gian khi địa phương hóa một ứng dụng nào đó. Bạn có thể lập chúng trong trình biên soạn .po, hoặc chỉ đơn giản lưu một bản sao của chúng để dán trên khối dòng đầu cũ hay gốc.
Khi bạn cố điền các dòng đầu này cho đúng, và tìm biết cách mình để quản lý chúng, bạn trở thành một người dịch tốt hơn, vì người thông mình làm việc thì sử dụng công cụ một cách tốt nhất. Định dạng .po là một công cụ của chúng ta.
tài liệu hướng dẫn gettext:
filling in the header entry: điền vào mục nhập đầu
Trang nhóm 2) của bạn tại TP sẽ liệt kê các tập tin sẵn sàng dịch. Bạn cần phải hỏi người chủ nhóm nên dịch tập tin nào, hay xin dịch một tập tin nào đó, thì họ sẽ thông báo điều hợp viên TP là bạn được gán cho những tập tin ấy.
Thì trở thành một người dịch tại TP như thế nào?
Bạn hãy đăng ký với TP. Phương pháp đơn giản, dù gồm một bước có lẽ làm cho trễ: đơn từ chối trách nhiệm (disclaimer).
Họ sẽ thông báo điều hợp viên là bạn muốn gia nhập dự án ấy, hoặc họ có thể cho phép bạn làm như thế dưới tên họ, nhưng mà quan trọng là bạn làm một phần nhóm ấy, thì người chủ nhóm phải cấp quyền bạn gia nhập.
Nhóm ngôn ngữ có thể hỗ trợ với nhau, giúp nhau, và đảm bảo mọi người làm công việc thông dịch thì cung cấp chất lượng bền bỉ. Làm cho lẫn lộn, và rất ít hữu ích hơn khi có nhiều người dịch một cách riêng sang cùng một ngôn ngữ, không phải liên lạc với nhau, không hợp tác với nhau. TP cần đến mọi thay đổi do người chủ nhóm thực hiện, nên không xung đột với gỉ, không làm cho lẫn lộn về ai làm gì, thế nào và tại sao.
Liên lạc với người chủ nhóm bạn, họ sẽ giúp đỡ bạn nhiều; tham dự hộp thư chung nhóm ấy, và gia nhập Dự án Thông dịch (TP).
(bạn với quyền người chủ nhóm, hoạc thông qua người chủ nhóm), sau đó bạn cần phải điền đầy đủ đơn từ chối trách nhiệm (disclaimer form), ký tên trên nó, rồi fax (điện thư) hay gửi nó qua bữu điện, cho Tổ chức Phần mềm Tự do (Free Software Foundation: FSF).
Nếu bạn gặp khó khăn hiểu thông tin ấy, hoặc đệ trình đơn từ chối trách nhiệm, thì người chủ nhóm sẽ giúp đỡ bạn.
Bạn cũng có thể in đơn ấy, ký nó, quét nó và gửi nó qua thư điện tử. Cách này hay cách khác, đơn từ chối trách nhiệm ấy phải tới FSF, và có được ghi lưu dưới họ tên bạn. Một khi đã làm như thế, họ tên bạn trong trang nhóm ngôn ngữ mình sẽ hiển thị:
Disclaimer | |
Họ tên bạn | Yes |
(Đơn từ chối trách nhiệm: Có)
Đơn từ chối trách nhiệm là quan trọng vì nó đơn giản hóa các vấn đề quyền tác giả. Lập trình viên không muốn gặp vấn đề loại ấy, thì phần lớn lập trình viên sẽ không cho phép bạn dịch tập tin họ cho đến đơn từ chối trách nhiệm bạn được xử lý. Khi bạn đi tới trang miền thuộc văn bàn (textual domain) của một tập tin nào đó (bằng cách nhắp vào liên kết nó trong trang nhóm bạn), hãy kiểm tra xem xuống trang ấy nếu cần đến đơn từ chối trách nhiệm, hay không.
Phần lớn tập tin cần đến nó, nhưng mà trong khi bạn đợi đơn ấy tới FSF và được xử lý, còn có một số tập tin tại TP không cần đến nó. Bạn có thể dịch chúng trong khi đợi. ;-D
Những tập tin trong danh sách tại trang nhóm bạn nên là những tập tin mới nhất. Lập trình viên gửi tập tin đã cập nhật cho TP để được dịch, và nên tự động gửi nó, mỗi lần cập nhật. Rất quan trọng là bạn sẽ dịch tập tin mới nhất, tập tin hiện thời (current file). Nếu không thì có lẽ không có lập trình viên hay người dùng sẽ sử dụng bản dịch của bạn, hoặc chỉ có ít người sử dụng nó. Tải tập tin xuống trang nhóm bạn tại TP nên đảm bảo bạn nhận tập tin mới nhất, «hiện thời nhất».
Nếu bạn gặp một tập tin nào đó không phải là tập tin hiện thời (rất ít khi gặp, nhưng mà có thể) thì bạn hãy gửi thư cho điều hợp viên TP để cho phép họ sửa nó.
Phương pháp thiết lập và bảo quản «sự hiện thời» bao gồm CVS, SVN và kho riêng. TP cho phép bạn tránh phải học biết nhiều cách khác quản lý hệ thống phiên bản, bằng cách bảo quản công bố những tập tin mới nhất. Bạn chỉ đơn giản hãy tải tập tin xuống trang nhóm mình tại TP. Nhắp vào tên tập tin sẽ mang bạn sang tập tin miền thuộc văn bản của nó. Hãy nhắp vào liên kết có tên tập tin: nó tải về đĩa cứng của bạn nhanh lắm. Bạn có một tập tin cần dịch!
Nếu bạn đã hỏi TP gửi cho bạn tập tin nào cập nhật tập tin đã gán cho bạn, thì mỗi tập tin đã cập nhật sẽ đơn giản đến vào Hộp Đến của bạn. Bạn không cần tải nó về.
Cập nhật tập tin dịch thường là cộng việc nhanh, vậy hữu ích khi tập tin ấy tự động đến vào. Một tập tin nào đó có thể được tải lên TP với vài chuỗi mới hay chuỗi đã sửa đổi, rồi nó được gửi cho người dịch, mà hiệu chỉnh nó và gửi trả nó, cùng trong một ngày. Đó là «sự hiện thời».
Dự án khác có hướng dẫn sở hữu về cách lấy tập tin hiện thời: bạn hãy hỏi người chủ nhóm.
Bạn sẽ bắt đầu từ số không: không có ai đã hiệu chỉnh tập tin này trước bạn.
như nói trên.
Có tin tức tốt: bạn sẽ không phải tự gõ mỗi chuỗi riêng vào tập tin mới ấy, nếu bạn có tập tin trích yếu (compendium) nào. Một bản trích yếu là một bản chú giải do trình gettext tạo. Người chủ nhóm bạn có thể chỉ đường cho bạn đến chỗ nào chứa một số bản chú giải hiện thời, có bất cứ dạng nào, dù chúng ta cần có bản trích yếu (compendium) để thực hiện tiến trình dòng lệnh bên dưới đây.
Tốt nhất để sử dụng cùng những bản chú giải với các nhóm bạn, vì quan trọng là tự vừng hợp nhất. Thì không làm cho người dùng lẫn lộn, cho họ ít kỹ thuật mới hơn để quản lý. Khi bạn bắt đầu sử dụng máy tính, hoặc khi bất đầu sử dụng một chương trình mới (chúng ta luôn luôn học biết điều mới) thì không hữu ích khi phải lo lăng về nhiều cách khác nói cùng một điều.
Một bản trích yếu (compendium) là một tập tin văn bản do trình gettext xây dụng, bằng cách hợp nhất nội dung của nhiều tập tin .po dịch xong. Có lẽ bạn sẽ muốn giữ nhiều bản trích yếu khác cho loại tập tin khác: tôi có n bản trích yếu riêng cho (lấy thí dụ) tập tin của chương trình chính, trò chơi, tập tin ISO và chương trình tính toán. Bạn có thể áp dụng nhiều bản trích yếu khác vào cùng một tập tin .pot hay .po.
Khi bạn áp dụng một bản trích yếu vào một tập tin mới (được gọi là khởi động tập tin ấy) thì trình gettext cố khớp những chuỗi gốc với chuỗi và bản dịch được ghi vào bản trích yếu. Khi gặp khớp chính xác thì gettext sẽ điền đầy đủ msgstr (chuỗi đã dịch) hoàn thành cho bạn. Khi khớp gần đúng 3), thì nó điền đầy đủ chuỗi đã dịch, nhưng mà cũng áp dụng thẻ mờ (fuzzy) vào khối chuỗi ấy. Thẻ mờ ấy có nghĩa là «Xin kiểm tra xem lại chuỗi này: tôi chưa chắc về nó.» Dù nếu trình gettext không thể dịch xong toàn chuỗi ấy, có lẽ nó sẽ tiết kiệm thời gian cho bạn: có lẽ chỉ cần phải sửa đổi một chữ hoa hay dấu chấm câu, hay một phần câu ấy ... hoặc có lẽ nó hoàn thành không đúng, nhưng thường nó gần đúng thì giúp đỡ người dịch nhiều.
Làm đó thế nào? Đây là lệnh riêng (hãy ghi lưu nó tại chỗ hữu ích):
msgmerge --compendium compendium.po -o tập_tin.po /dev/null tập_tin.pot
Lệnh này nói:
Chương trình msgmerge (chương trình hợp nhất của bộ trình gettext), hãy dùng thông tin trong một tập tin trích yếu tên (trong trường hợp này) compendium.po (có thể là bất cứ gì.po nào), rồi xuất (-o) các dữ liệu đã kết hợp từ tập tin trích yếu và tập tin cần dịch vào một tập tin khác tên tập_tin.po, tại /dev/null (vì bạn không muốn dữ liệu đã kết hợp: bạn chỉ muốn dữ liệu khớp: /dev/null giống như nói Bỏ đi, và tập tin cần khởi động có tên tập_tin.pot.
Vậy lệnh có thể là:
msgmerge --compendium bản_chú_giải.po -o tập_tin.po /dev/null gnubiff.pot
Các phần lệnh ấy:
msgmerge - chương trình sẽ làm việc ấy
--compendium - tùy chọn nói «tạo một tập tin chú giải từ các dữ liệu này»
bản_chú_giải.po - tên tập tin của bản chú giải đã có, hay tên tập tin đã muốn cho một tập tin mới
-o - _xuất_ các dữ liệu từ hai tập tin đã kết hợp
tập_tin.po - vào tập tin này
/dev/null - rồi bỏ nó, vì tôi không muốn hai tập tin được kết hợp
gnubiff.pot - nhưng mà, hãy chèn chuỗi khớp nào vào tập tin này (tập tin cần dịch)
Vậy bạn chỉ cần gõ tên tập tin chú giải, bản trích yếu, trong chỗ compendium.po, và gõ tên của tập tin cần dịch, trong chỗ gnubiff.pot.
Hãy ghi nhớ là đường dẫn, thư mục nào mà chương trình msgmerge phải dịch vụ qua để tìm một tập tin nào đó, cũng là một phần tên tập tin ấy. Hai tập tin trong lời thí dụ ở trên có lẽ là:
Tài_liệu/bản_chú_giải/bản1.po
and
Tài_liệu/TP/gnubiff-2.1.3/gnubiff.pot
Khi gõ tên tập tin trong thiết bị cuối, hãy sử dụng phím Tab để hoàn thành các chữ còn lại trong tên ấy, một khi đã gõ chữ nào khớp tên khác nào trong cùng thư mục ấy.
Dùng lệnh msgmerge này có lẽ sẽ khớp nhiều chuỗi, hay không: phụ thuộc vào bao nhiêu dữ liệu trong bản trích yếu có liên quan đến tập tin mới ấy. Bạn có liệt kê nhiều bản trích yếu, nếu bạn muốn áp dụng nhiều bản:
msgmerge --compendium bản1.po bản2.po bảnA.po -o tập_tin.po /dev/null gnubiff.pot
Nhất là, khi bạn dịch nhiều tập tin làm công việc tương tự, hoặc bạn quyết định lần kế tiếp có người nào muốn bạn dịch cái nút «OK», lúc ấy bạn sẽ kêu thét lên và ném cái, chương trình msgmerge có thể cho phép bạn tránh nhiều sự khó. Nó là một công cụ khác trong bộ của chúng tôi. (Toàn công việc thông dịch đã phục táp trước có bộ trình gettext.)
Ban đầu hãy cập nhật khối đầu, như được hiển thị ở trên. Khi cập nhật thì những vùng khóa là số phiên bản, chi tiết về người dịch và ngày sửa đổi.
Bạn cũng có thể sử dụng lệnh msgmerge ấy với một tập tin dịch một phần. Như thế thì nó sẽ đơn giản cố khớp chuỗi nào chưa dịch.
Trước khi chúng ta bắt đầu hiệu chỉnh tập tin mình, có một số từ tiết kiệm thời gian, về xây dụng bản trích yếu mình.
Tạo tập tin chú giải mình, tập tin trích yếu mình, là một tiến trình đơn giản, mà một số trình hiệu chỉnh .po có sẵn. Trong trình LocFactoryEditor, lấy thí dụ, tôi có thể tạo, hợp nhất và áp dụng bất cứ số bản chú giải nào trong nhiều khuôn dạng khác nhau (tôi thường sử dụng .tmx).
Khi sử dụng dòng lệnh, bạn vấn còn có thể làm như thế bằng cách này, mỗi khi dịch xong một tập tin nào đó và muốn thêm các bản dịch của nó vào một tập tin trích yếu:
msgcat -o tríchyếu.po tập_tin1.po tập_tin2.po
Lệnh này nói: chương trình msgcat (chương trình phân loại của bộ trình gettext), chèn các dữ liệu xuất (-o) cộng việc này vào một tập tin tên tríchyếu.po. (nếu đã có tập tin tên này tại chỗ ấy thì sẽ hợp nhất với nó: hữu ích để cập nhật bản trích yếu). Lấy mọi dữ liệu từ những tập tin này: tập_tin1.po và tập_tin2.po
vậy có thể:
msgcat -o chúgiảiA.po gnubiff.po
nếu bạn chỉ đang thêm một tập tin vào chúgiảiA, hoặc
msgcat -o chúgiải_bé.po tuxpaint.po gcompris.po
nếu bạn đang thêm hai tập tin ấy vào bản trích yếu loại chương trình em bé của bạn.
Tiến trình bản trích yếu tiết kiệm rất nhiều thời gian cho chúng ta: vui lòng mất ít thời gian để sử dụng nó. Bạn có thể xin người khác giúp đỡ, hay hỏi câu, vào bất cứ lúc nào tại Hập thư chung TƯ, như nói trên.
Tôi đã ghi lưu hai lệnh ấy tại một chỗ hữu ích, thì mỗi lúc cần chúng, tôi có thể tìm chúng. Nếu bạn sử dụng chúng nhiều lần, có lẽ sẽ còn lại trong trí nhớ bạn. Không có nhiều còn lại trong trí nhớ tôi hiện thời ... có lẽ nó bị rò.
tài liệu hướng dẫn gettext:
invoking the msgmerge program: gọi chương trình msgmerge
using translation compendia: sử dụng bản trích yếu thông dịch
Bạn đã sửa đổi khối đầ, bạn đã sử dụng bản trích yếu để cung cấp chuỗi liên quan nào, và lúc nào bạn tự hỏi lập trình viên đã gồm chuỗi lạ nào -- ừm, lúc cần dịch.
Tập tin .po, trừ khối đầu, chứa chỉ nhiều khối chuỗi. Mỗi khối chuỗi tiêu biểu một chuỗi sẽ được hiển thị có dạng đã dịch trong chương trình mà trình gettext đã tạo ra tập tin .po từ nó. Có lẽ chuỗi này sẽ là chữ trên cái nút, trên thanh công cụ, trong thông điệp lỗi hay trong cửa sổ mẹo: dù việc nào nó làm trong chương trình, trong tập tin .po nó là một khối chuỗi. Tôi có khối chuỗi, bạn có khối chuỗi, mọi người có khối chuỗi!
Đây là cấu trúc khối chuỗi:
#.Type: boolean #.Description #:../exim4-base.templates.master:4 msgid "Remove undelivered mails in spool directory?" msgstr ""
Khối chuỗi này (từ dự án dịch bản cài đặt Debian) có cấu trúc thật tốt. Hãy ghi chú hai dòng #. Dấu băm và dấu chấm ngụ ý:
#.Tôi là một chú thích lập trình viên. :)
Lập trình viên có thể cho chúng ta tránh nhiều sự khó bằng cách chèn chú thích giải thích chuỗi ấy, hay hướng dẫn cách định dạng nó. Hậu hết tập tin .po chưa có chú thích lập trình viên, thì chuỗi này là đặc biệt. Bạn đệ nghị lập trình viên chèn chú thích, cũng với dòng đầu Report-Msgid-Bugs-To nhé.
Đây là một lời thí dụ chú thích lập trình viên rất cao cả, cũng từ dự án dịch bản cài đặt Debian:
#.Type: select #.Choices #.Translators beware! the following six strings form a single #.Choices menu. - Every one of these strings has to fit in a standard #.80 characters console, as the fancy screen setup takes up some space #.try to keep below ~71 characters. #.DO NOT USE commas (,) in Choices translations otherwise #.this will break the choices shown to users #:../exim4-config.templates.master:9 msgid "internet site; mail is sent and received directly using SMTP" msgstr ""
Hướng dẫn loại ấy là hữu ích lắm.
Trở về lời thí dụ thứ nhất, mà vẫn còn diễn tả chuỗi ấy nhiều khá hơn tài liệu .po thường:
#.Type: boolean #.Description #:../exim4-base.templates.master:4 msgid "Remove undelivered mails in spool directory?" msgstr ""
Hai dòng đầu chú thích lập trình viên có cho bạn biết:
Dòng kế tiếp diễn tả công việc của chuỗi này trong chương trình đích. Đôi khi dòng loại này có thể giúp đỡ chúng ta hiểu công việc của chuỗi này, nhưng mà không phải thường.
Về chú thích, chúng ta người dịch cũng có thể chèn chú thích.
# Tôi là một chú thích người dịch. ;)
Rất hữu ích khi nhiều người dịch cùng một tập tin.
Trong bất cứ trường hợp nào, trong tương lai người dịch có thể khác cập nhật tập tin này, thì hữu ích để chèn một chú thích nếu cần ghi nhớ gì. Phải chèn chú thích người dịch tại đỉnh khối chuỗi, sau khoảng cách («cách trắng») từ khối chuỗi trước: hãy xem toàn dòng trước mỗi chú thích người dịch được trích dẫn tại đây. Chú thịch người dịch có dấu băm # rồi một dấu cách: không có dấu chấm câu nào. Vì vậy, tôi đã chèn chú thích như:
# Don't translate this: it's a variable. Đừng dịch chuỗi này vì là biến.
trong khối chuỗi như:
# Don't translate this: it's a variable. Đừng dịch chuỗi này vì là biến. #. login window data #:../exim4-base.templates.master:4 msgid "(${NAME})" msgstr "(${NAME})"
hoặc bạn có thể đệ nghị một cách diển tả hay định dạng nào đó. Đừng cảm thấy nhút nhát về chèn chú thích người dịch: người dùng chương trình không có thấy nó. Bạn có lẻ sẽ tự hỏi nếu một số lập trình viên biết là trường chú thích của họ là dành cho nói về chúng ta: một số tập tin .po chứa chỉ chú thích lập trình viên nói chuyện với nhau trong những lập trình viên, ngay cả lăng mạ người dùng. Không tốt.
Trong khi bạn dịch mỗi khối chuỗi từ từ, đừng cảm thấy nên biết mọi điều.
Một số chuỗi (có lẽ nhiều chuỗi) sẽ làm cho lẫn lộn, ngảy cả là rất khó hiểu: nhiều lập trình viên không có những tài năng diễn tả tốt, kể cả trong ngôn ngữ sở hữu. Mọi ý kiến về tiến bộ cấu trúc, trong khi tạo chuỗi đã dịch, hãy bao gồm: hãy diễn tả chuỗi này bằng cách tốt nhất, cách dễ nhất hiểu cho cộng đồng ngôn ngữ bạn.
Mức đích không phải là dịch từ ấy hay kỹ thuật ấy, nhưng mà sự nghĩa của nó.
Nhất là vì từ và kỹ thuật loại máy tính được chọn vì ngắn. Từ như «icon» và «text» không phải có thường dụng trong tiếng Anh trước thời gian của máy tính cá nhân. Bạn cũng có thể chọn một từ ngắn hay cụm từ ngắn để vừa sự nghĩa đúng. Lấy thí dụ, từ «icon» bằng tiếng Việt là «biểu tượng» mà dài hơn nhiều. Khi khoảng cách là quan trọng, trong mục trình đơn hay trên cái nút, tôi sử dụng một từ cho «picture»: «hình» hay «ảnh», vì hai từ này gần cùng kích thước với từ gốc «icon» và trong ngữ cảnh ấy, có thể mang sự nghĩa thích hợp. Tự vựng máy tính có lớn hơn và có phát triển trong mọi ngôn ngữ: bạn có dịp giúp đỡ tạo và lọc nó cho cộng đồng ngôn ngữ mình.
Rất có thể là cộng đồng bạn sẽ có một dự án chú giải hiện thời cho kỹ thuật máy tính, mà bạn có thể đệ nghị, tìm và thảo luận những kỹ thuật thích hợp. Cho Việt ngữ, nó tại: đây.
Ý kiến bạn là quan trọng: mức đích là liên lạc với người dùng một cách hữu ích, không phải để phản ánh một cách chính xác người dùng làm gì trong tiếng Anh.
Công việc này đầy đủ thách thức nếu văn hóa bạn khác nhiều với văn hóa người nói tiếng Anh, thì hãy lấy dịp nghĩ cẩn thận về mức đích của mỗi chuỗi, và cách tốt nhất để liên lạc nó với cộng đồng ngôn ngữ của mình.
Lấy thí dụ, trong tiếng Việt, chúng ta hiển thị nhần mạnh bằng cách chọn những từ thích hợp, hơn dùng dấu chấm than. Dấu trích dấn gây trở ngại cho sự nghĩa, vì chúng ta sử dụng rất nhiều dấu phụ, thì tôi sử dụng «dấu trích dẫn Pháp» thay thế. Cách nói bằng tiếng Anh từ máy tính cho người dùng gần luôn không đúng cho tiếng Việt: tôi cần phải tìm cách thích hợp để diễn đạt sự nghĩa của chuỗi ấy. Lấy thí dụ:
msgid "Choosing a simple root password is a really dumb idea." ("Chọn một mật khẩu đơn giản cho người dùng chủ là một ý kiến ngớ ngẩn lắm.")
từ máy tính cho người dùng không phải thích hợp trong tiếng Việt, lăng mạ. Vậy câu tôi bằng tiếng Việt giống như:
msgstr "Không phải ý kiến tốt để chọn một mật khẩu đơn giản cho người dùng chủ."
vì kiểu dạng ấy nhiều mạnh bằng tiếng Việt hơn bằng tiếng Anh, thật đủ mạnh để được sự chú ý của người dùng tại mức độ thích hợp.
Hãy ghi chú: dù lập trình viên có lẽ là nhà chuyên môn về chương trình ấy hoạt động thế nào, bạn và các người bạn nhóm là người hiểu ngôn ngữ mình và văn hóa mình, thì bạn cần phải chọn cách diễn đạt sự nghĩa, và chọn cách nói với người dùng một cách thích hợp nhất.
#~ msgid "I am an obsolete string. Nobody loves me. Boo-hoo. :(" #~ msgstr "Tôi là một chuỗi cũ. Không có ai thương tôi. Hu-hu. :("
Chuỗi bắt đầu với dấu băm # và dấu sóng ~ là chuỗi cũ...
#~ msgid "Forward _Quoted" #~ msgstr "Chuyển tiếp _trích dẫn"
Một số tập tin sẽ có nhiều chuỗi tại kết thức tập tin, mà cặp chuỗi msgid và msgstr bắt đầu với dấu băm, và thường cũng với dấu sóng (mà ngụ ý thư mục chính của người dùng trên đĩa cứng bạn. Nó không có nghĩa ấy tại đây.)
Trong tập tin .po, chuỗi nào bắt đầu với #~ do chương trình gốc không còn dùng lại.
Vậy sao giữ hết? Thật vậy, tôi tự hỏi... Hình như có ý kíến là trong tương lai có lẽ sẽ dùng lại các chuỗi ấy, thì không cho phép bạn xóa bỏ chúng, và phải dịch chúng. Tuy nhiên, bạn có thể quyết định sẽ mất bao nhiều sức mạnh dịch một số chuỗi cũ. Thật có lỗi trong tiến trình ấy: tôi đá gặp tập tin gần toàn chuỗi cũ à. Một tập tin GNOME có 25 000 dòng, và chỉ 18% là chuỗi hoạt động. Lạ quá.
Trình hiệu chỉnh của bạn có lẽ sẽ giữ các chuỗi cũ ra: trình LocFactoryEditor sẽ chỉ hiển thị chuỗi ấy cho tôi nếu nó có dấu mờ, hoặc nếu tôi báo nó.
the gettext manual: obsolete strings: chuỗi cũ
Để tiết kiệm thời gian gỡ lỗi trong tập tin này lần sau, bạn cần nhớ vài điều trong khi dịch.
Không bao giờ hiệu chỉnh chuỗi gốc, msgid.
Thông tin này thuộc về chương trình gốc thì nếu bạn sửa đổi nó bằng bất cứ cách nào, dù một dấu cách hay di chuyển một từ lên hay xuống một dòng, sẽ gây ra lỗi khi tập tin .po được hợp nhất lại vào chương trình gốc.
Nếu bạn gặp lỗi nào trong chuỗi gốc (msgid), hãy thông báo cho lập trình viên.
Bạn có thể thông báo lỗi dùng địa chỉ Report-Msgid-Bugs-To trong khối đầu, hoặc (nếu không có) hãy đi tới miền thuộc văn bản cho tập tin này (trang TP mà bạn tải tập tin này xuống nó) và theo những liên kết để tìm một địa chỉ liên hệ thật. Một khi đã tìm nó, vui lòng điền nó vào dòng đầu Report-Msgid-Bugs-To, để không có người dịch trong tương lai, gồm bạn, sẽ phải mất thời gian tìm kiếm nó lần nữa.
Hãy ghi nhớ: khi bạn gửi thư cho lập trình viên, hãy lễ phép và thân thiện. Dễ quá để nôn nóng, khi bạn đang làm sạch tập tin hỗn độn số n, nhưng mà hãy ghi nhớ rằng những người này cũng đóng góp thời gian mình, và có lẽ không có khéo léo tiếng Anh nhiều, hoặc hiểu tiến trình gettext hoạt động thế nào. Kết bạn: có dịp hay lắm.
Mỗi chuỗi phải “bắt đầu và kết thức với một dấu trích dẫn đôi”.
#: ../gedit/gedit-document.c:1964 msgid "" "The disk where you are trying to save the file has a limitation on file " "sizes. Please try saving a smaller file or saving it to a disk that does " "not have this limitation."
Hiện thời, kiểu dạng này bị phải đối, thì dù bạn không bao giờ hãy hiệu chỉnh chuỗi gốc (msgid), bạn có thể định dạng bản dịch (msgstr) có kiểu dạng hiện có: một dấu trích dẫn đôi tại đầu và cuối. Vậy trong tập tin tôi:
#: ../gedit/gedit-document.c:1964 msgid "" "The disk where you are trying to save the file has a limitation on file " "sizes. Please try saving a smaller file or saving it to a disk that does " "not have this limitation." msgstr "Đĩa được dùng để lưu tập tin có giới hạn về kích thước tập tin. Hãy lưu một tập tin nhỏ hơn hoặc lưu tập tin này vào đĩa không đặt ra giới hạn trên."
Theo như tôi có thể tìm biết, bạn có thể loại bỏ những dấu trích dẫn thêm chỉ khi không có một dấu ngắt dòng có thể thấy (\n). Khi có ký tự \n thì phải cho dấu trích dẫn đôi còn lại tại đầu và cuỗi mỗi dòng trong chuỗi ấy, giống như trong chuỗi gốc.
# Do not translate the upper-case quoted terms: they are values for the configuration. Đừng dịch kỹ thuật đã trích dẫn bằng chữ hoa vì là giá trị cho cấu hình. #: ../data/gedit.schemas.in.h:77 msgid "" "Style for the toolbar buttons. Possible values are \"GEDIT_TOOLBAR_SYSTEM\"\n" "to use the system's default style, \"GEDIT_TOOLBAR_ICONS\" to display icons\n" "only, \"GEDIT_TOOLBAR_ICONS_AND_TEXT\" to display both icons and text, and\n" "\"GEDIT_TOOLBAR_ICONS_BOTH_HORIZ\" to display prioritized text beside icons.\n" "Note that the values are case-sensitive, so make sure they appear exactly as\n" "mentioned here." msgstr "Kiểu dáng cho nút thanh công cụ. Giá trị có thể là \"GEDIT_TOOLBAR_SYSTEM\"\n" "cho kiểu mặc định của hệ thống, \"GEDIT_TOOLBAR_ICONS\" nếu chỉ hiện thị các\n" "biểu tượng, \"GEDIT_TOOLBAR_ICONS_AND_TEXT\" nếu hiện cả biểu tượng và chữ.\n" "Và \"GEDIT_TOOLBAR_ICONS_BOTH_HORIZ\" để hiển thị chữ ưu tiên cạnh biểu\n" "tượng. Chú ý là phải viết hoa các giá trị để đảm bảo chúng được hiển thị\n" "đúng như đã nói."
mà hình như nhiều xe đi mua hàng có va vào nhau.
Nếu chuỗi gốc dùng ký tự ngắt dòng (\n) thì chuỗi dịch cũng phải dùng.
Không có nghĩa là bạn phải giữ cùng số dòng: bạn có thể dùng nhiều hay ít dòng hơn chuỗi gốc. Tuy nhiên, nếu dòng nào trong bản dịch có dài hơn chỗ ngắt dòng trong chuỗi gốc, tại điểm ấy cần phải dùng ký tự ngắt dòng. Có một số lời thí dụ:
#: ../data/gedit.schemas.in.h:74 msgid "" "Specifies the number of spaces that should be displayed instead of Tab\n" "characters." msgstr "Xác định số khoảng trắng được hiển thị thay vì ký tự Tab."
Bản dịch này là đúng, vì nó ngắn hơn thì không cần ngắt dòng.
#: ../data/gedit.schemas.in.h:74 msgid "" "Specifies the number of spaces that should be displayed instead of Tab\n" "characters." msgstr "Xác định số khoảng trắng được hiển thị thay vì ký tự Tab, và một số từ thêm nữa không cần thiết."
Bản dịch này không đúng, vì tôi có phải ngắt dòng đầu, như chuỗi gốc, nhưng mà chưa dùng ký tự \n theo nó.
Thì chuỗi này là đúng:
#: ../data/gedit.schemas.in.h:74 msgid "" "Specifies the number of spaces that should be displayed instead of Tab\n" "characters." msgstr "Xác định số khoảng trắng được hiển thị thay vì ký tự Tab, và một\n số từ thêm nữa không cần thiết."
kể cả chuỗi này:
#: ../data/gedit.schemas.in.h:74 msgid "" "Specifies the number of spaces that should be displayed instead of Tab\n" "characters." msgstr "Xác định số khoảng trắng được hiển thị thay vì ký tự Tab, và một\n số từ thêm nữa không cần thiết. Hơn nữa, tôi có thể nói chuyện bằng cách\n này được mấy ngày."
Kết quả, bản dịch, phải có cùng một bố trí với chuỗi gốc (msgid). Nếu msgid cần ngắt dòng tại một điểm nào đó (khoảng), thì bạn hãy theo, cho bất cứ số dòng nào.
Bạn đã thấy sổ chéo ngược \ được dùng trong ký tự ngắt dòng. Đây là một ký tự đặc biệt trong tập tin .po (và trong nhiều loại tập tin khác). \n ngụ ý ngắt dòng.
Trong tập tin .po, cách dùng \ thường khác và để thoát dấu trích dẫn.
Như bạn đã thấy biết, dấu trích dấn có một công việc đặc biệt trong khối chuỗi. Chúng nói, Chuỗi msgid hay msgstr bất đầu tại “đây, và kết thức tại đó.” Vậy khi trình phân tách gettext kiểm tra qua tập tin .po ấy, nó biết không thể đọc là lệnh, nội dung giữa hai dấu trích dẫn ấy. Nó có thể nghỉ cho đến khi gặp dấu trích dẫn kế tiếp, mà nó phải làm việc lại.
Đúng vậy, nhưng mà nếu chuỗi ấy chứa một dấu trích dẫn, có làm gì vậy? Ối ... chúng ta thử tìm hiểu xem nhé:
#:../src/window-commands.c:162 msgid "See the "Quick Help" for a list of commands." msgstr ""
Ở đây, sẽ gặp gì đấy? Này, chúng ta biết là trình phân tách sẽ xử lý dấu trích dấn thứ hai là kết thức chuỗi. Cũng hơi tốt. Sau đó, nó sẽ cố đọc các dữ liệu sau đó là lệnh ... cho đến nó gặp một dấu trích dấn nữa, mà nó sẽ nghĩ là đầu một chuỗi khác. Ồ, lộn xộn lắm. Bạn có thể hiểu là khi quên một dấu trích dẫn hay chèn một điều thêm thì có thể gặp nhiều lỗi.
Máy là chúng ta có thể thoát trường hợp này, bằng cách dùng sổ chéo ngược có ích. Sổ chéo ngược báo trình phân tách bỏ qua công việc thường của những dấu trích dẫn ấy. Vậy chúng ta có chuỗi này:
#:../src/window-commands.c:162 msgid "See the \"Quick Help\" for a list of commands." msgstr ""
Nó hình như hơi lạ, nhưng mà chỉ có một sổ chéo ngược thoát mỗi dấu trích dẫn thêm. Bạn chỉ cần nhớ làm như thế mỗi khi dùng một dấu trích dấn trong chuỗi dịch. Tuy nhiên, bạn có lẽ dùng «dấu trích dẫn này», cùng với ngôn ngữ tôi, và dấu này không có công việc đặc biệt trong tập tin .po, thì không cần thoát chúng. Xong rồi.
Tổng số và loại biến trong cả hai chuỗi phải khớp.
Trong tập tin .po, biến thường có dạng strftime và printf, nhưng mà lời hướng dẫn chung tốt là bất cứ điều nào không phải là một từ thường thì rất có thể là một biến. Đừng sửa đổi biến nào, vì nó là điều giữ chỗ cho chương trình gốc: lấy thí dụ, lập trình viên đã báo chương trình để thay thế biến %s trong chuỗi c:219 bằng tên người dùng của người dùng hiện thời. Như thế thì chuỗi trong tập tin .po:
#: src/gbiff2.c:219 #, c-format msgid "Welcome to gnubiff, %s!\n"
khi do chương trình dùng, sẽ hiển thị:
Welcome to gnubiff, Clytie!
nếu nó là tên người dùng của tôi trong hệ thống ấy.
Vậy đơn giản dịch nó, với biến tại ví trị ấy, có lẽ đúng:
#: src/gbiff2.c:219 #, c-format msgid "Welcome to gnubiff, %s!\n" msgstr "Chúc mừng vào gnubiff, %s!\n"
Hãy ghi nhớ là chuỗi này ngắt dòng, dù nó hơi ngắn. Sẽ có lý do hiển thị vì dùng ký tự ngắt dòng này, thì chúng ta đơn giản theo.
Dù chúng tôi có thể theo những từ trong chuỗi ấy, cũng biến ấy...
Bạn sẽ tạo một bản dịch có chất lượng nhiều cao hơn nếu bạn mật thời gian để nghĩ về mức đích của chuỗi ấy trong chương trình gốc.
Có thể gặp khó khăn làm như thế khi không có chú thích lập trình viên diễn tả chuỗi. Tuy nhiên, trong chuỗi loại này, bạn sẽ thấy biết là chương trình thường nói với người dùng bằng cách thuyết hình người như thế. Bạn cần phải quyết định nếu hành vi này thích hợp với văn hóa mình hay không.
Trong trường hợp này, trong ngôn ngữ tôi là thích hợp hơn để loại bỏ dấu than, chọn động từ «dùng» thay vào «vào» (ngầm), và chèn tên người dùng trước động từ ngầm ấy:
#: src/gbiff2.c:219 #, c-format msgid "Welcome to gnubiff, %s!\n" msgstr "Chúc mừng %s dùng gnubiff.\n"
Chúc mừng Clytie dùng gnubiff.
Bạn có thể thay đổi ví trị của biến, như tôi tại đây, với điều kiện là bạn không thay đổi thứ tự của nhưng biến. Một số chuỗi có nhiều biến: một chuỗi có thể nói:
#: src/gbiff2.c:219 #, c-format msgid "Welcome to %s, %s!\n"
và báo chương trình thay thế tên phần chương trình hiện thời trước, rồi tên người dùng của người dùng hiện thời sau.
Welcome to gnubiff configuration widget, Clytie!
Tuy nhiên, như nói trên, trong tiếng Việt tôi cần chèn biến tên người dùng sau «Welcome to (using)», tôi sẽ thay đổi thứ tự biến:
#: src/gbiff2.c:219 #, c-format msgid "Welcome to %s, %s!\n" msgstr "Chúc mừng %s dùng %s.\n"
Chúc mừng gnubiff configuration widget dùng Clytie.
Vậy tôi cần ngụ ý cách thay đổi thứ tự:
#: src/gbiff2.c:219 #, c-format msgid "Welcome to %s, %s!\n" msgstr "Chúc mừng %2$s dùng %1$s.\n"
bằng cách chèn 2$ (mà nói «biến thứ hai») và 1$ («biến thứ nhất») giữa % và s của mỗi biến. Chuỗi trên báo chương trình là biến %2$s có lẽ đi trước trong chuỗi, nhưng mà nó thật là biến thứ hai trong chương trình gốc. Còn %1%s có lẽ đi sau, nhưng mà nó được nhận diện là biến thứ nhất. Vậy chương trình gốc có thể thay thế những giá trị hiện thời để hiển thị tôi:
Chào mừng Clytie dùng gnubiff configuration widget.
_ |
---|
Vì vậy, hãy bảo quản cùng tổng số, hình thức chính xác và thứ tự biến với chuỗi gốc. Nếu bạn cần thay đổi thứ tự thì hãy sử dụng phương pháp trên.
Nếu bạn thiếu điều nào trong những quy tắc này, hay nhầm hai điều bằng bất cứ cách nào, đừng lo lăng, vì khi bạn dịch xong tập tin ấy (hay vào bất cứ lúc nào), bạn có thể kiểm tra gặp lỗi thường nào, dùng lệnh này:
msgfmt -cv /dev/null TÊN_TẬP_TIN
Lệnh này nói: chương trình msgfmt, kiểm tra (-c) những quy tắc ngôn ngữ (xuất (-o) các kết quả vào /dev/null vì tôi không muốn lưu một bản sao) trong tập tin này.
Trình msgfmt sẽ liệt kê lỗi còn lại nào, với số thứ tự dỏng và mô tả, để cho phép bạn sửa hết. Nó sẽ cho bạn biết nếu có mục nhập mờ (fuzzy) còn lại, và lỗi loại nào có. Trình msgfmt là hữu ích lắm.
Khi tôi chạy lệnh kiểm tra ấy với tập tin mà tôi hiện thời dịch:
Pearl:~/gnome/HEAD clytie$ msgfmt -cv gedit/po/vi.po
Hãy ghi chú là tôi hiện thời tại mức độ mà hai mức dưới thư mục chính của tôi, ở trong danh mục HEAD mà ở trong danh mục gnome; tôi cũng cần phải báo trình msgfmt rằng tập tin vi.po tại mức độ mà hai mức dưới ví trị tôi (có trong danh mục po mà ở trong danh mục gedit). Bạn có hiểu chưa? Mong muốn có. Đây là kết quả lệnh ấy:
Pearl:~/gnome/HEAD clytie$ msgfmt -cv gedit/po/vi.po gedit/po/vi.po:504: parse error gedit/po/vi.po:643: missing `msgstr' section gedit/po/vi.po:644: keyword "t" unknown gedit/po/vi.po:1385: keyword "C" unknown gedit/po/vi.po:1386: keyword "C" unknown gedit/po/vi.po:1402: keyword "C" unknown gedit/po/vi.po:1403: keyword "C" unknown gedit/po/vi.po:1409: keyword "C" unknown gedit/po/vi.po:1468: missing `msgstr' section gedit/po/vi.po:1469: keyword "n" unknown gedit/po/vi.po:1483: missing `msgstr' section gedit/po/vi.po:1484: keyword "ang" unknown found 12 fatal errors
«Fatal errors» (lỗi nghiêm trọng) không phải thật giết người, ngưng mà lỗi loại ấy sẽ ngăn cản tập tin bạn được chấp nhận là hoàn thành. Dễ dàng để tìm những lỗi này: kinh nghiệm cho tôi biết là rất có thể thiếu một số dấu trích dấn. Đó là lý do trình phân tách có cố đọc chuỗi là lệnh, và không hiểu từ khóa (keyword), từ đầu trong chuỗi ấy, cho trình phân tách ấy.
(Toàn bộ trình gettext mới công bố trong tiếng Việt, thì bạn có thể xem các thông điệp lỗi này bằng tiếng mình. Tuy nhiên, thông điệp này phục táp trong tiếng Anh, thì có lẽ bản dịch sẽ không dễ hiểu. Bộ trình gettext công bố bằng nhiều ngôn ngữ khác từ TP.)
Bạn có thể kiểm tra tập tin dịch nhiều lần (phím mũi tên lên sẽ lặp lại lệnh trước) cho đến khi được kết quả như:
msgfmt -cv dasher/po/vi.po 133 translated messages.
(133 thông điệp đã dịch.)
Lúc ấy bạn có thể đệ trình tập tin bạn.
Để đệ trình một tập tin dịch xong ((hãy xem người chủ nhóm về tập tin nào bạn không thể dịch xong) thì bạn chỉ đơn giản hãy gửi nó cho chương trình rô-bốt tại TP trong thư điện tử.
Hãy đảm bảo lệnh kiểm tra msgfmt ở trên có kết quả sạch, không có lỗi, trước khi gửi tập tin.
Hãy đảm bảo chi tiết trong dòng chủ đề của thư là đúng: nếu không thì sẽ không chấp nhận tập tin bạn.
Hãy đảm bảo đã thay đổi tên của tập tin thành mã_ngôn_ngữ.po, trong trường hợp tôi, vi.po.
Ghi chú: bạn có lẽ sẽ muốn giữ toàn tên tập tin (trong trường hợp tôi, và cho tập tin gnubiff-2.3pre1) gnubiff-2.3pre1.vi.po, để tránh nhầm nhiều tập tin cùng tên. Một sự phòng ngừa hữu ích nữa là gzip tập tin bạn trước đính nó kèm thư, để ngăn cản cách mã hóa bị hỏng trong khi truyền.
Địa chỉ thư khi đệ trình tập tin:
<translation ở iro chấm umontreal chấm ca>
Dòng chủ đề của thư:
TP Robot TÊN_GÓI.MÃ_NGÔN_NGỮ.po
Lấy thí dụ, cho gnubiff bằng tiếng Việt:
TP Robot gnubiff-2.1.3.vi.po
Hãy đảm bảo tên gói tin là đúng: chèn một dấu gạch nối giữa tên chương trình và số phiên bản, và chèn dấu chấm trong số phiên bản.
Hãy đảm bảo có một dấu chấm giữa số phiên bản và mã ngôn ngữ, và một dấu chấm nữa giữa mã ngôn ngữ và phần mở rộng po.
Tôi đã tạo một mẫu trong chương trình thư, thì mỗi lúc tôi cần đệ trình một tập tin, thì tôi chỉ cần phải điền chi tiết gói vào dòng chủ đề. Mẫu này cho tôi tránh làm lỗi trong thông tin khác, vì dễ để quên một dấu cách hay một dấu chấm. Cho trình thư tôi Mail trong Mac OSX, tôi sử dụng Mail Template, một chương trình tốt lấm tiết kiệm thời gian và tránh sự khó khi cần gửi nhiều thư tương tự, kể cả trả lời bằng một cách nào đó.
gettext 0.14.3: the tutorial
Có nhiều thông tin hữu ích trong wiki này: vui lòng thấy biết nhé. :)
Bạn có thể đóng góp thông tin và kinh nghiệm vào wiki này vào bất cứ lúc nào. Chỉ cần phải đăng ký, và bắt đầu!
Tôi không thể dịch toàn wiki, nhưng mà nếu bạn gặp khó khăn hiểu một phần nào đó, hãy gửi thư cho tôi và tôi sẽ cố dịch cho bạn.
Chúc bạn dịch vui vẻ nhé.
Clytie