diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/gettext.info | 189 | ||||
| -rw-r--r-- | doc/gettext.info-1 | 59 | ||||
| -rw-r--r-- | doc/gettext.info-2 | 274 | ||||
| -rw-r--r-- | doc/gettext.info-3 | 256 | ||||
| -rw-r--r-- | doc/gettext.info-4 | 341 | ||||
| -rw-r--r-- | doc/gettext.info-5 | 189 | ||||
| -rw-r--r-- | doc/version.texi | 2 |
7 files changed, 730 insertions, 580 deletions
diff --git a/doc/gettext.info b/doc/gettext.info index cbc500f..c3d6cf3 100644 --- a/doc/gettext.info +++ b/doc/gettext.info @@ -33,103 +33,104 @@ translation approved by the Foundation. Indirect: gettext.info-1: 1411 -gettext.info-2: 49514 -gettext.info-3: 98183 -gettext.info-4: 147581 -gettext.info-5: 197084 +gettext.info-2: 48952 +gettext.info-3: 98371 +gettext.info-4: 147112 +gettext.info-5: 195688 Tag Table: (Indirect) Node: Top1411 -Node: Introduction6887 -Node: Why8743 -Ref: Why-Footnote-111833 -Node: Concepts11989 -Node: Aspects15402 -Node: Files21459 -Node: Overview23727 -Node: Basics34653 -Node: Installation35483 -Node: PO Files37450 -Ref: PO Files-Footnote-144462 -Node: Main PO Commands44574 -Node: Entry Positioning49514 -Node: Normalizing54765 -Node: Sources59217 -Node: Triggering60487 -Node: Mark Keywords63502 -Node: Marking67052 -Node: c-format74693 -Node: Special cases78443 -Node: Initial81305 -Node: xgettext Invocation81627 -Node: C Sources Context85455 -Node: Compendium90434 -Node: Updating91137 -Node: msgmerge Invocation91777 -Node: Translated Entries91951 -Node: Fuzzy Entries93242 -Node: Untranslated Entries96344 -Node: Obsolete Entries98183 -Node: Modifying Translations101315 -Node: Modifying Comments109133 -Node: Subedit113440 -Node: Auxiliary117217 -Node: Binaries120287 -Node: msgfmt Invocation120551 -Node: MO Files123177 -Node: Users131263 -Node: Matrix132744 -Node: Installers133947 -Node: End Users135117 -Node: Programmers135746 -Node: catgets136920 -Node: Interface to catgets138325 -Node: Problems with catgets140326 -Node: gettext141224 -Node: Interface to gettext142682 -Node: Ambiguities145024 -Node: Locating Catalogs147581 -Ref: Locating Catalogs-Footnote-1148728 -Ref: Locating Catalogs-Footnote-2148953 -Node: Charset conversion149102 -Node: Plural forms151544 -Ref: Plural forms-Footnote-1161320 -Node: GUI program problems161412 -Node: Optimized gettext166515 -Node: Comparison167848 -Node: Using libintl.a172120 -Node: gettext grok172891 -Node: Temp Programmers175523 -Node: Temp Implementations175963 -Node: Temp catgets177329 -Node: Temp WSI179016 -Node: Temp Notes181004 -Node: Translators181493 -Node: Trans Intro 0181872 -Node: Trans Intro 1184521 -Node: Discussions186385 -Node: Organization189541 -Node: Central Coordination191522 -Node: National Teams192650 -Node: Sub-Cultures195162 -Node: Organizational Ideas196081 -Node: Mailing Lists197084 -Node: Information Flow198887 -Node: Maintainers201020 -Node: Flat and Non-Flat202779 -Node: Prerequisites204540 -Node: gettextize Invocation208649 -Node: Adjusting Files212221 -Node: po/POTFILES.in213444 -Node: configure.in214383 -Node: aclocal216509 -Node: acconfig217688 -Node: Makefile218286 -Node: src/Makefile220474 -Node: Conclusion222871 -Node: History223361 -Node: References226821 -Node: Language Codes228376 +Node: Introduction6944 +Node: Why8800 +Ref: Why-Footnote-111890 +Node: Concepts12046 +Node: Aspects15459 +Node: Files21208 +Node: Overview23150 +Node: Basics34076 +Node: Installation34906 +Node: PO Files36873 +Ref: PO Files-Footnote-143885 +Node: Main PO Commands44012 +Node: Entry Positioning48952 +Node: Normalizing54203 +Node: Sources58655 +Node: Triggering59926 +Node: Mark Keywords62941 +Node: Marking66491 +Node: c-format74132 +Node: Special cases77882 +Node: Template80744 +Node: xgettext Invocation81096 +Node: Creating84900 +Node: Updating91212 +Node: msgmerge Invocation91965 +Node: Translated Entries92139 +Node: Fuzzy Entries93430 +Node: Untranslated Entries96532 +Node: Obsolete Entries98371 +Node: Modifying Translations101503 +Node: Modifying Comments109321 +Node: Subedit113628 +Node: C Sources Context117413 +Node: Auxiliary122380 +Node: Compendium125479 +Node: Binaries126175 +Node: msgfmt Invocation126439 +Node: MO Files129065 +Node: Users137151 +Node: Matrix138632 +Node: Installers139835 +Node: End Users141005 +Node: Programmers141634 +Node: catgets142808 +Node: Interface to catgets144213 +Node: Problems with catgets146214 +Node: gettext147112 +Node: Interface to gettext148570 +Node: Ambiguities150912 +Node: Locating Catalogs153469 +Ref: Locating Catalogs-Footnote-1154616 +Ref: Locating Catalogs-Footnote-2154841 +Node: Charset conversion154990 +Node: Plural forms157432 +Ref: Plural forms-Footnote-1167461 +Node: GUI program problems167553 +Node: Optimized gettext172656 +Node: Comparison173989 +Node: Using libintl.a178261 +Node: gettext grok179038 +Node: Temp Programmers181670 +Node: Temp Implementations182110 +Node: Temp catgets183476 +Node: Temp WSI185163 +Node: Temp Notes187151 +Node: Translators187640 +Node: Trans Intro 0188019 +Node: Trans Intro 1190668 +Node: Discussions192532 +Node: Organization195688 +Node: Central Coordination197669 +Node: National Teams198797 +Node: Sub-Cultures201309 +Node: Organizational Ideas202228 +Node: Mailing Lists203231 +Node: Information Flow205034 +Node: Maintainers207167 +Node: Flat and Non-Flat208926 +Node: Prerequisites210409 +Node: gettextize Invocation214518 +Node: Adjusting Files218090 +Node: po/POTFILES.in219313 +Node: configure.in220252 +Node: aclocal222378 +Node: acconfig223557 +Node: Makefile224155 +Node: src/Makefile226343 +Node: Conclusion228740 +Node: History229230 +Node: References232690 +Node: Language Codes234245 End Tag Table diff --git a/doc/gettext.info-1 b/doc/gettext.info-1 index d7cdd42..df2989f 100644 --- a/doc/gettext.info-1 +++ b/doc/gettext.info-1 @@ -41,7 +41,8 @@ GNU `gettext' utilities * Introduction:: Introduction * Basics:: PO Files and PO Mode Basics * Sources:: Preparing Program Sources -* Initial:: Making the Initial PO File +* Template:: Making the PO Template File +* Creating:: Creating a New PO File * Updating:: Updating Existing PO Files * Binaries:: Producing Binary MO Files * Users:: The User's View @@ -78,11 +79,9 @@ Preparing Program Sources * c-format:: Telling something about the following string * Special cases:: Special Cases of Translatable Strings -Making the Initial PO File +Making the PO Template File * xgettext Invocation:: Invoking the `xgettext' Program -* C Sources Context:: C Sources Context -* Compendium:: Using Translation Compendiums Updating Existing PO Files @@ -94,7 +93,9 @@ Updating Existing PO Files * Modifying Translations:: Modifying Translations * Modifying Comments:: Modifying Comments * Subedit:: Mode for Editing Translations +* C Sources Context:: C Sources Context * Auxiliary:: Consulting Auxiliary PO Files +* Compendium:: Using Translation Compendiums Producing Binary MO Files @@ -400,20 +401,18 @@ translate beyond output messages. As we already stressed, translation is only one aspect of locales. -Other internationalization aspects are not currently handled by GNU -`gettext', but perhaps may be handled in future versions. There are -many attributes that are needed to define a country's cultural -conventions. These attributes include beside the country's native -language, the formatting of the date and time, the representation of -numbers, the symbols for currency, etc. These local "rules" are termed -the country's locale. The locale represents the knowledge needed to -support the country's native attributes. +Other internationalization aspects are system services and are handled +in GNU `libc'. There are many attributes that are needed to define a +country's cultural conventions. These attributes include beside the +country's native language, the formatting of the date and time, the +representation of numbers, the symbols for currency, etc. These local +"rules" are termed the country's locale. The locale represents the +knowledge needed to support the country's native attributes. There are a few major areas which may vary between countries and hence, define what a locale must describe. The following list helps putting multi-lingual messages into the proper context of other tasks -related to locales, and also presents some other areas which GNU -`gettext' might eventually tackle, maybe, one of these days. +related to locales. See the GNU `libc' manual for details. _Characters and Codesets_ The codeset most commonly used through out the USA and most English @@ -460,13 +459,10 @@ _Messages_ users to easily change the language that the software uses to communicate to the user. - In the near future we see no chance that components of locale -outside of message handling will be made available for use in other -packages. The reason for this is that most modern systems provide a -more or less reasonable support for at least some of the missing -components. Another point is that the GNU `libc' and Linux will get a -new and complete implementation of the whole locale functionality which -could be adopted by system lacking a reasonable locale support. + Components of locale outside of message handling are standardized in +the ISO C standard and the SUSV2 specification. GNU `libc' fully +implements this, and most other modern systems provide a more or less +reasonable support for at least some of the missing components. File: gettext.info, Node: Files, Next: Overview, Prev: Aspects, Up: Introduction @@ -500,15 +496,10 @@ often temporary PO files. A few systems already offer tools for creating and handling MO files as part of the Native Language Support coming with the system, but the format of these MO files is often different from system to system, and -non-portable. They do not necessary use `.mo' for file extensions, but -since system libraries are also used for accessing these files, it -works as long as the system is self-consistent about it. If GNU -`gettext' is able to interface with the tools already provided with -systems, it will consequently let these provided tools take care of -generating the MO files. Or else, if such tools are not found or do -not seem usable, GNU `gettext' will use its own ways and its own format -for MO files. Files ending with `.gmo' are really MO files, when it is -known that these files use the GNU format. +non-portable. The tools already provided with these systems don't +support all the features of GNU `gettext'. Therefore GNU `gettext' +uses its own format for MO files. Files ending with `.gmo' are really +MO files, when it is known that these files use the GNU format. File: gettext.info, Node: Overview, Prev: Files, Up: Introduction @@ -590,8 +581,8 @@ library functions are already contained in GNU libc. That is all you have to change. Once the C sources have been modified, the `xgettext' program is -used to find and extract all translatable strings, and create an -initial PO file out of all these. This `PACKAGE.pot' file contains all +used to find and extract all translatable strings, and create a PO +template file out of all these. This `PACKAGE.pot' file contains all original program strings. It has sets of pointers to exactly where in C sources each string is used. All translations are set to empty. The letter `t' in `.pot' marks this as a Template PO file, not yet oriented @@ -919,8 +910,8 @@ be replaced unexpectedly when the PO file is given to `msgmerge'. ---------- Footnotes ---------- - (1) This limitation is not imposed by GNU `gettext', but comes from -the `msgfmt' implementation on Solaris. + (1) This limitation is not imposed by GNU `gettext', but is for +compatibility with the `msgfmt' implementation on Solaris. File: gettext.info, Node: Main PO Commands, Next: Entry Positioning, Prev: PO Files, Up: Basics diff --git a/doc/gettext.info-2 b/doc/gettext.info-2 index 36352bd..e480eba 100644 --- a/doc/gettext.info-2 +++ b/doc/gettext.info-2 @@ -240,7 +240,7 @@ normalization, to be documented in this manual, once these questions settle. -File: gettext.info, Node: Sources, Next: Initial, Prev: Basics, Up: Top +File: gettext.info, Node: Sources, Next: Template, Prev: Basics, Up: Top Preparing Program Sources ************************* @@ -718,19 +718,20 @@ generally not very difficult. If it should be in any situation you can use this second method in this situation. -File: gettext.info, Node: Initial, Next: Updating, Prev: Sources, Up: Top +File: gettext.info, Node: Template, Next: Creating, Prev: Sources, Up: Top -Making the Initial PO File -************************** +Making the PO Template File +*************************** + + After preparing the sources, the programmer creates a PO template +file. This section explains how to use `xgettext' for this purpose. * Menu: * xgettext Invocation:: Invoking the `xgettext' Program -* C Sources Context:: C Sources Context -* Compendium:: Using Translation Compendiums -File: gettext.info, Node: xgettext Invocation, Next: C Sources Context, Prev: Initial, Up: Initial +File: gettext.info, Node: xgettext Invocation, Prev: Template, Up: Template Invoking the `xgettext' Program =============================== @@ -863,123 +864,162 @@ cases, like strings in preprocessor macros, ANSI concatenation of adjacent strings, and escaped end of lines for continued strings. -File: gettext.info, Node: C Sources Context, Next: Compendium, Prev: xgettext Invocation, Up: Initial +File: gettext.info, Node: Creating, Next: Updating, Prev: Template, Up: Top -C Sources Context -================= +Creating a New PO File +********************** - PO mode is particularily powerful when used with PO files created -through GNU `gettext' utilities, as those utilities insert special -comments in the PO files they generate. Some of these special comments -relate the PO file entry to exactly where the untranslated string -appears in the program sources. - - When the translator gets to an untranslated entry, she is fairly -often faced with an original string which is not as informative as it -normally should be, being succinct, cryptic, or otherwise ambiguous. -Before chosing how to translate the string, she needs to understand -better what the string really means and how tight the translation has -to be. Most of times, when problems arise, the only way left to make -her judgment is looking at the true program sources from where this -string originated, searching for surrounding comments the programmer -might have put in there, and looking around for helping clues of _any_ -kind. - - Surely, when looking at program sources, the translator will receive -more help if she is a fluent programmer. However, even if she is not -versed in programming and feels a little lost in C code, the translator -should not be shy at taking a look, once in a while. It is most -probable that she will still be able to find some of the hints she -needs. She will learn quickly to not feel uncomfortable in program -code, paying more attention to programmer's comments, variable and -function names (if he dared chosing them well), and overall -organization, than to programmation itself. - - The following commands are meant to help the translator at getting -program source context for a PO file entry. - -`s' - Resume the display of a program source context, or cycle through - them. - -`M-s' - Display of a program source context selected by menu. - -`S' - Add a directory to the search path for source files. - -`M-S' - Delete a directory from the search path for source files. - - The commands `s' (`po-cycle-reference') and `M-s' -(`po-select-source-reference') both open another window displaying some -source program file, and already positioned in such a way that it shows -an actual use of the string to be translated. By doing so, the command -gives source program context for the string. But if the entry has no -source context references, or if all references are unresolved along -the search path for program sources, then the command diagnoses this as -an error. - - Even if `s' (or `M-s') opens a new window, the cursor stays in the -PO file window. If the translator really wants to get into the program -source window, she ought to do it explicitly, maybe by using command -`O'. - - When `s' is typed for the first time, or for a PO file entry which -is different of the last one used for getting source context, then the -command reacts by giving the first context available for this entry, if -any. If some context has already been recently displayed for the -current PO file entry, and the translator wandered off to do other -things, typing `s' again will merely resume, in another window, the -context last displayed. In particular, if the translator moved the -cursor away from the context in the source file, the command will bring -the cursor back to the context. By using `s' many times in a row, with -no other commands intervening, PO mode will cycle to the next available -contexts for this particular entry, getting back to the first context -once the last has been shown. - - The command `M-s' behaves differently. Instead of cycling through -references, it lets the translator choose of particular reference among -many, and displays that reference. It is best used with completion, if -the translator types `<TAB>' immediately after `M-s', in response to -the question, she will be offered a menu of all possible references, as -a reminder of which are the acceptable answers. This command is useful -only where there are really many contexts available for a single string -to translate. - - Program source files are usually found relative to where the PO file -stands. As a special provision, when this fails, the file is also -looked for, but relative to the directory immediately above it. Those -two cases take proper care of most PO files. However, it might happen -that a PO file has been moved, or is edited in a different place than -its normal location. When this happens, the translator should tell PO -mode in which directory normally sits the genuine PO file. Many such -directories may be specified, and all together, they constitute what is -called the "search path" for program sources. The command `S' -(`po-consider-source-path') is used to interactively enter a new -directory at the front of the search path, and the command `M-S' -(`po-ignore-source-path') is used to select, with completion, one of -the directories she does not want anymore on the search path. + When starting a new translation, the translator copies the +`PACKAGE.pot' template file to a file called `LANG.po'. Then she +modifies the initial comments and the header entry of this file. - -File: gettext.info, Node: Compendium, Prev: C Sources Context, Up: Initial + The initial comments "SOME DESCRIPTIVE TITLE", "YEAR" and "FIRST +AUTHOR <EMAIL@ADDRESS>, YEAR" ought to be replaced by sensible +information. This can be done in any text editor; if Emacs is used and +it switched to PO mode automatically (because it has recognized the +file's suffix), you can disable it by typing `M-x fundamental-mode'. + + Modifying the header entry can already be done using PO mode: in +Emacs, type `M-x po-mode RET' and then `RET' again to start editing the +entry. You should fill in the following fields. + +Project-Id-Version + This is the name and version of the package. + +POT-Creation-Date + This has already been filled in by `xgettext'. + +PO-Revision-Date + You don't need to fill this in. It will be filled by the Emacs PO + mode when you save the file. + +Last-Translator + Fill in your name and email address (without double quotes). + +Language-Team + Fill in the English name of the language, and the email address of + the language team you are part of. + + Before starting a translation, it is a good idea to get in touch + with your translation team, not only to make sure you don't do + duplicated work, but also to coordinate difficult linguistic + issues. + + In the Free Translation Project, each translation team has its own + mailing list. The up-to-date list of teams can be found at the + Free Translation Project's homepage, + `http://www.iro.umontreal.ca/contrib/po/HTML/', in the "National + teams" area. + +Content-Type + Replace `CHARSET' with the character encoding used for your + language, in your locale, or UTF-8. This field is needed for + correct operation of the `msgmerge' and `msgfmt' programs, as well + as for users whose locale's character encoding differs from yours + (see *Note Charset conversion::). + + You get the character encoding of your locale by running the shell + command `locale charmap'. If the result is `C' or + `ANSI_X3.4-1968', which is equivalent to `ASCII' (= `US-ASCII'), + it means that your locale is not correctly configured. In this + case, ask your translation team which charset to use. `ASCII' is + not usable for any language except Latin. + + Because the PO files must be portable to operating systems with + less advanced internationalization facilities, the character + encodings that can be used are limited to those supported by both + GNU `libc' and GNU `libiconv'. These are: `ASCII', `ISO-8859-1', + `ISO-8859-2', `ISO-8859-3', `ISO-8859-4', `ISO-8859-5', + `ISO-8859-6', `ISO-8859-7', `ISO-8859-8', `ISO-8859-9', + `ISO-8859-13', `ISO-8859-15', `KOI8-R', `KOI8-U', `CP850', + `CP866', `CP874', `CP932', `CP949', `CP950', `CP1250', `CP1251', + `CP1252', `CP1253', `CP1254', `CP1255', `CP1256', `CP1257', + `GB2312', `EUC-JP', `EUC-KR', `EUC-TW', `BIG5', `BIG5HKSCS', + `GBK', `GB18030', `SJIS', `JOHAB', `TIS-620', `VISCII', `UTF-8'. + + In the GNU system, the following encodings are frequently used for + the corresponding languages. + + * `ISO-8859-1' for Afrikaans, Albanian, Basque, Catalan, + Dutch, English, Estonian, Faroese, Finnish, French, + Galician, German, Greenlandic, Icelandic, Indonesian, Irish, + Italian, Malay, Norwegian, Portuguese, Spanish, Swedish, + + * `ISO-8859-2' for Croatian, Czech, Hungarian, Polish, + Romanian, Serbian, Slovak, Slovenian, + + * `ISO-8859-3' for Maltese, -Using Translation Compendiums -============================= + * `ISO-8859-5' for Macedonian, Serbian, - Compendiums are yet to be implemented. + * `ISO-8859-6' for Arabic, - An incoming PO mode feature will let the translator maintain a -compendium of already achieved translations. A "compendium" is a -special PO file containing a set of translations recurring in many -different packages. The translator will be given commands for adding -entries to her compendium, and later initializing untranslated entries, -or updating already translated entries, from translations kept in the -compendium. For this to work, however, the compendium would have to be -normalized. *Note Normalizing::. + * `ISO-8859-7' for Greek, + + * `ISO-8859-8' for Hebrew, + + * `ISO-8859-9' for Turkish, + + * `ISO-8859-13' for Latvian, Lithuanian, + + * `ISO-8859-15' for Basque, Catalan, Dutch, English, Finnish, + French, Galician, German, Irish, Italian, Portuguese, + Spanish, Swedish, + + * `KOI8-R' for Russian, + + * `KOI8-U' for Ukrainian, + + * `CP1251' for Bulgarian, Byelorussian, + + * `GB2312', `GBK', `GB18030' for simplified writing of Chinese, + + * `BIG5', `BIG5HKSCS' for traditional writing of Chinese, + + * `EUC-JP' for Japanese, + + * `EUC-KR' for Korean, + + * `TIS-620' for Thai, + + * `UTF-8' for any language, including those listed above. + + When single quote characters or double quote characters are used in + translations for your language, and your locale's encoding is one + of the ISO-8859-* charsets, it is best if you create your PO files + in UTF-8 encoding, instead of your locale's encoding. This is + because in UTF-8 the real quote characters can be represented + (single quote characters: U+2018, U+2019, double quote characters: + U+201C, U+201D), whereas none of ISO-8859-* charsets has them all. + Users in UTF-8 locales will see the real quote characters, + whereas users in ISO-8859-* locales will see the vertical + apostrophe and the vertical double quote instead (because that's + what the character set conversion will transliterate them to). + + To enter such quote characters under X11, you can change your + keyboard mapping using the `xmodmap' program. The X11 names of + the quote characters are "leftsinglequotemark", + "rightsinglequotemark", "leftdoublequotemark", + "rightdoublequotemark", "singlelowquotemark", "doublelowquotemark". + + Note that only recent versions of GNU Emacs support the UTF-8 + encoding: Emacs 20 with Mule-UCS, and Emacs 21. As of January + 2001, XEmacs doesn't support the UTF-8 encoding. + + The character encoding name can be written in either upper or + lower case. Usually upper case is preferred. + +Content-Transfer-Encoding + Set this to `8-bit'. + +Plural-Forms + This field is optional. It is only needed if the PO file has + plural forms. You can find them by searching for the + `msgid_plural' keyword. The format of the plural forms field is + described in *Note Plural forms::. -File: gettext.info, Node: Updating, Next: Binaries, Prev: Initial, Up: Top +File: gettext.info, Node: Updating, Next: Binaries, Prev: Creating, Up: Top Updating Existing PO Files ************************** @@ -994,7 +1034,9 @@ Updating Existing PO Files * Modifying Translations:: Modifying Translations * Modifying Comments:: Modifying Comments * Subedit:: Mode for Editing Translations +* C Sources Context:: C Sources Context * Auxiliary:: Consulting Auxiliary PO Files +* Compendium:: Using Translation Compendiums File: gettext.info, Node: msgmerge Invocation, Next: Translated Entries, Prev: Updating, Up: Updating diff --git a/doc/gettext.info-3 b/doc/gettext.info-3 index f25894d..f28d7b0 100644 --- a/doc/gettext.info-3 +++ b/doc/gettext.info-3 @@ -333,7 +333,7 @@ Emacs commands `C-y' (`yank') and `M-y' (`yank-pop') to get the previous translation where she likes. -File: gettext.info, Node: Subedit, Next: Auxiliary, Prev: Modifying Comments, Up: Updating +File: gettext.info, Node: Subedit, Next: C Sources Context, Prev: Modifying Comments, Up: Updating Details of Sub Edition ====================== @@ -410,7 +410,106 @@ subedits are automatically resumed one at a time, so she may decide for each of them. -File: gettext.info, Node: Auxiliary, Prev: Subedit, Up: Updating +File: gettext.info, Node: C Sources Context, Next: Auxiliary, Prev: Subedit, Up: Updating + +C Sources Context +================= + + PO mode is particularily powerful when used with PO files created +through GNU `gettext' utilities, as those utilities insert special +comments in the PO files they generate. Some of these special comments +relate the PO file entry to exactly where the untranslated string +appears in the program sources. + + When the translator gets to an untranslated entry, she is fairly +often faced with an original string which is not as informative as it +normally should be, being succinct, cryptic, or otherwise ambiguous. +Before chosing how to translate the string, she needs to understand +better what the string really means and how tight the translation has +to be. Most of times, when problems arise, the only way left to make +her judgment is looking at the true program sources from where this +string originated, searching for surrounding comments the programmer +might have put in there, and looking around for helping clues of _any_ +kind. + + Surely, when looking at program sources, the translator will receive +more help if she is a fluent programmer. However, even if she is not +versed in programming and feels a little lost in C code, the translator +should not be shy at taking a look, once in a while. It is most +probable that she will still be able to find some of the hints she +needs. She will learn quickly to not feel uncomfortable in program +code, paying more attention to programmer's comments, variable and +function names (if he dared chosing them well), and overall +organization, than to programmation itself. + + The following commands are meant to help the translator at getting +program source context for a PO file entry. + +`s' + Resume the display of a program source context, or cycle through + them. + +`M-s' + Display of a program source context selected by menu. + +`S' + Add a directory to the search path for source files. + +`M-S' + Delete a directory from the search path for source files. + + The commands `s' (`po-cycle-reference') and `M-s' +(`po-select-source-reference') both open another window displaying some +source program file, and already positioned in such a way that it shows +an actual use of the string to be translated. By doing so, the command +gives source program context for the string. But if the entry has no +source context references, or if all references are unresolved along +the search path for program sources, then the command diagnoses this as +an error. + + Even if `s' (or `M-s') opens a new window, the cursor stays in the +PO file window. If the translator really wants to get into the program +source window, she ought to do it explicitly, maybe by using command +`O'. + + When `s' is typed for the first time, or for a PO file entry which +is different of the last one used for getting source context, then the +command reacts by giving the first context available for this entry, if +any. If some context has already been recently displayed for the +current PO file entry, and the translator wandered off to do other +things, typing `s' again will merely resume, in another window, the +context last displayed. In particular, if the translator moved the +cursor away from the context in the source file, the command will bring +the cursor back to the context. By using `s' many times in a row, with +no other commands intervening, PO mode will cycle to the next available +contexts for this particular entry, getting back to the first context +once the last has been shown. + + The command `M-s' behaves differently. Instead of cycling through +references, it lets the translator choose of particular reference among +many, and displays that reference. It is best used with completion, if +the translator types `<TAB>' immediately after `M-s', in response to +the question, she will be offered a menu of all possible references, as +a reminder of which are the acceptable answers. This command is useful +only where there are really many contexts available for a single string +to translate. + + Program source files are usually found relative to where the PO file +stands. As a special provision, when this fails, the file is also +looked for, but relative to the directory immediately above it. Those +two cases take proper care of most PO files. However, it might happen +that a PO file has been moved, or is edited in a different place than +its normal location. When this happens, the translator should tell PO +mode in which directory normally sits the genuine PO file. Many such +directories may be specified, and all together, they constitute what is +called the "search path" for program sources. The command `S' +(`po-consider-source-path') is used to interactively enter a new +directory at the front of the search path, and the command `M-S' +(`po-ignore-source-path') is used to select, with completion, one of +the directories she does not want anymore on the search path. + + +File: gettext.info, Node: Auxiliary, Next: Compendium, Prev: C Sources Context, Up: Updating Consulting Auxiliary PO Files ============================= @@ -476,6 +575,23 @@ discrepancies between PO mode and other GNU `gettext' tools get fully resolved, the translator should stay aware of normalisation issues. +File: gettext.info, Node: Compendium, Prev: Auxiliary, Up: Updating + +Using Translation Compendiums +============================= + + Compendiums are yet to be implemented. + + An incoming PO mode feature will let the translator maintain a +compendium of already achieved translations. A "compendium" is a +special PO file containing a set of translations recurring in many +different packages. The translator will be given commands for adding +entries to her compendium, and later initializing untranslated entries, +or updating already translated entries, from translations kept in the +compendium. For this to work, however, the compendium would have to be +normalized. *Note Normalizing::. + + File: gettext.info, Node: Binaries, Next: Users, Prev: Updating, Up: Top Producing Binary MO Files @@ -916,139 +1032,3 @@ chaos but one as the other fails in one aspect or the other. We don't want to say that the other approach has no problems but they are far more easily to manage. - -File: gettext.info, Node: gettext, Next: Comparison, Prev: catgets, Up: Programmers - -About `gettext' -=============== - - The definition of the `gettext' interface comes from a Uniforum -proposal and it is followed by at least one major Unix vendor (Sun) in -its last developments. It is not specified in any official standard, -though. - - The main points about this solution is that it does not follow the -method of normal file handling (open-use-close) and that it does not -burden the programmer so many task, especially the unique key handling. -Of course here is also a unique key needed, but this key is the message -itself (how long or short it is). See *Note Comparison:: for a more -detailed comparison of the two methods. - - The following section contains a rather detailed description of the -interface. We make it that detailed because this is the interface we -chose for the GNU `gettext' Library. Programmers interested in using -this library will be interested in this description. - -* Menu: - -* Interface to gettext:: The interface -* Ambiguities:: Solving ambiguities -* Locating Catalogs:: Locating message catalog files -* Charset conversion:: How to request conversion to Unicode -* Plural forms:: Additional functions for handling plurals -* GUI program problems:: Another technique for solving ambiguities -* Optimized gettext:: Optimization of the *gettext functions - - -File: gettext.info, Node: Interface to gettext, Next: Ambiguities, Prev: gettext, Up: gettext - -The Interface -------------- - - The minimal functionality an interface must have is a) to select a -domain the strings are coming from (a single domain for all programs is -not reasonable because its construction and maintenance is difficult, -perhaps impossible) and b) to access a string in a selected domain. - - This is principally the description of the `gettext' interface. It -has an global domain which unqualified usages reference. Of course this -domain is selectable by the user. - - char *textdomain (const char *domain_name); - - This provides the possibility to change or query the current status -of the current global domain of the `LC_MESSAGE' category. The -argument is a null-terminated string, whose characters must be legal in -the use in filenames. If the DOMAIN_NAME argument is `NULL', the -function return the current value. If no value has been set before, -the name of the default domain is returned: _messages_. Please note -that although the return value of `textdomain' is of type `char *' no -changing is allowed. It is also important to know that no checks of -the availability are made. If the name is not available you will see -this by the fact that no translations are provided. - -To use a domain set by `textdomain' the function - - char *gettext (const char *msgid); - - is to be used. This is the simplest reasonable form one can imagine. -The translation of the string MSGID is returned if it is available in -the current domain. If not available the argument itself is returned. -If the argument is `NULL' the result is undefined. - - One things which should come into mind is that no explicit -dependency to the used domain is given. The current value of the -domain for the `LC_MESSAGES' locale is used. If this changes between -two executions of the same `gettext' call in the program, both calls -reference a different message catalog. - - For the easiest case, which is normally used in internationalized -packages, once at the beginning of execution a call to `textdomain' is -issued, setting the domain to a unique name, normally the package name. -In the following code all strings which have to be translated are -filtered through the gettext function. That's all, the package speaks -your language. - - -File: gettext.info, Node: Ambiguities, Next: Locating Catalogs, Prev: Interface to gettext, Up: gettext - -Solving Ambiguities -------------------- - - While this single name domain work good for most applications there -might be the need to get translations from more than one domain. Of -course one could switch between different domains with calls to -`textdomain', but this is really not convenient nor is it fast. A -possible situation could be one case discussing while this writing: all -error messages of functions in the set of common used functions should -go into a separate domain `error'. By this mean we would only need to -translate them once. - -For this reasons there are two more functions to retrieve strings: - - char *dgettext (const char *domain_name, const char *msgid); - char *dcgettext (const char *domain_name, const char *msgid, - int category); - - Both take an additional argument at the first place, which -corresponds to the argument of `textdomain'. The third argument of -`dcgettext' allows to use another locale but `LC_MESSAGES'. But I -really don't know where this can be useful. If the DOMAIN_NAME is -`NULL' or CATEGORY has an value beside the known ones, the result is -undefined. It should also be noted that this function is not part of -the second known implementation of this function family, the one found -in Solaris. - - A second ambiguity can arise by the fact, that perhaps more than one -domain has the same name. This can be solved by specifying where the -needed message catalog files can be found. - - char *bindtextdomain (const char *domain_name, - const char *dir_name); - - Calling this function binds the given domain to a file in the -specified directory (how this file is determined follows below). -Especially a file in the systems default place is not favored against -the specified file anymore (as it would be by solely using -`textdomain'). A `NULL' pointer for the DIR_NAME parameter returns the -binding associated with DOMAIN_NAME. If DOMAIN_NAME itself is `NULL' -nothing happens and a `NULL' pointer is returned. Here again as for -all the other functions is true that none of the return value must be -changed! - - It is important to remember that relative path names for the -DIR_NAME parameter can be trouble. Since the path is always computed -relative to the current directory different results will be achieved -when the program executes a `chdir' command. Relative paths should -always be avoided to avoid dependencies and unreliabilities. - diff --git a/doc/gettext.info-4 b/doc/gettext.info-4 index bc0214e..8d710c7 100644 --- a/doc/gettext.info-4 +++ b/doc/gettext.info-4 @@ -31,6 +31,142 @@ versions, except that this permission notice may be stated in a translation approved by the Foundation. +File: gettext.info, Node: gettext, Next: Comparison, Prev: catgets, Up: Programmers + +About `gettext' +=============== + + The definition of the `gettext' interface comes from a Uniforum +proposal and it is followed by at least one major Unix vendor (Sun) in +its last developments. It is not specified in any official standard, +though. + + The main points about this solution is that it does not follow the +method of normal file handling (open-use-close) and that it does not +burden the programmer so many task, especially the unique key handling. +Of course here is also a unique key needed, but this key is the message +itself (how long or short it is). See *Note Comparison:: for a more +detailed comparison of the two methods. + + The following section contains a rather detailed description of the +interface. We make it that detailed because this is the interface we +chose for the GNU `gettext' Library. Programmers interested in using +this library will be interested in this description. + +* Menu: + +* Interface to gettext:: The interface +* Ambiguities:: Solving ambiguities +* Locating Catalogs:: Locating message catalog files +* Charset conversion:: How to request conversion to Unicode +* Plural forms:: Additional functions for handling plurals +* GUI program problems:: Another technique for solving ambiguities +* Optimized gettext:: Optimization of the *gettext functions + + +File: gettext.info, Node: Interface to gettext, Next: Ambiguities, Prev: gettext, Up: gettext + +The Interface +------------- + + The minimal functionality an interface must have is a) to select a +domain the strings are coming from (a single domain for all programs is +not reasonable because its construction and maintenance is difficult, +perhaps impossible) and b) to access a string in a selected domain. + + This is principally the description of the `gettext' interface. It +has an global domain which unqualified usages reference. Of course this +domain is selectable by the user. + + char *textdomain (const char *domain_name); + + This provides the possibility to change or query the current status +of the current global domain of the `LC_MESSAGE' category. The +argument is a null-terminated string, whose characters must be legal in +the use in filenames. If the DOMAIN_NAME argument is `NULL', the +function return the current value. If no value has been set before, +the name of the default domain is returned: _messages_. Please note +that although the return value of `textdomain' is of type `char *' no +changing is allowed. It is also important to know that no checks of +the availability are made. If the name is not available you will see +this by the fact that no translations are provided. + +To use a domain set by `textdomain' the function + + char *gettext (const char *msgid); + + is to be used. This is the simplest reasonable form one can imagine. +The translation of the string MSGID is returned if it is available in +the current domain. If not available the argument itself is returned. +If the argument is `NULL' the result is undefined. + + One things which should come into mind is that no explicit +dependency to the used domain is given. The current value of the +domain for the `LC_MESSAGES' locale is used. If this changes between +two executions of the same `gettext' call in the program, both calls +reference a different message catalog. + + For the easiest case, which is normally used in internationalized +packages, once at the beginning of execution a call to `textdomain' is +issued, setting the domain to a unique name, normally the package name. +In the following code all strings which have to be translated are +filtered through the gettext function. That's all, the package speaks +your language. + + +File: gettext.info, Node: Ambiguities, Next: Locating Catalogs, Prev: Interface to gettext, Up: gettext + +Solving Ambiguities +------------------- + + While this single name domain work good for most applications there +might be the need to get translations from more than one domain. Of +course one could switch between different domains with calls to +`textdomain', but this is really not convenient nor is it fast. A +possible situation could be one case discussing while this writing: all +error messages of functions in the set of common used functions should +go into a separate domain `error'. By this mean we would only need to +translate them once. + +For this reasons there are two more functions to retrieve strings: + + char *dgettext (const char *domain_name, const char *msgid); + char *dcgettext (const char *domain_name, const char *msgid, + int category); + + Both take an additional argument at the first place, which +corresponds to the argument of `textdomain'. The third argument of +`dcgettext' allows to use another locale but `LC_MESSAGES'. But I +really don't know where this can be useful. If the DOMAIN_NAME is +`NULL' or CATEGORY has an value beside the known ones, the result is +undefined. It should also be noted that this function is not part of +the second known implementation of this function family, the one found +in Solaris. + + A second ambiguity can arise by the fact, that perhaps more than one +domain has the same name. This can be solved by specifying where the +needed message catalog files can be found. + + char *bindtextdomain (const char *domain_name, + const char *dir_name); + + Calling this function binds the given domain to a file in the +specified directory (how this file is determined follows below). +Especially a file in the systems default place is not favored against +the specified file anymore (as it would be by solely using +`textdomain'). A `NULL' pointer for the DIR_NAME parameter returns the +binding associated with DOMAIN_NAME. If DOMAIN_NAME itself is `NULL' +nothing happens and a `NULL' pointer is returned. Here again as for +all the other functions is true that none of the return value must be +changed! + + It is important to remember that relative path names for the +DIR_NAME parameter can be trouble. Since the path is always computed +relative to the current directory different results will be achieved +when the program executes a `chdir' command. Relative paths should +always be avoided to avoid dependencies and unreliabilities. + + File: gettext.info, Node: Locating Catalogs, Next: Charset conversion, Prev: Ambiguities, Up: gettext Locating Message Catalog Files @@ -211,7 +347,7 @@ purpose. An example for the us of this function is: - printf (ngettext ("%d file removed", "%d files removed", n), n); + printf (ngettext ("%d file removed", "%d files removed", n), n); Please note that the numeric value N has to be passed to the `printf' function as well. It is not sufficient to pass it only to @@ -246,10 +382,10 @@ details are explained in the GNU `gettext' manual. Here only a a bit of information is provided. The information about the plural form selection has to be stored in -the header entry (the one with the empty `msgid' string). There should -be something like: +the header entry of the PO file (the one with the empty `msgid' string). +The plural form information looks like this: - nplurals=2; plural=n == 1 ? 0 : 1 + Plural-Forms: nplurals=2; plural=n == 1 ? 0 : 1; The `nplurals' value must be a decimal number which specifies how many different plural forms exist for this language. The string @@ -272,7 +408,7 @@ Only one form: distinction between the singular and plural form. An appropriate header entry would look like this: - nplurals=1; plural=0 + Plural-Forms: nplurals=1; plural=0; Languages with this property include: @@ -289,7 +425,7 @@ 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: - nplurals=2; plural=n != 1 + Plural-Forms: nplurals=2; plural=n != 1; (Note: this uses the feature of C expressions that boolean expressions have to value zero or one.) @@ -318,7 +454,7 @@ Two forms, singular used for zero and one Exceptional case in the language family. The header entry would be: - nplurals=2; plural=n>1 + Plural-Forms: nplurals=2; plural=n>1; Languages with this property include: @@ -328,7 +464,7 @@ Two forms, singular used for zero and one Three forms, special cases for one and two The header entry would be: - nplurals=3; plural=n==1 ? 0 : n==2 ? 1 : 2 + Plural-Forms: nplurals=3; plural=n==1 ? 0 : n==2 ? 1 : 2; Languages with this property include: @@ -338,7 +474,8 @@ Three forms, special cases for one and two Three forms, special case for one and all numbers ending in 2, 3, or 4 The header entry would look like this: - nplurals=3; plural=n==1 ? 0 : n%10>=2 && n%10<=4 ? 1 : 2 + Plural-Forms: nplurals=3; \ + plural=n==1 ? 0 : n%10>=2 && n%10<=4 ? 1 : 2; Languages with this property include: @@ -348,8 +485,9 @@ Three forms, special case for one and all numbers ending in 2, 3, or 4 Three forms, special case for one and some numbers ending in 2, 3, or 4 The header entry would look like this: - nplurals=3; plural=n==1 ? 0 : \ - n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2 + Plural-Forms: nplurals=3; \ + plural=n==1 ? 0 : \ + n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2; (Continuation in the next line is possible.) @@ -361,7 +499,9 @@ Three forms, special case for one and some numbers ending in 2, 3, or 4 Four forms, special case for one and all numbers ending in 2, 3, or 4 The header entry would look like this: - nplurals=4; plural=n==1 ? 0 : n%10==2 ? 1 : n%10==3 || n%10==4 ? 2 : 3 + Plural-Forms: nplurals=4; \ + plural=n==1 ? 0 : \ + n%10==2 ? 1 : n%10==3 || n%10==4 ? 2 : 3; Languages with this property include: @@ -635,11 +775,11 @@ self-contained. I.e., you can use it in your own programs without providing additional functions. The `Makefile' will put the header and the library in directories selected using the `$(prefix)'. - One exception of the above is found on HP-UX systems. Here the C -library does not contain the `alloca' function (and the HP compiler does -not generate it inlined). But it is not intended to rewrite the whole -library just because of this dumb system. Instead include the `alloca' -function in all package you use the `libintl.a' in. + One exception of the above is found on HP-UX 10.01 systems. Here +the C library does not contain the `alloca' function (and the HP +compiler does not generate it inlined). But it is not intended to +rewrite the whole library just because of this dumb system. Instead +include the `alloca' function in all package you use the `libintl.a' in. File: gettext.info, Node: gettext grok, Next: Temp Programmers, Prev: Using libintl.a, Up: Programmers @@ -1013,170 +1153,3 @@ concerns. Some of these doubts are presented and discussed, here. the localization routines themselves. - -File: gettext.info, Node: Organization, Next: Information Flow, Prev: Discussions, Up: Translators - -Organization -============ - - On a larger scale, the true solution would be to organize some kind -of fairly precise set up in which volunteers could participate. I gave -some thought to this idea lately, and realize there will be some touchy -points. I thought of writing to Richard Stallman to launch such a -project, but feel it might be good to shake out the ideas between -ourselves first. Most probably that Linux International has some -experience in the field already, or would like to orchestrate the -volunteer work, maybe. Food for thought, in any case! - - I guess we have to setup something early, somehow, that will help -many possible contributors of the same language to interlock and avoid -work duplication, and further be put in contact for solving together -problems particular to their tongue (in most languages, there are many -difficulties peculiar to translating technical English). My Swedish -contributor acknowledged these difficulties, and I'm well aware of them -for French. - - This is surely not a technical issue, but we should manage so the -effort of locale contributors be maximally useful, despite the national -team layer interface between contributors and maintainers. - - The Translation Project needs some setup for coordinating language -coordinators. Localizing evolving programs will surely become a -permanent and continuous activity in the free software community, once -well started. The setup should be minimally completed and tested -before GNU `gettext' becomes an official reality. The e-mail address -`translation@iro.umontreal.ca' has been setup for receiving offers from -volunteers and general e-mail on these topics. This address reaches -the Translation Project coordinator. - -* Menu: - -* Central Coordination:: Central Coordination -* National Teams:: National Teams -* Mailing Lists:: Mailing Lists - - -File: gettext.info, Node: Central Coordination, Next: National Teams, Prev: Organization, Up: Organization - -Central Coordination --------------------- - - I also think GNU will need sooner than it thinks, that someone setup -a way to organize and coordinate these groups. Some kind of group of -groups. My opinion is that it would be good that GNU delegates this -task to a small group of collaborating volunteers, shortly. Perhaps in -`gnu.announce' a list of this national committee's can be published. - - My role as coordinator would simply be to refer to Ulrich any German -speaking volunteer interested to localization of free software -packages, and maybe helping national groups to initially organize, -while maintaining national registries for until national groups are -ready to take over. In fact, the coordinator should ease volunteers to -get in contact with one another for creating national teams, which -should then select one coordinator per language, or country -(regionalized language). If well done, the coordination should be -useful without being an overwhelming task, the time to put delegations -in place. - - -File: gettext.info, Node: National Teams, Next: Mailing Lists, Prev: Central Coordination, Up: Organization - -National Teams --------------- - - I suggest we look for volunteer coordinators/editors for individual -languages. These people will scan contributions of translation files -for various programs, for their own languages, and will ensure high and -uniform standards of diction. - - From my current experience with other people in these days, those who -provide localizations are very enthusiastic about the process, and are -more interested in the localization process than in the program they -localize, and want to do many programs, not just one. This seems to -confirm that having a coordinator/editor for each language is a good -idea. - - We need to choose someone who is good at writing clear and concise -prose in the language in question. That is hard--we can't check it -ourselves. So we need to ask a few people to judge each others' -writing and select the one who is best. - - I announce my prerelease to a few dozen people, and you would not -believe all the discussions it generated already. I shudder to think -what will happen when this will be launched, for true, officially, -world wide. Who am I to arbitrate between two Czekolsovak users -contradicting each other, for example? - - I assume that your German is not much better than my French so that -I would not be able to judge about these formulations. What I would -suggest is that for each language there is a group for people who -maintain the PO files and judge about changes. I suspect there will be -cultural differences between how such groups of people will behave. -Some will have relaxed ways, reach consensus easily, and have anyone of -the group relate to the maintainers, while others will fight to death, -organize heavy administrations up to national standards, and use strict -channels. - - The German team is putting out a good example. Right now, they are -maybe half a dozen people revising translations of each other and -discussing the linguistic issues. I do not even have all the names. -Ulrich Drepper is taking care of coordinating the German team. He -subscribed to all my pretest lists, so I do not even have to warn him -specifically of incoming releases. - - I'm sure, that is a good idea to get teams for each language working -on translations. That will make the translations better and more -consistent. - -* Menu: - -* Sub-Cultures:: Sub-Cultures -* Organizational Ideas:: Organizational Ideas - - -File: gettext.info, Node: Sub-Cultures, Next: Organizational Ideas, Prev: National Teams, Up: National Teams - -Sub-Cultures -............ - - Taking French for example, there are a few sub-cultures around -computers which developed diverging vocabularies. Picking volunteers -here and there without addressing this problem in an organized way, -soon in the project, might produce a distasteful mix of -internationalized programs, and possibly trigger endless quarrels among -those who really care. - - Keeping some kind of unity in the way French localization of -internationalized programs is achieved is a difficult (and delicate) -job. Knowing the latin character of French people (:-), if we take this -the wrong way, we could end up nowhere, or spoil a lot of energies. -Maybe we should begin to address this problem seriously _before_ GNU -`gettext' become officially published. And I suspect that this means -soon! - - -File: gettext.info, Node: Organizational Ideas, Prev: Sub-Cultures, Up: National Teams - -Organizational Ideas -.................... - - I expect the next big changes after the official release. Please -note that I use the German translation of the short GPL message. We -need to set a few good examples before the localization goes out for -true in the free software community. Here are a few points to discuss: - - * Each group should have one FTP server (at least one master). - - * The files on the server should reflect the latest version (of - course!) and it should also contain a RCS directory with the - corresponding archives (I don't have this now). - - * There should also be a ChangeLog file (this is more useful than the - RCS archive but can be generated automatically from the later by - Emacs). - - * A "core group" should judge about questionable changes (for now - this group consists solely by me but I ask some others - occasionally; this also seems to work). - - diff --git a/doc/gettext.info-5 b/doc/gettext.info-5 index 03411a4..dcdf5eb 100644 --- a/doc/gettext.info-5 +++ b/doc/gettext.info-5 @@ -31,6 +31,173 @@ versions, except that this permission notice may be stated in a translation approved by the Foundation. +File: gettext.info, Node: Organization, Next: Information Flow, Prev: Discussions, Up: Translators + +Organization +============ + + On a larger scale, the true solution would be to organize some kind +of fairly precise set up in which volunteers could participate. I gave +some thought to this idea lately, and realize there will be some touchy +points. I thought of writing to Richard Stallman to launch such a +project, but feel it might be good to shake out the ideas between +ourselves first. Most probably that Linux International has some +experience in the field already, or would like to orchestrate the +volunteer work, maybe. Food for thought, in any case! + + I guess we have to setup something early, somehow, that will help +many possible contributors of the same language to interlock and avoid +work duplication, and further be put in contact for solving together +problems particular to their tongue (in most languages, there are many +difficulties peculiar to translating technical English). My Swedish +contributor acknowledged these difficulties, and I'm well aware of them +for French. + + This is surely not a technical issue, but we should manage so the +effort of locale contributors be maximally useful, despite the national +team layer interface between contributors and maintainers. + + The Translation Project needs some setup for coordinating language +coordinators. Localizing evolving programs will surely become a +permanent and continuous activity in the free software community, once +well started. The setup should be minimally completed and tested +before GNU `gettext' becomes an official reality. The e-mail address +`translation@iro.umontreal.ca' has been setup for receiving offers from +volunteers and general e-mail on these topics. This address reaches +the Translation Project coordinator. + +* Menu: + +* Central Coordination:: Central Coordination +* National Teams:: National Teams +* Mailing Lists:: Mailing Lists + + +File: gettext.info, Node: Central Coordination, Next: National Teams, Prev: Organization, Up: Organization + +Central Coordination +-------------------- + + I also think GNU will need sooner than it thinks, that someone setup +a way to organize and coordinate these groups. Some kind of group of +groups. My opinion is that it would be good that GNU delegates this +task to a small group of collaborating volunteers, shortly. Perhaps in +`gnu.announce' a list of this national committee's can be published. + + My role as coordinator would simply be to refer to Ulrich any German +speaking volunteer interested to localization of free software +packages, and maybe helping national groups to initially organize, +while maintaining national registries for until national groups are +ready to take over. In fact, the coordinator should ease volunteers to +get in contact with one another for creating national teams, which +should then select one coordinator per language, or country +(regionalized language). If well done, the coordination should be +useful without being an overwhelming task, the time to put delegations +in place. + + +File: gettext.info, Node: National Teams, Next: Mailing Lists, Prev: Central Coordination, Up: Organization + +National Teams +-------------- + + I suggest we look for volunteer coordinators/editors for individual +languages. These people will scan contributions of translation files +for various programs, for their own languages, and will ensure high and +uniform standards of diction. + + From my current experience with other people in these days, those who +provide localizations are very enthusiastic about the process, and are +more interested in the localization process than in the program they +localize, and want to do many programs, not just one. This seems to +confirm that having a coordinator/editor for each language is a good +idea. + + We need to choose someone who is good at writing clear and concise +prose in the language in question. That is hard--we can't check it +ourselves. So we need to ask a few people to judge each others' +writing and select the one who is best. + + I announce my prerelease to a few dozen people, and you would not +believe all the discussions it generated already. I shudder to think +what will happen when this will be launched, for true, officially, +world wide. Who am I to arbitrate between two Czekolsovak users +contradicting each other, for example? + + I assume that your German is not much better than my French so that +I would not be able to judge about these formulations. What I would +suggest is that for each language there is a group for people who +maintain the PO files and judge about changes. I suspect there will be +cultural differences between how such groups of people will behave. +Some will have relaxed ways, reach consensus easily, and have anyone of +the group relate to the maintainers, while others will fight to death, +organize heavy administrations up to national standards, and use strict +channels. + + The German team is putting out a good example. Right now, they are +maybe half a dozen people revising translations of each other and +discussing the linguistic issues. I do not even have all the names. +Ulrich Drepper is taking care of coordinating the German team. He +subscribed to all my pretest lists, so I do not even have to warn him +specifically of incoming releases. + + I'm sure, that is a good idea to get teams for each language working +on translations. That will make the translations better and more +consistent. + +* Menu: + +* Sub-Cultures:: Sub-Cultures +* Organizational Ideas:: Organizational Ideas + + +File: gettext.info, Node: Sub-Cultures, Next: Organizational Ideas, Prev: National Teams, Up: National Teams + +Sub-Cultures +............ + + Taking French for example, there are a few sub-cultures around +computers which developed diverging vocabularies. Picking volunteers +here and there without addressing this problem in an organized way, +soon in the project, might produce a distasteful mix of +internationalized programs, and possibly trigger endless quarrels among +those who really care. + + Keeping some kind of unity in the way French localization of +internationalized programs is achieved is a difficult (and delicate) +job. Knowing the latin character of French people (:-), if we take this +the wrong way, we could end up nowhere, or spoil a lot of energies. +Maybe we should begin to address this problem seriously _before_ GNU +`gettext' become officially published. And I suspect that this means +soon! + + +File: gettext.info, Node: Organizational Ideas, Prev: Sub-Cultures, Up: National Teams + +Organizational Ideas +.................... + + I expect the next big changes after the official release. Please +note that I use the German translation of the short GPL message. We +need to set a few good examples before the localization goes out for +true in the free software community. Here are a few points to discuss: + + * Each group should have one FTP server (at least one master). + + * The files on the server should reflect the latest version (of + course!) and it should also contain a RCS directory with the + corresponding archives (I don't have this now). + + * There should also be a ChangeLog file (this is more useful than the + RCS archive but can be generated automatically from the later by + Emacs). + + * A "core group" should judge about questionable changes (for now + this group consists solely by me but I ask some others + occasionally; this also seems to work). + + + File: gettext.info, Node: Mailing Lists, Prev: National Teams, Up: Organization Mailing Lists @@ -164,23 +331,19 @@ functions meant to replace or complement C libraries, and a subdirectory `src/' for holding the proper sources for the package. These other distributions are said to be "non-flat". - For now, we cannot say much about flat distributions. A flat -directory structure has the disadvantage of increasing the difficulty -of updating to a new version of GNU `gettext'. Also, if you have many -PO files, this could somewhat pollute your single directory. In the -GNU `gettext' distribution, the `misc/' directory contains a shell -script named `combine-sh'. That script may be used for combining all -the C files of the `intl/' directory into a pair of C files (one `.c' -and one `.h'). Those two generated files would fit more easily in a -flat directory structure, and you will then have to add these two files -to your project. + We cannot say much about flat distributions. A flat directory +structure has the disadvantage of increasing the difficulty of updating +to a new version of GNU `gettext'. Also, if you have many PO files, +this could somewhat pollute your single directory. Also, GNU +`gettext''s libintl sources consist of C sources, shell scripts, `sed' +scripts and complicated Makefile rules, which don't fit well into an +existing flat structure. For these reasons, we recommend to use +non-flat approach in this case as well. Maybe because GNU `gettext' itself has a non-flat structure, we have more experience with this approach, and this is what will be described in the remaining of this chapter. Some maintainers might use this as -an opportunity to unflatten their package structure. Only later, once -gained more experience adapting GNU `gettext' to flat distributions, we -might add some notes about how to proceed in flat situations. +an opportunity to unflatten their package structure. File: gettext.info, Node: Prerequisites, Next: gettextize Invocation, Prev: Flat and Non-Flat, Up: Maintainers diff --git a/doc/version.texi b/doc/version.texi index 757ecb3..bda6d12 100644 --- a/doc/version.texi +++ b/doc/version.texi @@ -1,3 +1,3 @@ -@set UPDATED 11 March 2001 +@set UPDATED 29 March 2001 @set EDITION 0.10.36 @set VERSION 0.10.36 |