mirror of
https://github.com/rkd77/elinks.git
synced 2025-01-03 14:57:44 -05:00
4c2831677a
the same accelerator key to multiple buttons in a dialog box or to multiple items in a menu. ELinks already has some support for this but it requires the translator to run ELinks and manually scan through all menus and dialogs. The attached changes make it possible to quickly detect and list any conflicts, including ones that can only occur on operating systems or configurations that the translator is not currently using. The changes have no immediate effect on the elinks executable or the MO files. PO files become larger, however. The scheme works like this: - Like before, accelerator keys in translatable strings are tagged with the tilde (~) character. - Whenever a C source file defines an accelerator key, it must assign one or more named "contexts" to it. The translations in the PO files inherit these contexts. If multiple strings use the same accelerator (case insensitive) in the same context, that's a conflict and can be detected automatically. - The contexts are defined with "gettext_accelerator_context" comments in source files. These comments delimit regions where all translatable strings containing tildes are given the same contexts. There must be one special comment at the top of the region; it lists the contexts assigned to that region. The region automatically ends at the end of the function (found with regexp /^\}/), but it can also be closed explicitly with another special comment. The comments are formatted like this: /* [gettext_accelerator_context(foo, bar, baz)] begins a region that uses the contexts "foo", "bar", and "baz". The comma is the delimiter; whitespace is optional. [gettext_accelerator_context()] ends the region. */ The scripts don't currently check whether this syntax occurs inside or outside comments. - The names of contexts consist of C identifiers delimited with periods. I typically used the name of a function that sets up a dialog, or the name of an array where the items of a menu are listed. There is a special feature for static functions: if the name begins with a period, then the period will be replaced with the name of the source file and a colon. - If a menu is programmatically generated from multiple parts, of which some are never used together, so that it is safe to use the same accelerators in them, then it is necessary to define multiple contexts for the same menu. link_menu() in src/viewer/text/link.c is the most complex example of this. - During make update-po: - A Perl script (po/gather-accelerator-contexts.pl) reads po/elinks.pot, scans the source files listed in it for "gettext_accelerator_context" comments, and rewrites po/elinks.pot with "accelerator_context" comments that indicate the contexts of each msgid: the union of all contexts of all of its uses in the source files. It also removes any "gettext_accelerator_context" comments that xgettext --add-comments has copied to elinks.pot. - If po/gather-accelerator-contexts.pl does not find any contexts for some use of an msgid that seems to contain an accelerator (because it contains a tilde), it warns. If the tilde refers to e.g. "~/.elinks" and does not actually mark an accelerator, the warning can be silenced by specifying the special context "IGNORE", which the script otherwise ignores. - msgmerge copies the "accelerator_context" comments from po/elinks.pot to po/*.po. Translators do not edit those comments. - During make check-po: - Another Perl script (po/check-accelerator-contexts.pl) reads po/*.po and keeps track of which accelerators have been bound in each context. It warns about any conflicts it finds. This script does not access the C source files; thus it does not matter if the line numbers in "#:" lines are out of date. This implementation is not perfect and I am not proposing to add it to the main source tree at this time. Specifically: - It introduces compile-time dependencies on Perl and Locale::PO. There should be a configure-time or compile-time check so that the new features are skipped if the prerequisites are missing. - When the scripts include msgstr strings in warnings, they should transcode them from the charset of the PO file to the one specified by the user's locale. - It is not adequately documented (well, except perhaps here). - po/check-accelerator-contexts.pl reports the same conflict multiple times if it occurs in multiple contexts. - The warning messages should include line numbers, so that users of Emacs could conveniently edit the conflicting part of the PO file. This is not feasible with the current version of Locale::PO. - Locale::PO does not understand #~ lines and spews warnings about them. There is an ugly hack to hide these warnings. - Jonas Fonseca suggested the script could propose accelerators that are still available. This has not been implemented. There are three files attached: - po/gather-accelerator-contexts.pl: Augments elinks.pot with context information. - po/check-accelerator-contexts.pl: Checks conflicts. - accelerator-contexts.diff: Makes po/Makefile run the scripts, and adds special comments to source files. |
||
---|---|---|
.. | ||
.gitignore | ||
.vimrc | ||
be.po | ||
bg.po | ||
ca.po | ||
check-accelerator-contexts.pl | ||
cs.po | ||
da.po | ||
de.po | ||
el.po | ||
es.po | ||
et.po | ||
fi.po | ||
fr.po | ||
gather-accelerator-contexts.pl | ||
gen_translations_stats.sh | ||
gl.po | ||
hr.po | ||
hu.po | ||
id.po | ||
is.po | ||
it.po | ||
lt.po | ||
Makefile | ||
nb.po | ||
nl.po | ||
pl.po | ||
pt_BR.po | ||
pt.po | ||
README | ||
ro.po | ||
ru.po | ||
sk.po | ||
sr.po | ||
sv.po | ||
tr.po | ||
uk.po |
Guide for Translators 1. Adding a new language: ========================= Assuming you have downloaded the distributed source tarball, unpacked it and changed directory to the root directory of the unpacked source tarball first make the po template file: $ cd po/ $ make elinks.pot Use the elinks.pot template file as the basis for you translation: $ cp elinks.pot <your language code>.po Modify .po file header that should look like this: # 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: 2005-03-03 11:22+0100\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" Once done don't forget to remove '#, fuzzy' line. Then follow the instructions in the 'Updating .po files' section below. 1.1 Integrating a new language file: ------------------------------------ When you are done editing the .po file you need to integrate it as part of ELinks. If you don't feel comfortable editing the ELinks C-language source code don't hesitate to get a developer to do it for you. First change directory to the root directory of the unpacked source tarball: $ cd ../ Add your language code to the ALL_LINGUAS string in configure.in (keep the alphabetic order ;). To make the change take effect you have to rebuild all Makefiles: $ ./autogen.sh $ ./configure The language file will now be compiled when you run make and you can check the translation file for errors and fix any warnings you get. Next thing is to add it to the Setup->Language menu. This is done by adding an entry in the language array in src/intl/gettext/libintl.c, and should not require any C coding skills, just copy an already existing entry and edit the name of your language (in English) so you end up with something like: struct language languages[] = { {"System", "system"}, {"English", "en"}, ... other entries ... {"<name for your language in English>", "<your language code>"}, ... other entries ... {NULL, NULL}, }; 1.2 Making the new language file part of ELinks: ------------------------------------------------ Finally to make it part of the ELinks distribution send it to one of the mailinglists or file it as a bug at <http://bugzilla.elinks.or.cz>. 2. Updating .po files: ====================== 2.1 Tools needed: ----------------- There are a great deal of tools for editing and working with .po files most are described in the gettext manual availabe at <http://www.gnu.org/manual/gettext> or by typing `info gettext` on some systems. Some editors have special .po modes to help spot errors etc. but nothing fancy is required to update only some reasonable editor. In order to compile, get warnings and actually use your updated language file you will however need the gettext tools. If you don't have any of these tools please don't hesitate to still do the update and send it to the mailinglist or bugzilla so it can be added to CVS. By next release or nightly generated tarball you can then make use of your updates. 2.2 The basics of updating: --------------------------- 2.2.1 Singular forms, general rules: ------------------------------------ Each string that needs to be translated will look like this: #: src/dialogs/info.c:184 #, fuzzy, c-format msgid "Cache content: %s" msgstr "Cacheindhold: %s" Lines starting with '#' are comments or control hints for the po compiler. The text following '#:' is a listing of each place (filename and line number) in the code where the string is used. Text following '#,' are a comma separated list of control hints: 'fuzzy' means that the string was changed in the code and the translator needs to check if the translation is still ok. When it has been checked or updated it is safe to remove 'fuzzy' and the following comma. 'c-format' is a hint to the compiler, checker and translator that the string uses printf format. The string following 'msgid' are the original untranslated string. It is used to get the translated one so: DO NEVER CHANGE IT. If you spot an error in it change it in the code instead and resync your .po files using make update-po. The string following 'msgstr' is the translated string. TODO: write about the meaning of % fragments. Some strings contain '~' (tilde) chars. They are used to mark hotkeys in text for menu entries. The char following the '~' is the hotkey char. So in the string "Global ~history" the hotkey will become 'h'. You should try and keep hotkeys unique. If you configure ELinks with --enable-debug conflicting hotkeys will be visible. Some translations may become obsolete due to code modifications, these will be marked by #~ prefix, and moved at end of file. Keeping them may be a good thing since a modification can be reversed later and then gettext tools will reuse these special lines at resync time. If, at some time, you think some of these lines will never be reused, feel free to delete them to reduce file size. A special msgid ("") contains .po file headers, you may update them as well, especially Last-Translator and PO-Revision-Date fields. 2.2.2 Plurals forms: -------------------- First set Plural-Forms: header (msgid "" at top of .po file) to some correct value, depending on language. To help you in this, here is an excerpt from GNU gettext documentation: Only one form: Some languages only require one single form. There is no distinction between the singular and plural form. An appropriate header entry would look like this: Plural-Forms: nplurals=1; plural=0; Languages with this property include: Finno-Ugric family Hungarian Asian family Japanese, Korean Turkic/Altaic family Turkish Two forms, singular used for one only: This is the form used in most existing programs since it is what English is using. A header entry would look like this: Plural-Forms: nplurals=2; plural=n != 1; (Note: this uses the feature of C expressions that boolean expressions have to value zero or one.) Languages with this property include: Germanic family Danish, Dutch, English, German, Norwegian, Swedish Finno-Ugric family Estonian, Finnish Latin/Greek family Greek Semitic family Hebrew Romanic family Italian, Portuguese, Spanish Artificial Esperanto Two forms, singular used for zero and one: Exceptional case in the language family. The header entry would be: Plural-Forms: nplurals=2; plural=n>1; Languages with this property include: Romanic family French, Brazilian Portuguese Three forms, special case for zero: The header entry would be: Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n != 0 ? 1 : 2; Languages with this property include: Baltic family Latvian Three forms, special cases for one and two: The header entry would be: Plural-Forms: nplurals=3; plural=n==1 ? 0 : n==2 ? 1 : 2; Languages with this property include: Celtic Gaeilge (Irish) Three forms, special case for numbers ending in 1[2-9]: The header entry would look like this: Plural-Forms: nplurals=3; \ plural=n%10==1 && n%100!=11 ? 0 : \ n%10>=2 && (n%100<10 || n%100>=20) ? 1 : 2; Languages with this property include: Baltic family Lithuanian Three forms, special cases for numbers ending in 1 and 2, 3, 4, except those ending in 1[1-4]: The header entry would look like this: Plural-Forms: nplurals=3; \ plural=n%10==1 && n%100!=11 ? 0 : \ n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2; Languages with this property include: Slavic family Croatian, Czech, Russian, Slovak, Ukrainian Three forms, special case for one and some numbers ending in 2, 3, or 4: The header entry would look like this: Plural-Forms: nplurals=3; \ plural=n==1 ? 0 : \ n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2; Languages with this property include: Slavic family Polish Four forms, special case for one and all numbers ending in 02, 03, or 04: The header entry would look like this: Plural-Forms: nplurals=4; \ plural=n%100==1 ? 0 : n%100==2 ? 1 : n%100==3 || n%100==4 ? 2 : 3; Languages with this property include: Slavic family Slovenian More info at http://www.gnu.org/software/gettext Plural forms will appear like this in .po file: #: src/dialogs/info.c:259 #, c-format msgid "%d session" msgid_plural "%d sessions" msgstr[0] "%d session" msgstr[1] "%d sessions" msgid and msgid_plural should not be changed, each msgstr[n] line contains translation for each plural form. 2.3 Synchronizing .po files with the code ----------------------------------------- IMPORTANT: if you changed strings in the code, or if you're using a cvs version of ELinks, take care of synchronization between code and po files. Before any change to a po file, you must synchronize it with code. To update only one file you may use: cd po/ ; make update-po PO=<lang>.po or cd po/ ; make update-po PO=<lang> where <lang> has to be replaced by ie. fr, de, da, cs... If this fails or you want to update all .po files, use: cd po/ ; make update-po 2.4 Checking updated .po files ------------------------------ After updating a .po file you should always check it for errors in the c-format fragments, etc. You can do this by running: cd po/ ; make check-po PO=<lang>.po or cd po/ ; make check-po PO=<lang> It can potentially report some false positives if the .po file contains fuzzy message strings. 2.5 Making the updates part of ELinks: -------------------------------------- If the language file is already added finally run make to compile and check the language file for errors and fix any warnings you get. Then patch your changes and send it to one of the mailinglists or file it as a bug at <http://bugzilla.elinks.or.cz>. 3. Statistics: ============== Some people (like Zas but other mortals as well ;) like to know how much of the language file is up-to-date. This can be accomplished by running the gen_translations_stats.sh script from the po/ directory. It will list the current status of each language file. Be proud if your language file rank higher or the same as the French one. vim: textwidth=80