docs/html/gettext/gettext_1.html

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