1<HTML> 2<HEAD> 3<!-- This HTML file has been created by texi2html 1.52b 4 from gettext.texi on 29 December 2011 --> 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 proprietary 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#SEC178">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> 394These areas of cultural conventions are called <EM>locale categories</EM>. 395It is an unfortunate term; <EM>locale aspects</EM> or <EM>locale feature 396categories</EM> would be a better term, because each ���locale category��� 397describes an area or task that requires localization. The concrete data 398that describes the cultural conventions for such an area and for a particular 399culture is also called a <EM>locale category</EM>. In this sense, a locale 400is composed of several locale categories: the locale category describing 401the codeset, the locale category describing the formatting of numbers, 402the locale category containing the translated messages, and so on. 403 404</P> 405<P> 406<A NAME="IDX28"></A> 407Components of locale outside of message handling are standardized in 408the ISO C standard and the POSIX:2001 standard (also known as the SUSV3 409specification). GNU <CODE>libc</CODE> 410fully implements this, and most other modern systems provide a more 411or less reasonable support for at least some of the missing components. 412 413</P> 414 415 416<H2><A NAME="SEC5" HREF="gettext_toc.html#TOC5">1.4 Files Conveying Translations</A></H2> 417 418<P> 419<A NAME="IDX29"></A> 420The letters PO in <TT>‘.po’</TT> files means Portable Object, to 421distinguish it from <TT>‘.mo’</TT> files, where MO stands for Machine 422Object. This paradigm, as well as the PO file format, is inspired 423by the NLS standard developed by Uniforum, and first implemented by 424Sun in their Solaris system. 425 426</P> 427<P> 428PO files are meant to be read and edited by humans, and associate each 429original, translatable string of a given package with its translation 430in a particular target language. A single PO file is dedicated to 431a single target language. If a package supports many languages, 432there is one such PO file per language supported, and each package 433has its own set of PO files. These PO files are best created by 434the <CODE>xgettext</CODE> program, and later updated or refreshed through 435the <CODE>msgmerge</CODE> program. Program <CODE>xgettext</CODE> extracts all 436marked messages from a set of C files and initializes a PO file with 437empty translations. Program <CODE>msgmerge</CODE> takes care of adjusting 438PO files between releases of the corresponding sources, commenting 439obsolete entries, initializing new ones, and updating all source 440line references. Files ending with <TT>‘.pot’</TT> are kind of base 441translation files found in distributions, in PO file format. 442 443</P> 444<P> 445MO files are meant to be read by programs, and are binary in nature. 446A few systems already offer tools for creating and handling MO files 447as part of the Native Language Support coming with the system, but the 448format of these MO files is often different from system to system, 449and non-portable. The tools already provided with these systems don't 450support all the features of GNU <CODE>gettext</CODE>. Therefore GNU 451<CODE>gettext</CODE> uses its own format for MO files. Files ending with 452<TT>‘.gmo’</TT> are really MO files, when it is known that these files use 453the GNU format. 454 455</P> 456 457 458<H2><A NAME="SEC6" HREF="gettext_toc.html#TOC6">1.5 Overview of GNU <CODE>gettext</CODE></A></H2> 459 460<P> 461<A NAME="IDX30"></A> 462<A NAME="IDX31"></A> 463<A NAME="IDX32"></A> 464The following diagram summarizes the relation between the files 465handled by GNU <CODE>gettext</CODE> and the tools acting on these files. 466It is followed by somewhat detailed explanations, which you should 467read while keeping an eye on the diagram. Having a clear understanding 468of these interrelations will surely help programmers, translators 469and maintainers. 470 471</P> 472@example 473@group 474Original C Sources ���������> Preparation ���������> Marked C Sources ������������ 475 ��� 476 ������������������������������<��������� GNU gettext Library ��� 477������������ make <������������ ��� 478��� ������������������������������<��������������������������������������������������������������������������������������������������������������� 479��� ��� 480��� ������������������<��������� PACKAGE.pot <��������� xgettext <������������ ������������<��������� PO Compendium 481��� ��� ��� ��� 482��� ��� ��������������� ��� 483��� ��������������� ������������> PO editor ������������ 484��� ���������������> msgmerge ������������������> LANG.po ������������>��������������������������� ��� 485��� ��������������� ��� 486��� ��� ��� 487��� ������������������������������������������<������������������������������������������������ ��� 488��� ������������ New LANG.po <��������������������������������������������������������������� 489��� ������������ LANG.gmo <��������� msgfmt <������������ 490��� ��� 491��� ������������> install ���������> /.../LANG/PACKAGE.mo ������������ 492��� ������������> "Hello world!" 493������������������������> install ���������> /.../bin/PROGRAM ������������������������ 494@end group 495@end example 496 497<P> 498<A NAME="IDX33"></A> 499As a programmer, the first step to bringing GNU <CODE>gettext</CODE> 500into your package is identifying, right in the C sources, those strings 501which are meant to be translatable, and those which are untranslatable. 502This tedious job can be done a little more comfortably using emacs PO 503mode, but you can use any means familiar to you for modifying your 504C sources. Beside this some other simple, standard changes are needed to 505properly initialize the translation library. See section <A HREF="gettext_4.html#SEC16">4 Preparing Program Sources</A>, for 506more information about all this. 507 508</P> 509<P> 510For newly written software the strings of course can and should be 511marked while writing it. The <CODE>gettext</CODE> approach makes this 512very easy. Simply put the following lines at the beginning of each file 513or in a central header file: 514 515</P> 516 517<PRE> 518#define _(String) (String) 519#define N_(String) String 520#define textdomain(Domain) 521#define bindtextdomain(Package, Directory) 522</PRE> 523 524<P> 525Doing this allows you to prepare the sources for internationalization. 526Later when you feel ready for the step to use the <CODE>gettext</CODE> library 527simply replace these definitions by the following: 528 529</P> 530<P> 531<A NAME="IDX34"></A> 532 533<PRE> 534#include <libintl.h> 535#define _(String) gettext (String) 536#define gettext_noop(String) String 537#define N_(String) gettext_noop (String) 538</PRE> 539 540<P> 541<A NAME="IDX35"></A> 542<A NAME="IDX36"></A> 543and link against <TT>‘libintl.a’</TT> or <TT>‘libintl.so’</TT>. Note that on 544GNU systems, you don't need to link with <CODE>libintl</CODE> because the 545<CODE>gettext</CODE> library functions are already contained in GNU libc. 546That is all you have to change. 547 548</P> 549<P> 550<A NAME="IDX37"></A> 551<A NAME="IDX38"></A> 552Once the C sources have been modified, the <CODE>xgettext</CODE> program 553is used to find and extract all translatable strings, and create a 554PO template file out of all these. This <TT>‘<VAR>package</VAR>.pot’</TT> file 555contains all original program strings. It has sets of pointers to 556exactly where in C sources each string is used. All translations 557are set to empty. The letter <CODE>t</CODE> in <TT>‘.pot’</TT> marks this as 558a Template PO file, not yet oriented towards any particular language. 559See section <A HREF="gettext_5.html#SEC28">5.1 Invoking the <CODE>xgettext</CODE> Program</A>, for more details about how one calls the 560<CODE>xgettext</CODE> program. If you are <EM>really</EM> lazy, you might 561be interested at working a lot more right away, and preparing the 562whole distribution setup (see section <A HREF="gettext_13.html#SEC210">13 The Maintainer's View</A>). By doing so, you 563spare yourself typing the <CODE>xgettext</CODE> command, as <CODE>make</CODE> 564should now generate the proper things automatically for you! 565 566</P> 567<P> 568The first time through, there is no <TT>‘<VAR>lang</VAR>.po’</TT> yet, so the 569<CODE>msgmerge</CODE> step may be skipped and replaced by a mere copy of 570<TT>‘<VAR>package</VAR>.pot’</TT> to <TT>‘<VAR>lang</VAR>.po’</TT>, where <VAR>lang</VAR> 571represents the target language. See section <A HREF="gettext_6.html#SEC37">6 Creating a New PO File</A> for details. 572 573</P> 574<P> 575Then comes the initial translation of messages. Translation in 576itself is a whole matter, still exclusively meant for humans, 577and whose complexity far overwhelms the level of this manual. 578Nevertheless, a few hints are given in some other chapter of this 579manual (see section <A HREF="gettext_12.html#SEC198">12 The Translator's View</A>). You will also find there indications 580about how to contact translating teams, or becoming part of them, 581for sharing your translating concerns with others who target the same 582native language. 583 584</P> 585<P> 586While adding the translated messages into the <TT>‘<VAR>lang</VAR>.po’</TT> 587PO file, if you are not using one of the dedicated PO file editors 588(see section <A HREF="gettext_8.html#SEC55">8 Editing PO Files</A>), you are on your own 589for ensuring that your efforts fully respect the PO file format, and quoting 590conventions (see section <A HREF="gettext_3.html#SEC15">3 The Format of PO Files</A>). This is surely not an impossible task, 591as this is the way many people have handled PO files around 1995. 592On the other hand, by using a PO file editor, most details 593of PO file format are taken care of for you, but you have to acquire 594some familiarity with PO file editor itself. 595 596</P> 597<P> 598If some common translations have already been saved into a compendium 599PO file, translators may use PO mode for initializing untranslated 600entries from the compendium, and also save selected translations into 601the compendium, updating it (see section <A HREF="gettext_8.html#SEC72">8.4 Using Translation Compendia</A>). Compendium files 602are meant to be exchanged between members of a given translation team. 603 604</P> 605<P> 606Programs, or packages of programs, are dynamic in nature: users write 607bug reports and suggestion for improvements, maintainers react by 608modifying programs in various ways. The fact that a package has 609already been internationalized should not make maintainers shy 610of adding new strings, or modifying strings already translated. 611They just do their job the best they can. For the Translation 612Project to work smoothly, it is important that maintainers do not 613carry translation concerns on their already loaded shoulders, and that 614translators be kept as free as possible of programming concerns. 615 616</P> 617<P> 618The only concern maintainers should have is carefully marking new 619strings as translatable, when they should be, and do not otherwise 620worry about them being translated, as this will come in proper time. 621Consequently, when programs and their strings are adjusted in various 622ways by maintainers, and for matters usually unrelated to translation, 623<CODE>xgettext</CODE> would construct <TT>‘<VAR>package</VAR>.pot’</TT> files which are 624evolving over time, so the translations carried by <TT>‘<VAR>lang</VAR>.po’</TT> 625are slowly fading out of date. 626 627</P> 628<P> 629<A NAME="IDX39"></A> 630It is important for translators (and even maintainers) to understand 631that package translation is a continuous process in the lifetime of a 632package, and not something which is done once and for all at the start. 633After an initial burst of translation activity for a given package, 634interventions are needed once in a while, because here and there, 635translated entries become obsolete, and new untranslated entries 636appear, needing translation. 637 638</P> 639<P> 640The <CODE>msgmerge</CODE> program has the purpose of refreshing an already 641existing <TT>‘<VAR>lang</VAR>.po’</TT> file, by comparing it with a newer 642<TT>‘<VAR>package</VAR>.pot’</TT> template file, extracted by <CODE>xgettext</CODE> 643out of recent C sources. The refreshing operation adjusts all 644references to C source locations for strings, since these strings 645move as programs are modified. Also, <CODE>msgmerge</CODE> comments out as 646obsolete, in <TT>‘<VAR>lang</VAR>.po’</TT>, those already translated entries 647which are no longer used in the program sources (see section <A HREF="gettext_8.html#SEC66">8.3.8 Obsolete Entries</A>). It finally discovers new strings and inserts them in 648the resulting PO file as untranslated entries (see section <A HREF="gettext_8.html#SEC65">8.3.7 Untranslated Entries</A>). See section <A HREF="gettext_7.html#SEC46">7.1 Invoking the <CODE>msgmerge</CODE> Program</A>, for more information about what 649<CODE>msgmerge</CODE> really does. 650 651</P> 652<P> 653Whatever route or means taken, the goal is to obtain an updated 654<TT>‘<VAR>lang</VAR>.po’</TT> file offering translations for all strings. 655 656</P> 657<P> 658The temporal mobility, or fluidity of PO files, is an integral part of 659the translation game, and should be well understood, and accepted. 660People resisting it will have a hard time participating in the 661Translation Project, or will give a hard time to other participants! In 662particular, maintainers should relax and include all available official 663PO files in their distributions, even if these have not recently been 664updated, without exerting pressure on the translator teams to get the 665job done. The pressure should rather come 666from the community of users speaking a particular language, and 667maintainers should consider themselves fairly relieved of any concern 668about the adequacy of translation files. On the other hand, translators 669should reasonably try updating the PO files they are responsible for, 670while the package is undergoing pretest, prior to an official 671distribution. 672 673</P> 674<P> 675Once the PO file is complete and dependable, the <CODE>msgfmt</CODE> program 676is used for turning the PO file into a machine-oriented format, which 677may yield efficient retrieval of translations by the programs of the 678package, whenever needed at runtime (see section <A HREF="gettext_10.html#SEC177">10.3 The Format of GNU MO Files</A>). See section <A HREF="gettext_10.html#SEC157">10.1 Invoking the <CODE>msgfmt</CODE> Program</A>, for more information about all modes of execution 679for the <CODE>msgfmt</CODE> program. 680 681</P> 682<P> 683Finally, the modified and marked C sources are compiled and linked 684with the GNU <CODE>gettext</CODE> library, usually through the operation of 685<CODE>make</CODE>, given a suitable <TT>‘Makefile’</TT> exists for the project, 686and the resulting executable is installed somewhere users will find it. 687The MO files themselves should also be properly installed. Given the 688appropriate environment variables are set (see section <A HREF="gettext_2.html#SEC10">2.3 Setting the Locale through Environment Variables</A>), 689the program should localize itself automatically, whenever it executes. 690 691</P> 692<P> 693The remainder of this manual has the purpose of explaining in depth the various 694steps outlined above. 695 696</P> 697<P><HR><P> 698Go 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>. 699</BODY> 700</HTML> 701