1<HTML> 2<HEAD> 3<!-- This HTML file has been created by texi2html 1.52b 4 from gettext.texi on 27 November 2006 --> 5 6<META HTTP-EQUIV="content-type" CONTENT="text/html; charset=UTF-8"> 7<TITLE>GNU gettext utilities - 1 Introduction</TITLE> 8</HEAD> 9<BODY> 10Go to the first, previous, <A HREF="gettext_2.html">next</A>, <A HREF="gettext_25.html">last</A> section, <A HREF="gettext_toc.html">table of contents</A>. 11<P><HR><P> 12 13 14 15<H1><A NAME="SEC1" HREF="gettext_toc.html#TOC1">1 Introduction</A></H1> 16 17<P> 18This chapter explains the goals sought in the creation 19of GNU <CODE>gettext</CODE> and the free Translation Project. 20Then, it explains a few broad concepts around 21Native Language Support, and positions message translation with regard 22to other aspects of national and cultural variance, as they apply 23to programs. It also surveys those files used to convey the 24translations. It explains how the various tools interact in the 25initial generation of these files, and later, how the maintenance 26cycle should usually operate. 27 28</P> 29<P> 30<A NAME="IDX1"></A> 31<A NAME="IDX2"></A> 32<A NAME="IDX3"></A> 33In this manual, we use <EM>he</EM> when speaking of the programmer or 34maintainer, <EM>she</EM> when speaking of the translator, and <EM>they</EM> 35when speaking of the installers or end users of the translated program. 36This is only a convenience for clarifying the documentation. It is 37<EM>absolutely</EM> not meant to imply that some roles are more appropriate 38to males or females. Besides, as you might guess, GNU <CODE>gettext</CODE> 39is meant to be useful for people using computers, whatever their sex, 40race, religion or nationality! 41 42</P> 43<P> 44<A NAME="IDX4"></A> 45Please send suggestions and corrections to: 46 47</P> 48 49<PRE> 50Internet address: 51 bug-gnu-gettext@gnu.org 52</PRE> 53 54<P> 55Please include the manual's edition number and update date in your messages. 56 57</P> 58 59 60 61<H2><A NAME="SEC2" HREF="gettext_toc.html#TOC2">1.1 The Purpose of GNU <CODE>gettext</CODE></A></H2> 62 63<P> 64Usually, programs are written and documented in English, and use 65English at execution time to interact with users. This is true 66not only of GNU software, but also of a great deal of commercial 67and free software. Using a common language is quite handy for 68communication between developers, maintainers and users from all 69countries. On the other hand, most people are less comfortable with 70English than with their own native language, and would prefer to 71use their mother tongue for day to day's work, as far as possible. 72Many would simply <EM>love</EM> to see their computer screen showing 73a lot less of English, and far more of their own language. 74 75</P> 76<P> 77<A NAME="IDX5"></A> 78However, to many people, this dream might appear so far fetched that 79they may believe it is not even worth spending time thinking about 80it. They have no confidence at all that the dream might ever 81become true. Yet some have not lost hope, and have organized themselves. 82The Translation Project is a formalization of this hope into a 83workable structure, which has a good chance to get all of us nearer 84the achievement of a truly multi-lingual set of programs. 85 86</P> 87<P> 88GNU <CODE>gettext</CODE> is an important step for the Translation Project, 89as it is an asset on which we may build many other steps. This package 90offers to programmers, translators and even users, a well integrated 91set of tools and documentation. Specifically, the GNU <CODE>gettext</CODE> 92utilities are a set of tools that provides a framework within which 93other free packages may produce multi-lingual messages. These tools 94include 95 96</P> 97 98<UL> 99<LI> 100 101A set of conventions about how programs should be written to support 102message catalogs. 103 104<LI> 105 106A directory and file naming organization for the message catalogs 107themselves. 108 109<LI> 110 111A runtime library supporting the retrieval of translated messages. 112 113<LI> 114 115A few stand-alone programs to massage in various ways the sets of 116translatable strings, or already translated strings. 117 118<LI> 119 120A library supporting the parsing and creation of files containing 121translated messages. 122 123<LI> 124 125A special mode for Emacs<A NAME="DOCF1" HREF="gettext_foot.html#FOOT1">(1)</A> which helps preparing these sets 126and bringing them up to date. 127</UL> 128 129<P> 130GNU <CODE>gettext</CODE> is designed to minimize the impact of 131internationalization on program sources, keeping this impact as small 132and hardly noticeable as possible. Internationalization has better 133chances of succeeding if it is very light weighted, or at least, 134appear to be so, when looking at program sources. 135 136</P> 137<P> 138The Translation Project also uses the GNU <CODE>gettext</CODE> distribution 139as a vehicle for documenting its structure and methods. This goes 140beyond the strict technicalities of documenting the GNU <CODE>gettext</CODE> 141proper. By so doing, translators will find in a single place, as 142far as possible, all they need to know for properly doing their 143translating work. Also, this supplemental documentation might also 144help programmers, and even curious users, in understanding how GNU 145<CODE>gettext</CODE> is related to the remainder of the Translation 146Project, and consequently, have a glimpse at the <EM>big picture</EM>. 147 148</P> 149 150 151<H2><A NAME="SEC3" HREF="gettext_toc.html#TOC3">1.2 I18n, L10n, and Such</A></H2> 152 153<P> 154<A NAME="IDX6"></A> 155<A NAME="IDX7"></A> 156Two long words appear all the time when we discuss support of native 157language in programs, and these words have a precise meaning, worth 158being explained here, once and for all in this document. The words are 159<EM>internationalization</EM> and <EM>localization</EM>. Many people, 160tired of writing these long words over and over again, took the 161habit of writing <EM>i18n</EM> and <EM>l10n</EM> instead, quoting the first 162and last letter of each word, and replacing the run of intermediate 163letters by a number merely telling how many such letters there are. 164But in this manual, in the sake of clarity, we will patiently write 165the names in full, each time... 166 167</P> 168<P> 169<A NAME="IDX8"></A> 170By <EM>internationalization</EM>, one refers to the operation by which a 171program, or a set of programs turned into a package, is made aware of and 172able to support multiple languages. This is a generalization process, 173by which the programs are untied from calling only English strings or 174other English specific habits, and connected to generic ways of doing 175the same, instead. Program developers may use various techniques to 176internationalize their programs. Some of these have been standardized. 177GNU <CODE>gettext</CODE> offers one of these standards. See section <A HREF="gettext_11.html#SEC164">11 The Programmer's View</A>. 178 179</P> 180<P> 181<A NAME="IDX9"></A> 182By <EM>localization</EM>, one means the operation by which, in a set 183of programs already internationalized, one gives the program all 184needed information so that it can adapt itself to handle its input 185and output in a fashion which is correct for some native language and 186cultural habits. This is a particularisation process, by which generic 187methods already implemented in an internationalized program are used 188in specific ways. The programming environment puts several functions 189to the programmers disposal which allow this runtime configuration. 190The formal description of specific set of cultural habits for some 191country, together with all associated translations targeted to the 192same native language, is called the <EM>locale</EM> for this language 193or country. Users achieve localization of programs by setting proper 194values to special environment variables, prior to executing those 195programs, identifying which locale should be used. 196 197</P> 198<P> 199In fact, locale message support is only one component of the cultural 200data that makes up a particular locale. There are a whole host of 201routines and functions provided to aid programmers in developing 202internationalized software and which allow them to access the data 203stored in a particular locale. When someone presently refers to a 204particular locale, they are obviously referring to the data stored 205within that particular locale. Similarly, if a programmer is referring 206to “accessing the locale routines”, they are referring to the 207complete suite of routines that access all of the locale's information. 208 209</P> 210<P> 211<A NAME="IDX10"></A> 212<A NAME="IDX11"></A> 213<A NAME="IDX12"></A> 214One uses the expression <EM>Native Language Support</EM>, or merely NLS, 215for speaking of the overall activity or feature encompassing both 216internationalization and localization, allowing for multi-lingual 217interactions in a program. In a nutshell, one could say that 218internationalization is the operation by which further localizations 219are made possible. 220 221</P> 222<P> 223Also, very roughly said, when it comes to multi-lingual messages, 224internationalization is usually taken care of by programmers, and 225localization is usually taken care of by translators. 226 227</P> 228 229 230<H2><A NAME="SEC4" HREF="gettext_toc.html#TOC4">1.3 Aspects in Native Language Support</A></H2> 231 232<P> 233<A NAME="IDX13"></A> 234For a totally multi-lingual distribution, there are many things to 235translate beyond output messages. 236 237</P> 238 239<UL> 240<LI> 241 242As of today, GNU <CODE>gettext</CODE> offers a complete toolset for 243translating messages output by C programs. Perl scripts and shell 244scripts will also need to be translated. Even if there are today some hooks 245by which this can be done, these hooks are not integrated as well as they 246should be. 247 248<LI> 249 250Some programs, like <CODE>autoconf</CODE> or <CODE>bison</CODE>, are able 251to produce other programs (or scripts). Even if the generating 252programs themselves are internationalized, the generated programs they 253produce may need internationalization on their own, and this indirect 254internationalization could be automated right from the generating 255program. In fact, quite usually, generating and generated programs 256could be internationalized independently, as the effort needed is 257fairly orthogonal. 258 259<LI> 260 261A few programs include textual tables which might need translation 262themselves, independently of the strings contained in the program 263itself. For example, RFC 1345 gives an English description for each 264character which the <CODE>recode</CODE> program is able to reconstruct at execution. 265Since these descriptions are extracted from the RFC by mechanical means, 266translating them properly would require a prior translation of the RFC 267itself. 268 269<LI> 270 271Almost all programs accept options, which are often worded out so to 272be descriptive for the English readers; one might want to consider 273offering translated versions for program options as well. 274 275<LI> 276 277Many programs read, interpret, compile, or are somewhat driven by 278input files which are texts containing keywords, identifiers, or 279replies which are inherently translatable. For example, one may want 280<CODE>gcc</CODE> to allow diacriticized characters in identifiers or use 281translated keywords; <SAMP>‘rm -i’</SAMP> might accept something else than 282<SAMP>‘y’</SAMP> or <SAMP>‘n’</SAMP> for replies, etc. Even if the program will 283eventually make most of its output in the foreign languages, one has 284to decide whether the input syntax, option values, etc., are to be 285localized or not. 286 287<LI> 288 289The manual accompanying a package, as well as all documentation files 290in the distribution, could surely be translated, too. Translating a 291manual, with the intent of later keeping up with updates, is a major 292undertaking in itself, generally. 293 294</UL> 295 296<P> 297As we already stressed, translation is only one aspect of locales. 298Other internationalization aspects are system services and are handled 299in GNU <CODE>libc</CODE>. There 300are many attributes that are needed to define a country's cultural 301conventions. These attributes include beside the country's native 302language, the formatting of the date and time, the representation of 303numbers, the symbols for currency, etc. These local <EM>rules</EM> are 304termed the country's locale. The locale represents the knowledge 305needed to support the country's native attributes. 306 307</P> 308<P> 309<A NAME="IDX14"></A> 310There are a few major areas which may vary between countries and 311hence, define what a locale must describe. The following list helps 312putting multi-lingual messages into the proper context of other tasks 313related to locales. See the GNU <CODE>libc</CODE> manual for details. 314 315</P> 316<DL COMPACT> 317 318<DT><EM>Characters and Codesets</EM> 319<DD> 320<A NAME="IDX15"></A> 321<A NAME="IDX16"></A> 322<A NAME="IDX17"></A> 323<A NAME="IDX18"></A> 324 325The codeset most commonly used through out the USA and most English 326speaking parts of the world is the ASCII codeset. However, there are 327many characters needed by various locales that are not found within 328this codeset. The 8-bit ISO 8859-1 code set has most of the special 329characters needed to handle the major European languages. However, in 330many cases, choosing ISO 8859-1 is nevertheless not adequate: it 331doesn't even handle the major European currency. Hence each locale 332will need to specify which codeset they need to use and will need 333to have the appropriate character handling routines to cope with 334the codeset. 335 336<DT><EM>Currency</EM> 337<DD> 338<A NAME="IDX19"></A> 339<A NAME="IDX20"></A> 340 341The symbols used vary from country to country as does the position 342used by the symbol. Software needs to be able to transparently 343display currency figures in the native mode for each locale. 344 345<DT><EM>Dates</EM> 346<DD> 347<A NAME="IDX21"></A> 348<A NAME="IDX22"></A> 349 350The format of date varies between locales. For example, Christmas day 351in 1994 is written as 12/25/94 in the USA and as 25/12/94 in Australia. 352Other countries might use ISO 8601 dates, etc. 353 354Time of the day may be noted as <VAR>hh</VAR>:<VAR>mm</VAR>, <VAR>hh</VAR>.<VAR>mm</VAR>, 355or otherwise. Some locales require time to be specified in 24-hour 356mode rather than as AM or PM. Further, the nature and yearly extent 357of the Daylight Saving correction vary widely between countries. 358 359<DT><EM>Numbers</EM> 360<DD> 361<A NAME="IDX23"></A> 362<A NAME="IDX24"></A> 363 364Numbers can be represented differently in different locales. 365For example, the following numbers are all written correctly for 366their respective locales: 367 368 369<PRE> 37012,345.67 English 37112.345,67 German 372 12345,67 French 3731,2345.67 Asia 374</PRE> 375 376Some programs could go further and use different unit systems, like 377English units or Metric units, or even take into account variants 378about how numbers are spelled in full. 379 380<DT><EM>Messages</EM> 381<DD> 382<A NAME="IDX25"></A> 383<A NAME="IDX26"></A> 384 385The most obvious area is the language support within a locale. This is 386where GNU <CODE>gettext</CODE> provides the means for developers and users to 387easily change the language that the software uses to communicate to 388the user. 389 390</DL> 391 392<P> 393<A NAME="IDX27"></A> 394Components of locale outside of message handling are standardized in 395the ISO C standard and the SUSV2 specification. GNU <CODE>libc</CODE> 396fully implements this, and most other modern systems provide a more 397or less reasonable support for at least some of the missing components. 398 399</P> 400 401 402<H2><A NAME="SEC5" HREF="gettext_toc.html#TOC5">1.4 Files Conveying Translations</A></H2> 403 404<P> 405<A NAME="IDX28"></A> 406The letters PO in <TT>‘.po’</TT> files means Portable Object, to 407distinguish it from <TT>‘.mo’</TT> files, where MO stands for Machine 408Object. This paradigm, as well as the PO file format, is inspired 409by the NLS standard developed by Uniforum, and first implemented by 410Sun in their Solaris system. 411 412</P> 413<P> 414PO files are meant to be read and edited by humans, and associate each 415original, translatable string of a given package with its translation 416in a particular target language. A single PO file is dedicated to 417a single target language. If a package supports many languages, 418there is one such PO file per language supported, and each package 419has its own set of PO files. These PO files are best created by 420the <CODE>xgettext</CODE> program, and later updated or refreshed through 421the <CODE>msgmerge</CODE> program. Program <CODE>xgettext</CODE> extracts all 422marked messages from a set of C files and initializes a PO file with 423empty translations. Program <CODE>msgmerge</CODE> takes care of adjusting 424PO files between releases of the corresponding sources, commenting 425obsolete entries, initializing new ones, and updating all source 426line references. Files ending with <TT>‘.pot’</TT> are kind of base 427translation files found in distributions, in PO file format. 428 429</P> 430<P> 431MO files are meant to be read by programs, and are binary in nature. 432A few systems already offer tools for creating and handling MO files 433as part of the Native Language Support coming with the system, but the 434format of these MO files is often different from system to system, 435and non-portable. The tools already provided with these systems don't 436support all the features of GNU <CODE>gettext</CODE>. Therefore GNU 437<CODE>gettext</CODE> uses its own format for MO files. Files ending with 438<TT>‘.gmo’</TT> are really MO files, when it is known that these files use 439the GNU format. 440 441</P> 442 443 444<H2><A NAME="SEC6" HREF="gettext_toc.html#TOC6">1.5 Overview of GNU <CODE>gettext</CODE></A></H2> 445 446<P> 447<A NAME="IDX29"></A> 448<A NAME="IDX30"></A> 449<A NAME="IDX31"></A> 450The following diagram summarizes the relation between the files 451handled by GNU <CODE>gettext</CODE> and the tools acting on these files. 452It is followed by somewhat detailed explanations, which you should 453read while keeping an eye on the diagram. Having a clear understanding 454of these interrelations will surely help programmers, translators 455and maintainers. 456 457</P> 458 459<PRE> 460@group 461Original C Sources ───> Preparation ───> Marked C Sources ───╮ 462 │ 463 ╭─────────<─── GNU gettext Library │ 464╭─── make <───┤ │ 465│ ╰─────────<────────────────────┬───────────────╯ 466│ │ 467│ ╭─────<─── PACKAGE.pot <─── xgettext <───╯ ╭───<─── PO Compendium 468│ │ │ ↑ 469│ │ ╰───╮ │ 470│ ╰───╮ ├───> PO editor ───╮ 471│ ├────> msgmerge ──────> LANG.po ────>────────╯ │ 472│ ╭───╯ │ 473│ │ │ 474│ ╰─────────────<───────────────╮ │ 475│ ├─── New LANG.po <────────────────────╯ 476│ ╭─── LANG.gmo <─── msgfmt <───╯ 477│ │ 478│ ╰───> install ───> /.../LANG/PACKAGE.mo ───╮ 479│ ├───> "Hello world!" 480╰───────> install ───> /.../bin/PROGRAM ───────╯ 481@end group 482</PRE> 483 484<P> 485<A NAME="IDX32"></A> 486As a programmer, the first step to bringing GNU <CODE>gettext</CODE> 487into your package is identifying, right in the C sources, those strings 488which are meant to be translatable, and those which are untranslatable. 489This tedious job can be done a little more comfortably using emacs PO 490mode, but you can use any means familiar to you for modifying your 491C sources. Beside this some other simple, standard changes are needed to 492properly initialize the translation library. See section <A HREF="gettext_4.html#SEC11">4 Preparing Program Sources</A>, for 493more information about all this. 494 495</P> 496<P> 497For newly written software the strings of course can and should be 498marked while writing it. The <CODE>gettext</CODE> approach makes this 499very easy. Simply put the following lines at the beginning of each file 500or in a central header file: 501 502</P> 503 504<PRE> 505#define _(String) (String) 506#define N_(String) String 507#define textdomain(Domain) 508#define bindtextdomain(Package, Directory) 509</PRE> 510 511<P> 512Doing this allows you to prepare the sources for internationalization. 513Later when you feel ready for the step to use the <CODE>gettext</CODE> library 514simply replace these definitions by the following: 515 516</P> 517<P> 518<A NAME="IDX33"></A> 519 520<PRE> 521#include <libintl.h> 522#define _(String) gettext (String) 523#define gettext_noop(String) String 524#define N_(String) gettext_noop (String) 525</PRE> 526 527<P> 528<A NAME="IDX34"></A> 529<A NAME="IDX35"></A> 530and link against <TT>‘libintl.a’</TT> or <TT>‘libintl.so’</TT>. Note that on 531GNU systems, you don't need to link with <CODE>libintl</CODE> because the 532<CODE>gettext</CODE> library functions are already contained in GNU libc. 533That is all you have to change. 534 535</P> 536<P> 537<A NAME="IDX36"></A> 538<A NAME="IDX37"></A> 539Once the C sources have been modified, the <CODE>xgettext</CODE> program 540is used to find and extract all translatable strings, and create a 541PO template file out of all these. This <TT>‘<VAR>package</VAR>.pot’</TT> file 542contains all original program strings. It has sets of pointers to 543exactly where in C sources each string is used. All translations 544are set to empty. The letter <CODE>t</CODE> in <TT>‘.pot’</TT> marks this as 545a Template PO file, not yet oriented towards any particular language. 546See section <A HREF="gettext_5.html#SEC22">5.1 Invoking the <CODE>xgettext</CODE> Program</A>, for more details about how one calls the 547<CODE>xgettext</CODE> program. If you are <EM>really</EM> lazy, you might 548be interested at working a lot more right away, and preparing the 549whole distribution setup (see section <A HREF="gettext_13.html#SEC196">13 The Maintainer's View</A>). By doing so, you 550spare yourself typing the <CODE>xgettext</CODE> command, as <CODE>make</CODE> 551should now generate the proper things automatically for you! 552 553</P> 554<P> 555The first time through, there is no <TT>‘<VAR>lang</VAR>.po’</TT> yet, so the 556<CODE>msgmerge</CODE> step may be skipped and replaced by a mere copy of 557<TT>‘<VAR>package</VAR>.pot’</TT> to <TT>‘<VAR>lang</VAR>.po’</TT>, where <VAR>lang</VAR> 558represents the target language. See section <A HREF="gettext_6.html#SEC31">6 Creating a New PO File</A> for details. 559 560</P> 561<P> 562Then comes the initial translation of messages. Translation in 563itself is a whole matter, still exclusively meant for humans, 564and whose complexity far overwhelms the level of this manual. 565Nevertheless, a few hints are given in some other chapter of this 566manual (see section <A HREF="gettext_12.html#SEC184">12 The Translator's View</A>). You will also find there indications 567about how to contact translating teams, or becoming part of them, 568for sharing your translating concerns with others who target the same 569native language. 570 571</P> 572<P> 573While adding the translated messages into the <TT>‘<VAR>lang</VAR>.po’</TT> 574PO file, if you are not using one of the dedicated PO file editors 575(see section <A HREF="gettext_8.html#SEC49">8 Editing PO Files</A>), you are on your own 576for ensuring that your efforts fully respect the PO file format, and quoting 577conventions (see section <A HREF="gettext_3.html#SEC10">3 The Format of PO Files</A>). This is surely not an impossible task, 578as this is the way many people have handled PO files around 1995. 579On the other hand, by using a PO file editor, most details 580of PO file format are taken care of for you, but you have to acquire 581some familiarity with PO file editor itself. 582 583</P> 584<P> 585If some common translations have already been saved into a compendium 586PO file, translators may use PO mode for initializing untranslated 587entries from the compendium, and also save selected translations into 588the compendium, updating it (see section <A HREF="gettext_8.html#SEC66">8.3.14 Using Translation Compendia</A>). Compendium files 589are meant to be exchanged between members of a given translation team. 590 591</P> 592<P> 593Programs, or packages of programs, are dynamic in nature: users write 594bug reports and suggestion for improvements, maintainers react by 595modifying programs in various ways. The fact that a package has 596already been internationalized should not make maintainers shy 597of adding new strings, or modifying strings already translated. 598They just do their job the best they can. For the Translation 599Project to work smoothly, it is important that maintainers do not 600carry translation concerns on their already loaded shoulders, and that 601translators be kept as free as possible of programming concerns. 602 603</P> 604<P> 605The only concern maintainers should have is carefully marking new 606strings as translatable, when they should be, and do not otherwise 607worry about them being translated, as this will come in proper time. 608Consequently, when programs and their strings are adjusted in various 609ways by maintainers, and for matters usually unrelated to translation, 610<CODE>xgettext</CODE> would construct <TT>‘<VAR>package</VAR>.pot’</TT> files which are 611evolving over time, so the translations carried by <TT>‘<VAR>lang</VAR>.po’</TT> 612are slowly fading out of date. 613 614</P> 615<P> 616<A NAME="IDX38"></A> 617It is important for translators (and even maintainers) to understand 618that package translation is a continuous process in the lifetime of a 619package, and not something which is done once and for all at the start. 620After an initial burst of translation activity for a given package, 621interventions are needed once in a while, because here and there, 622translated entries become obsolete, and new untranslated entries 623appear, needing translation. 624 625</P> 626<P> 627The <CODE>msgmerge</CODE> program has the purpose of refreshing an already 628existing <TT>‘<VAR>lang</VAR>.po’</TT> file, by comparing it with a newer 629<TT>‘<VAR>package</VAR>.pot’</TT> template file, extracted by <CODE>xgettext</CODE> 630out of recent C sources. The refreshing operation adjusts all 631references to C source locations for strings, since these strings 632move as programs are modified. Also, <CODE>msgmerge</CODE> comments out as 633obsolete, in <TT>‘<VAR>lang</VAR>.po’</TT>, those already translated entries 634which are no longer used in the program sources (see section <A HREF="gettext_8.html#SEC60">8.3.8 Obsolete Entries</A>). It finally discovers new strings and inserts them in 635the resulting PO file as untranslated entries (see section <A HREF="gettext_8.html#SEC59">8.3.7 Untranslated Entries</A>). See section <A HREF="gettext_7.html#SEC40">7.1 Invoking the <CODE>msgmerge</CODE> Program</A>, for more information about what 636<CODE>msgmerge</CODE> really does. 637 638</P> 639<P> 640Whatever route or means taken, the goal is to obtain an updated 641<TT>‘<VAR>lang</VAR>.po’</TT> file offering translations for all strings. 642 643</P> 644<P> 645The temporal mobility, or fluidity of PO files, is an integral part of 646the translation game, and should be well understood, and accepted. 647People resisting it will have a hard time participating in the 648Translation Project, or will give a hard time to other participants! In 649particular, maintainers should relax and include all available official 650PO files in their distributions, even if these have not recently been 651updated, without exerting pressure on the translator teams to get the 652job done. The pressure should rather come 653from the community of users speaking a particular language, and 654maintainers should consider themselves fairly relieved of any concern 655about the adequacy of translation files. On the other hand, translators 656should reasonably try updating the PO files they are responsible for, 657while the package is undergoing pretest, prior to an official 658distribution. 659 660</P> 661<P> 662Once the PO file is complete and dependable, the <CODE>msgfmt</CODE> program 663is used for turning the PO file into a machine-oriented format, which 664may yield efficient retrieval of translations by the programs of the 665package, whenever needed at runtime (see section <A HREF="gettext_10.html#SEC163">10.3 The Format of GNU MO Files</A>). See section <A HREF="gettext_10.html#SEC143">10.1 Invoking the <CODE>msgfmt</CODE> Program</A>, for more information about all modes of execution 666for the <CODE>msgfmt</CODE> program. 667 668</P> 669<P> 670Finally, the modified and marked C sources are compiled and linked 671with the GNU <CODE>gettext</CODE> library, usually through the operation of 672<CODE>make</CODE>, given a suitable <TT>‘Makefile’</TT> exists for the project, 673and the resulting executable is installed somewhere users will find it. 674The MO files themselves should also be properly installed. Given the 675appropriate environment variables are set (see section <A HREF="gettext_2.html#SEC9">2.2 Magic for End Users</A>), the 676program should localize itself automatically, whenever it executes. 677 678</P> 679<P> 680The remainder of this manual has the purpose of explaining in depth the various 681steps outlined above. 682 683</P> 684<P><HR><P> 685Go to the first, previous, <A HREF="gettext_2.html">next</A>, <A HREF="gettext_25.html">last</A> section, <A HREF="gettext_toc.html">table of contents</A>. 686</BODY> 687</HTML> 688