GNOMEアプリケーションの地域化
そんなにGNOMEを翻訳したいですか?
Contents
はじめに
GNOMEのプログラムは、地域化できることを意図して書かれています。これは、(物理的に)異なる場所で異なった振るまいをするようにプログラムを増強できることを意味します: アメリカで印刷される紙は、ヨーロッパで印刷される紙とはサイズが異なります; 気温は、場所に応じて華氏や摂氏という単位で表示されます; そして、ユーザが見るプログラムの言語は、ユーザの母国語である可能性があります。
翻訳は、この地域化の手順において主要な部分です。GNOMEの翻訳の過半数は、ボランティアベースでネイティブスピーカたちによって行われています。彼らは、オリジナルの英語の文に適切な翻訳を提供し、この情報を含んだファイルをGNOME Git リポジトリに追加します。それによってソフトウェアの次のリリースに新しい言語が含まれます。
このドキュメントは、GNOMEの翻訳手順に関与する方法について説明しようとしています。
あなたのチームの検索
まず最初に既にあなたの言語で誰かが作業していないか?です。もしそうならば、彼らはGNOME翻訳プロジェクトのチーム一覧に記載されているでしょう。最初の一歩は、彼らに連絡することです。あなたは、利用可能な言語の一覧も見てみたいかもしれません。
地域化したい言語のチームを見つけたにも関わらず彼らから返事がない場合、GNOME国際化メーリングリストに連絡してください。誰かが、何をすればよいか助言してくれるでしょう。
もし、あなたの言語のチームがない場合も先ほどのメーリングリストに連絡してください。その場合には、その言語のコーディネータとなるよう招待されるでしょう。
活発なチームと接触することに成功した場合、おそらく次の節を飛ばし、『翻訳』という節に移動できます。
チームの創設
あなたの言語のチームがなければ、潔くチームを開始しそのコーディネータを買ってでませんか?天晴れです!
コーディネータの役割
チームのコーディネータとして、チームの主要な担当者としてチームの他の翻訳者を組織する責任があります。これは、複数の翻訳者が同時に同じファイルの翻訳を試みることを未然に防止することを含みます。
コーディネータは、GNOME国際化メーリングリスト(gnome-18n)に参加する必要があります。これは、すべてのGNOME翻訳者に強く推奨される事ですが、コーディネータには必須です。
もし、チームの何人かのメンバーがGitのアクセス権を持っていてもそれはあなたになるでしょう。アカウントが適格になる前に最初にいくつかの翻訳に貢献する必要がありますが。詳しくは、アカウントの要求をご覧ください。 もし、あなたがGitのアクセス権を持っていないならば、各チームメンバーがあなたに翻訳を送り、それらをGitのアクセス権を持った誰かに転送し、その誰かがそれらをコミットするでしょう。これは、すべての正しい翻訳がふさわしい人に適時に渡るようにします。なるべくなら、GNOME's Bugzilla bug tracking systemにて"l10n"プロダクト("l10n"は"localization"という用語の略語です)のあなたの言語のコンポーネントに対し、バグレポートを作成してこれを行ってください。そして、このバグレポートに翻訳を添付してください。それから、このバグレポートに誰かを指名して、その翻訳をコミットするように頼んでください。
当初、少なくともあなたのチームに属するバグは、あなたの宛名に来ます。(あなたの翻訳が使われるようになるまでに多くのバグを受け止る可能性はありません。)前述のようにあなたの言語は、Bugzillaでそれ自身のコンポーネントを有しています。翻訳のバグは、"l10n"プロダクトに対して提出されるでしょう。アイディアを得るためにGNOME BugzillaにあるL10Nの概要ページをご覧ください。
しばしば、コーディネータは、LINGUASファイルの更新やPOTファイルの生成といった翻訳作業のより技術的な局面に対処することが予想されます。(そのすべてを後述しようと思います。)
あなたの翻訳チームにより多くのメンバーを募集することにも関わるでしょう。それは、あなたのより多くの作業を意味するかもしれませんが、多くの手が翻訳を早めます。
適切な時にコーディネータを辞める事もコーディネータとしての責任です: 例えば、コーディネータに値する努力を捧げる時間がもはやない時です。もし、調整役を実行できないことが分かったならば、あらかじめ代わりをするよう誰かに頼んでください。GNOME国際化メーリングリスト(gnome-18n)にコーディネータの変更をアナウンスするようお願いします。
言語コード
始めるにあたって、あなたの言語のコードを見つけ出す必要があるでしょう。これは、2ないし3文字のコードです。多くの一般的な言語は2文字のコードを持つ傾向があり、一方、多くの名もない言語は3文字にはめ込む傾向があります。複数の国で話されている言語において、国を特定する翻訳は、アンダースコアと大文字で2文字の国コードが続きます。アットマークと更なる情報を付け加えることもできます。当面は、国コードは"fr"(フランス語)や"en_GB"(英国で使用されている英語)の様な形式である事を知ってください。
あなたの言語のコードを知らないのであれば、(KDE、Mozilla及びOpenOfficeといった)他のプロジェクトにおいてあなたの言語での翻訳成果がないか探してみてください — 同じコードが使われている(はず)です。何も見つからないのであれば、GNOME国際化メーリングリスト(gnome-18n)に助けを求めてください。
GNOMEは、ISO規格639(言語コード)とISO規格3166(国コード)で定められた標準コードを使用しています。gnome-i18nのメンバーは、あなたの言語のコードを見分ける手伝いをしてくれるでしょう。
あなたの言語のコードは、地域化を識別するために使われています。例えば、ロケールやファイルの名前です。あなたのコードがあれば、翻訳を開始することができます。
開始するのに必要なもの
あなたの翻訳作業に非常に役立つものが多数あります。
メーリングリスト
- できれば、独自の言語でグループが話すことができるフォーラムが必要です。誰が何を翻訳しようとしているか監視したり、難しい単語や用語についての議論することや用語集を打ち出すためにそれを使用することができます。(KDEといった)別のプロジェクトの翻訳チームとメーリングリストを共有するのが適切かもしれません。また、あなたの翻訳についての告知を投稿するための良い場所でもあります。 メーリングリストは、あなたの翻訳のユーザがフィードバッグを与えたり、全般的な議論のために使う場合もあります。
ウェブサイト
- ウェブサイトは、あなたの努力を人々に紹介したり、成果の配布、誰が何をしているかの追跡の維持、用語集のようなものの維持をするのに良いです。
用語集
- あなたの翻訳は、ユーザの混乱を避けるため同じ用語を一貫して使うことが重要です。標準的な用語集は、一つのものを多くの名前で参照しないようにするのを助けます。新しい用語を発明するのではなく、既存の用語を再利用するようにしてください — あなたの言語や他のプロジェクトで使われている翻訳、あるいはMicrosoft WindowsやApple OS Xで使われている専門用語で統一された本文を見てください。特にKDEと言った他のフリーなデスクトップ環境と一致する用語が好ましいです。新しい用語を作成する必要がある場合や他の言葉より敢えて一つの言葉を使用することを決めた場合は、あなたの選択(そしてその背景にある理由)を用語集に記録してください。これは、後の混乱を抑えます。いくつか翻訳した後に最初の用語集の提案をいくらか変更することを予期してください。いったん翻訳を 開始すると問題に気づき始めます。
KDEやMozillaやOpenOfficeを同じ言語に翻訳する人々が同一のチームもあります。その他のチームでは、それぞれのプロジェクト毎に別々のチームがあります。後者の場合、他のチームと連絡を取り、彼らが使用しているものや捨て去っているものを見つけ出すことなどはとても良い考えです。
A good foundation to base your glossary upon is a combination of the GNOME Documentation Project's Style Guide and the glossary found in the gnome-i18n module in GNOME Git, although the latter needs updating.
Another option worth to mention is to use Open-tran.eu in order to look up any existing translations of an english word that you want to translate. This service could also be used to search for inconsistencies in translations.
An IRC channel
This is a benefit for many of the same reasons as a mailing list is, except that it can be more convenient for certain kinds of discussion, especially for quick queries. It can also be good for helping users of your translation. The Freenode network is an IRC network dedicated to free software-related discussion and would be a suitable place for hosting your channel.
The gettext tools
- gettext is a package which contains tools for creating translatable strings, turning those strings into a list which can be translated, updating these strings, and converting them into a format the computer can use. Someone on your team (as many as possible really) needs these and to know the basics of how to use them. The package is installed by default on many Linux distributions. Where it is not installed, it is still usually available. You should also look at intltool. This is rather like a front-end to gettext and performs some tasks you need to do as a GNOME translator. It is often available for your distribution, but it is almost always a release or two ahead of whatever is on your distribution. You can find it in GNOME Git.
翻訳
This is where we get down to it. There are about 44,000 distinct strings which are found in the basic distribution of GNOME 2.26. There are a variety of tactics and methods you can employ, but they all boil down to translating all those strings.
異なるアプローチ
There are different ways of translating. Some teams simple parcel out the “po file” to different people and the members work through them with a text editor and return them to the person who can commit them into GNOME. Other teams use web-based systems. All have advantages and disadvantages.
.po file details are at the end of this page as the longest section. You can jump ahead to the section on .po files if you don't intend to use anything else.
Webインターフェース
A web interface generally provides anyone with a list of strings and waits for them to suggest translations for them. Someone periodically sweeps up all the results and feeds them back into Git. The advantage is that only the team co-ordinator and the maintainer of the web interface need to care about how to make .po files. This lets anyone who doesn't have GNOME, a useful editor, or other things help with the translation. One disadvantage is that without being able to see the rest of the file, contributors may not realise how other people are translating applications. If your team is trying to achieve consistency, this can be a problem. Another is that comments from the developer to translators explaining the string are not always shown.
Existing web interfaces include the following:
Prevod
Kyfieithu
poファイル
There is an excellent document available about how to checkout po/ directories, create .pot files, turn them into .po files, and check them back into Git: How to use GNOME Git as a Translator. You must read this. It explains all the details of using the gettext tools. Since this is 90% of working with .po files, you need to know it. We have not repeated it here. We have simply added a few comments which are in addition to it. They do not replace it.
Note that you can obtain .po files from your language's status pages on the GNOME Translation Project website. (See below). Sometimes special characters (non-ASCII) can be garbled doing this, but it is a useful alternative to Git.
A .po file is simply a list of strings from the original program, with spaces for you to put your version in. There is a set of headers at the top, some of which you will have to edit. The Project-Id-Version will become the name of the module. The POT-Creation-Date should be filled in automatically. You must edit the PO-Revision-Date yourself. Language-Team should be your team's language and ideally an email address which will contact one or more of your members. The Content-Type must be UTF-8 and you must make sure that the resulting file is in fact UTF-8 format. On UNIX and UNIX-like systems, the file command will tell you what format it is in. On a machine with all the gettext facilities installed, you can use msgfmt -cv filename.po. If the file is not UTF-8, msgfmt -cv will produce an error message saying so.
You will meet comments in the file. When they say “c-format”, this means that there are strings which the program will fill in itself. For example, the clock applet in gnome-applets has a string to translate of “%H:%M”. You can “translate” this by pasting it straight in. They will be provided by the system clock on the computer. %H is the hours. %M is the minutes.
There is a separate appendix on common C-format strings.
You will also meet messages to translators from the programmer. For example, in gnome-applets, slightly after the message quoted above you will find the comment “translators: reverse the order of these arguments if the time should come before the date on a clock in your locale”.
You will also have to replace menu accelerators: the keyboard shortcuts which can be used instead of clicking on menus. Expect contradictions and collisions in the early days. It is probably most important to do the accelerators for gtk+ first, since they will be in every single GNOME application. Then you can use the remaining letters and try to work out what combinations work the best. Don't worry if you have two or more menu options with the same accelerator. Since version 2.4, GNOME will let you cycle between them.
You will often come across descriptions for GConf keys. Usually, each key has both a short and a long description. Strings which are key descriptions can be identified by the fact that they come from files with names resembling .schemas.in.h.
When translating key descriptions, be careful with sample key values, which will be enclosed in double quotes. They should not be translated. For example:
#: src/gnome-terminal.schemas.in.h:70 msgid "" "Default color of terminal background, as a color specification (can be HTML-" "style hex digits, or a color name such as \"red\")." msgstr "" "Rhagosodiad lliw cefndir y terfynell, fel penodid lliw (gall fod mewn hecs-" "ddigidau fel yn HTML neu fel enw lliw megis \"red\")."
In the example, “red” is a sample key value, and must be copied verbatim into the translation. Note that because the double quote character is significant in .po files, it is escaped with the backslash.
If you meet English messages which you cannot understand, don't hesitate to file a bug against the application telling the developer of the problem. Please add "L10N" to the "Keywords" field of the bug report form before committing your report. If you meet English messages which you cannot reasonably translate (too complex, not precise enough, etc), file a bug again. Translators as a group file dozens and dozens of these, because translators are the ones who spot them. The earlier you file these the better. When you learn what the message means, you will probably forget about filing the bug. Filing them gets them fixed, and stops other translators having to struggle with the strings.
Don't touch the msgid lines
Do not edit the English strings in the file. If you do that, the programs for merging them into the main application will get confused. Your changes to the English strings will be lost, and your translations may not be incorporated.
変更の処理
Unfortunately, software changes, and that includes changes to the translatable content of the software. Strings get added, strings are changed, and sometimes strings are removed. Fortunately, there are tools and procedures which can help you to keep up with changes to the software you're translating.
The status tables
At the Damned Lies about GNOME website you can get status tables for each language translation in GNOME and for each package. Clicking on Languages gives you a list of all language translations of GNOME. Clicking on any of these shows a page with detailed information on the translation status of each GNOME release and it's corresponding documentation for that language. By clicking on the releases you get a status breakdown by package. These pages for the packages contain links to the latest .pot file and the latest .po file (if a start has been made on the translation). You can download these straight from the status pages instead of using Git. You can't upload them that way, but the download facility is very useful.
And all of this is maintained from version 2.14, and the latest stable release, and for the packages which will become the next stable release. At the time of writing (August 2009), 2.26 was the last stable release and 2.28 is under development.
As soon as translations for your language have been committed to Git, your language will acquire its own section in the status tables. You should probably bookmark the pages relevant to your language. They are very very useful.
Your language page will have a URL of the form http://l10n.gnome.org/languages/XX/gnome-2-26 where XX should be replaced by your language code (lower-case). The above URL is for the upcoming GNOME 2.26. If you want to see the stable release of GNOME, adjust the URL accordingly.
変更されたパッケージの更新
You will generally discover changes when you update your copy of a module in GNOME Git or when you refresh your browser on your status pages. Again, How to use GNOME Git as a Translator is your guide to the necessary Git commands. If you check out the entire module from Git that you want to translate, you can enter the po subdirectory and run intltool-update xx where XX should be replaced by your language code (lower-case). This command will check the entire module for strings and will update your po file to include the latest strings.
Another option: If you know there are more strings to translate, then you need to generate a new .pot file which contains all the strings to translate and then to merge it with your xx.po file which has a less up-to-date set of translated strings. Generate the .pot file with intltool-update --pot. Merge the two together with msgmerge -o new-xx.po xx.po .pot and try very hard to get those in the right order! Then run msgfmt -cv new-xx.po to see how much work remains. If you are lucky, there will be many many “fuzzy” strings: strings which are so similar to already-translated messages that the msgfmt program has suggested that you use the old translation for the new string.
Fuzzy translations are just that
msgmerge gets fuzzy translations wrong from time to time. Every translator has their favourite suggestion which was badly wrong: my (Telsa's) personal favourite is the suggestion that the translation for “Open window” should be used to translate “Close window”...
Go through your new file searching for instances of the string “fuzzy”. If it is in a comment above a translation that looks correct, then remove the word “fuzzy”. If “fuzzy” is the only word on the line, you can safely remove the whole comment. If you do not remove the word “fuzzy” then the translation will not be used. For example:
#, fuzzy msgid "Blah blah blah." msgfmt "La la la."
In this case, if you are confident in the translaton, the line with "fuzzy" in it can be removed entirely:
msgid "Blah blah blah." msgfmt "La la la."
However, you may come across a something like this:
#, c-format, fuzzy msgid "Very important: %s" msgstr "Pwysig iawn: %s"
In this case, if you wish to remove the fuzziness, the "c-format" tag must be left intact:
#, c-format msgid "Very important: %s" msgstr "Pwysig iawn: %s"
Sometimes a whole set of messages are moved to a new module. This can be particularly disheartening if you had translated them once already and think you now have to do them again. You can save on the work by using the .po file from that module with msgmerge. You can also generate yourself a compendium of messages you have translated which you can keep, edit, and use as a source of suggested translations. You can do this using msgcat, in the form msgcat a.po b.po c.po > compendium. You should check the contents of the compendium before using it for translation, especially for strings of the form “#-#-#-#-#” which indicate conflicts among the original .po files. This feature also means that you can use msgcat to check for inconsistencies among .po files. Once you have created your compendium with msgcat, you can make use of it with msgfmt, as you would any other .po file.
You may find that a whole selection of messages are no longer used in the application. They will be moved down to the bottom of the .po file and left there, commented-out. A # at the start of a line comments it out. It is ignored. Unless there is a very large number of these and they really are getting in the way, do not delete these lines. They may come back into the application. They can also be used by the msgmerge program as a source for finding fuzzy translations. Leave them where they are.
翻訳する最初のパッケージの選択
Here are some factors which may help you decide what to translate first.
It is probably best to pick something very small the first time, in order to get used to the translation tools you are using. It is also useful to pick something which is an application rather than a library. This way, you will be able to run the application and see what it looks like. So a small stand-alone application is a good choice.
Unless you are running GNOME built from Git on your machine, you are likely to have the most recent stable release on it. Therefore, it is a good idea to translate the appropriate version of the application. So if you have bug-buddy-2.26 on your machine, use the 2.26 branch of the bug-buddy module in Git (in most cases the branch is called "gnome-2-26"). If you use a different version, some of the strings will have changed, and when you test it, you won't see all of your translations.
As soon as you test your application in its new language, you will almost certainly notice that common buttons and dialogue buttons are still in English. This is because they come from some of the libraries and are reused all over GNOME. To get those into your language, you will need to look at GTK+, gvfs, glib and gnome-desktop. These files contain some very difficult strings, but you do not need to do them all yet. Just look for the strings which consistently show up in dialogue boxes. This will help immensely.
The GTK+ package is part of a grouping called “GNOME developer platform”. It contains about half of the strings in that group. Once you have translated gtk+ you will see a huge jump in your statistics. When you view the statistics page for your language, the package is called “GKT+, UI Translations”. If your time is very limited, you may consider leaving untranslated those messages that you find unfamiliar (error messages, properties, etc). The GTK+ "stock" translations are used in many applications, and will give you good motivation with minimal work at the start. An example of these “stock” messages (stock: they are reused in many applications) are things like “OK”, “Cancel”, “Open”, “Save”, “Print”, “Warning”, “Undo”, “Preferences” that are used in many applications.
An additional important package is “gnome-menus”. It includes the basic categories that you can see in the Applications system menu, including the “Applications” itself, “Accessories”, “Internet”, “Graphics”, “Office” and so on.
Another very useful and small file to translate is xdg-user-dirs which is outside the GNOME project. This package contains common directories like "Videos", "Pictures", "Documents" etc. It can have a big impact with a small amount of work.
Some strings used in the Epiphany web browser come from Mozilla. So even when you have completed Epiphany, you may occasionally meet messages supplied by Mozilla which are not translated. If there is a Mozilla Language Pack for your language, you won't notice this. If there isn't, there is not a lot you can do about it. (You can persuade a friend that they want to translate Mozilla, of course..)
翻訳する最後のパッケージの選択
Note that the libraries libgnome, libgnomeui, libbonobo, libbonoboui, libgnomeprint, libgnomeprintui, gnome-vfs and libglade are deprecated. They are still shipped in GNOME 2.x and used by a few applications, but newly written code should use the existing replacements instead. The listed libraries will be removed for GNOME 3 which is planned for the year 2010 hence you should give these modules a low priority.
Also the so-called "Development tools" are modules that are needed by software developers only and not by average users. Software developers are often able to speak English hence you should give these modules a low priority.
インストール
If you have a reasonably up-to-date version of GNOME on a computer to which you have root access, you can test your translations on your machine and view them in context. This is strongly to be recommended. The machine will need a message object (.mo) file which you can create with the msgfmt -cv command. Run that on your po file, and you will find a file called messages.mo in the directory. This should be placed in the /usr/share/locale/XX/LC_MESSAGES/ directory (where XX is the code for your locale) and given the name of the program. Examples might be metacity.mo or nautilus.mo. Sometimes the program name requires a version number on it. Unfortunately, there is no easy way to work out what the name of the .mo should be for a given package. You will need to look at already-existing filenames in a sister directory to see what they use and copy those. Have a look around the different locales in /usr/share/locale/ and you should find good examples to copy.
Then run the application. Changing the .mo file will probably cause the application to crash, so save your work first; and if you are putting a gnome-terminal.mo there, make sure you are ready for the crash 
Once the file is in place, the app will be fine. It's just the act of updating the file which can cause problems.
The locale needs to exist
The above will only work if the locale exists on your computer. If it does not, you will need to create it. This is simplest on Debian: there is a command for it. The procedure varies on other distributions, unfortunately, and is well outside the scope of this document. Patches are welcome.
Once you have figured out how to install your translations onto a machine, pass the instructions out far and wide to people who might be interested in testing them out. Other people always spot more mistakes than you can. They may also be inspired to help!
テスト
Once you have large parts of your desktop completed, testing becomes vital. This is where you start realising that one of you has used one word for “install” and someone else has used another; or that that word “body” was referring to something other than a human body.
The more testing you can do, or persuade your friends to do, the better.
エディタとその技
A number of editors have special modes for editing .po files, and will drop you into the appropriate mode automatically.
Ensure that your editor is writing in UTF-8 format. If the file is not this format, things in GNOME Git will break.
Editors known to deal with UTF-8 well: Emacs Vim GEdit
For vim, things we have found useful to put into .vimrc are:
set fileencodings=utf-8 " A vim macro that makes control-E copy the msgid to the msgstr: map <C-E> :s/msgid "\(.*\)"\nmsgstr ""/msgid "\1"<C-V><CR>msgstr "\1"/<CR>
There is a plugin for editing .po files in vim which has several other useful tricks. It is available on the Vim website as, unsurprisingly, po.vim
GNU-Emacs has an entire PO mode.
There is a program called gtranslator which helps you translate applications and which is specifically designed for translating GNOME.
Other people are welcome to fill in more tricks for editors, ideally as dotfile instructions.
その他のヒント
There are some things we have learned from bitter experience, and we are including them here so other people don't do it.
Don't leave it ages to get stuff on the branch. We fell for this. However long it takes to check out the branch and update your translation, and however painful it is, if you intend to do both HEAD and branch, apply the changes to both. If you don't, you will meet a day when you spend hours and hours and hours doing nothing but feeding stuff back onto the branch.
If you are on a slow connection or a metered connection, check the branches out into a separate directory rather than flipping between branch and HEAD. It might take longer the first time, but it saves a lot of time in the long run.Automate as much as is safely possible. For example, when you are adding new translations, you will type the same three lines into the main Changelog about adding your locale to LINGUAS something like fifty times. Make a file which says it all already, and update the date daily. And then just include it with an editor macro. It's a lot better than typing it in fifty times. Use shell aliases for frequently used commands.
Find a language enthusiast! You will meet all manner of strange strings to translate, from the detailed spreadsheet terminology of Gnumeric to your language's equivalent of the English “The quick brown fox..” sentence which is used in the font selector because it includes every English letter. You will need to find or invent your own alternative which contains the letters your language uses. (This may be harder for Japanese and Chinese...)
If your language has an accepted set of translations of new terminology, be aware of it, even if you don't like it. Be prepared to justify why you didn't use some “official” terminology...Expect the occasional deliberately silly string. You will meet in-jokes from GNOME hackers as you go through more and more files. The GEGL, for example, may be a code library, but it is also the abbreviation for Genetically Engineered Goat, Large, and is just a silly joke that crops up in various places in GNOME. There is no need to translate it. There is also a selection of bizarre “hints” in one of the aisleriot files.
Accept them. Put up with them. They are part of what makes GNOME fun, although it's difficult to believe that when you've just worked your way through four dictionaries trying to work out what the word might be...The GNOME Internationalisation mailing list (gnome-18n) and the #i18n IRC channel can be either really busy (gnome-i18n) or almost always quiet (#i18n), but there are people on them who have almost certainly met these things before, and can suggest ways to deal with them. Use them.
It's really easy to omit the underscores which will turn a key into a keyboard shortcut in a menu. You can check whether the number of underscores in the msgids and the msgstrs match with the command msgfmt --check-accelerators=_ (but note that once you have filled the translator_credits one in there will always be one that appears to be missing).
Avoid using characters with accents as accelerators. Currently, there is an issue when you set an accelerator to a character such as Á, Å, ᾈ. (character with accents). The problem is that the user would need to press Alt and then the key sequence to produce this character with accent. If, for example, your keyboard layout requires dead keys, then it is currently not possible to type those characters while Alt is pressed. For more, see Keyboard accelerators and accents.
- Test, test, test. Whilst it is hard to get everything localised on your machine, it is very easy to install your own latest translations for at least some applications. Do this. It will really help.
- Create a tarball of completed translations. (Another good candidate for automation.) Put them up on the web with very simple walk-through steps which let other people install them. This gets you feedback (and help) much earlier than waiting for a distribution to ship them will. The instructions for installing will unfortunately differ for very nearly every distribution. But the results are worth it.
用語集
Git
Git: the system used to maintain the repository of GNOME code in a central place.
I18N
- The abbreviation of internationalisation (the initial and final letters of the word and then eighteen letters between them): the process of ensuring a program comes in a form which can be localised.
L10N
- The abbreviation of localisation (the initial and final letters and then ten between them): the process of making a program work in a particular location. It includes both translating messages and tweaking such things as measurements, currency symbols and temperature scales.
locale
- FIXME
A. Special characters in po files, and one special string
There is a separate appendix about C-format strings. Here is a list of other characters and situations which can cause problems.
Escape-able characters
Some characters will be interpreted by the programs which operate on .po files and thus need to be escaped with a backslash in front of them.
The most common character for this is a double-quote character like " .
Formatting marks
You may come across the combinations \n or \t. These mean newline and tab. You do not have to put the same number of these into your translation, but if there is one of these at the start (or end) of the string, you must include one at the start (or end) of your translated string.
Angle brackets and ampersands in GConf files
There are one or two modules where XML is used heavily. GConf is the most notable. XML treats the characters <, > and & as special. You can not just include them in your translation. You must specify them as entities. < is represented as < > is represented as > & is represented as & FIXME: I've sure we've met this. But where? And does it apply to all .in.in.h files too?
TRUE and FALSE
“TRUE” and “FALSE” show up in gtk+ and in Gconf and in a lot of files generated by Glade. (These will have a name ending in .glade.) Do not translate them. Programs expect to see them and will be confused if they don't.
There is also one very special string in the .po file: the msgid of translator_credits. This will show up when someone running the application in your language looks at the credits by following the Help->About path in the application. They will see a Translation option. In that will be the contents of this translator_credits. This is where you put your name(s), so the world can see. The typical format is to put a list of names and email addresses on separate lines, with the URL of any team page. For example:
msgid "translator_credits" msgstr "Telsa Gwynne <hobbit@aloss.ukuug.org.uk>\n" "Dafydd Harries <daf@muse.19inch.net>"
Don't forget to do this one
B. Some C-format strings to leave alone — or to re-order
This is a brief list of C-format strings you may need to know about.
%s
- This represents a string. An example is in nautilus:
#: components/emblem/nautilus-emblem-view.c:834
#, c-format
msgid "The file '%s' does not appear to be a valid image."
msgstr ""
Strings containing such C-format sequnces are marked with the "c-format" tag, like in the example. Be aware that where there are two instances of one of these, they are not necessarily the same string. Another nautilus example:
#: components/hardware/nautilus-hardware-view.c:483 #, c-format msgid "Uptime is %d days, %d hours, %d minutes" msgstr ""
If you need to re-arrange them to make them make sense, you can do that. In English, this is common:
#, c-format msgid "%d out of %d"
This might come out as “10 out of 100”. If your language wants to say “Out of 100, 10”, you can reverse them like this:
#, c-format msgid "%d out of %d" msgstr "Out of %2$d, %1$d"
Original Authors
This guide was originally written by:
License
This document can be redistributed and/or modified under the terms of the GNU General Public License; either version 2 of the license, or (at your option) any later version. The full text of the license can be found at http://www.gnu.org/copyleft/gpl.html.
Translations
原文(English) Localising GNOME Applications
中文(Chinese) 本地化GNOME应用程序