language.tpl 16.4 KB
Newer Older
1 2 3 4

ATTENTION! This is the template for generating language.doc. If you want to
change the language.doc, make the changes here and inside maintainers.txt.

Dimitri van Heesch's avatar
Dimitri van Heesch committed
5
/******************************************************************************
6
 * %(editnote)s 
Dimitri van Heesch's avatar
Dimitri van Heesch committed
7
 *
8
 * Copyright (C) 1997-2006 by Dimitri van Heesch.
Dimitri van Heesch's avatar
Dimitri van Heesch committed
9 10 11 12 13 14 15 16 17 18
 *
 * Permission to use, copy, modify, and distribute this software and its
 * documentation under the terms of the GNU General Public License is hereby 
 * granted. No representations are made about the suitability of this software 
 * for any purpose. It is provided "as is" without express or implied warranty.
 * See the GNU General Public License for more details.
 *
 * Documents produced by Doxygen are derivative works derived from the
 * input used in their production; they are not affected by this license.
 *
19
 * $Id$
Dimitri van Heesch's avatar
Dimitri van Heesch committed
20 21 22 23 24
 */
/*! \page langhowto Internationalization

<h3>Support for multiple languages</h3>

25 26 27 28
Doxygen has built-in support for multiple languages. This means that the
text fragments, generated by doxygen, can be produced in languages other
than English (the default). The output language is chosen through the
configuration file (with default name and known as Doxyfile).
29

30 31 32
Currently (version %(doxVersion)s), %(numLangStr)s languages 
are supported (sorted alphabetically):
%(supportedLangReadableStr)s.
Dimitri van Heesch's avatar
Dimitri van Heesch committed
33 34

The table of information related to the supported languages follows.
35
It is sorted by language alphabetically.  The <b>Status</b> column
Dimitri van Heesch's avatar
Dimitri van Heesch committed
36 37 38
was generated from sources and shows approximately the last version
when the translator was updated.

39
%(informationTable)s
Dimitri van Heesch's avatar
Dimitri van Heesch committed
40 41 42 43 44 45

Most people on the list have indicated that they were also busy
doing other things, so if you want to help to speed things up please 
let them (or me) know.

If you want to add support for a language that is not yet listed 
46 47
please read the next section.

Dimitri van Heesch's avatar
Dimitri van Heesch committed
48 49 50

<h3>Adding a new language to doxygen</h3>

51
This short HOWTO explains how to add support for the new language to Doxygen:
Dimitri van Heesch's avatar
Dimitri van Heesch committed
52 53 54 55 56 57 58

Just follow these steps:
<ol>
<li>Tell me for which language you want to add support. If no one else
    is already working on support for that language, you will be 
    assigned as the maintainer for the language. 
<li>Create a copy of translator_en.h and name it 
59
    translator_\<your_2_letter_country_code\>.h
Dimitri van Heesch's avatar
Dimitri van Heesch committed
60
    I'll use xx in the rest of this document.
61 62 63 64
<li>Add definition of the symbol for your language in the configure 
at two places in the script:
  <ol>
  <li>After the <code>f_langs=</code> is statement, in lower case.
65
  <li>In the string that following <code>\@allowed=</code> in upper case.
66 67
  </ol>
The rerun the configure script such that is generates src/lang_cfg.h.
68
This file should now contain a \#define for your language code.
Dimitri van Heesch's avatar
Dimitri van Heesch committed
69 70 71
<li>Edit language.cpp:
    Add a 
\verbatim
72
#ifdef LANG_xx
Dimitri van Heesch's avatar
Dimitri van Heesch committed
73
#include<translator_xx.h>
74
#endif
Dimitri van Heesch's avatar
Dimitri van Heesch committed
75
\endverbatim
76 77
    Remember to use the same symbol LANG_xx that you added to \c lang_cfg.h.
    I.e., the \c xx should be capital letters that identify your language.
78
    On the other hand, the \c xx inside your \c translator_xx.h should use
79 80
    lower case.
    <p>Now, in <code>setTranslator()</code> add
Dimitri van Heesch's avatar
Dimitri van Heesch committed
81
\verbatim
82
#ifdef LANG_xx
Dimitri van Heesch's avatar
Dimitri van Heesch committed
83 84 85 86
    else if (L_EQUAL("your_language_name"))
    {
      theTranslator = new TranslatorYourLanguage;
    }
87
#endif    
Dimitri van Heesch's avatar
Dimitri van Heesch committed
88
\endverbatim
89 90 91 92
    after the <code>if { ... }</code>. I.e., it must be placed after the code
    for creating the English translator at the beginning, and before the 
    <code>else { ... }</code> part that creates the translator for the 
    default language (English again).
Dimitri van Heesch's avatar
Dimitri van Heesch committed
93
<li>Edit libdoxygen.pro.in and add \c translator_xx.h to 
Dimitri van Heesch's avatar
Dimitri van Heesch committed
94
    the \c HEADERS line.
Dimitri van Heesch's avatar
Dimitri van Heesch committed
95 96
<li>Edit <code>translator_xx.h</code>:
   <ul>
97
   <li>Rename <code>TRANSLATOR_EN_H</code> to <code>TRANSLATOR_XX_H</code> 
98
       twice (i.e. in the \c \#ifndef and \c \#define preprocessor commands at 
99
       the beginning of the file).
Dimitri van Heesch's avatar
Dimitri van Heesch committed
100 101
   <li>Rename TranslatorEnglish to TranslatorYourLanguage 
   <li>In the member <code>idLanguage()</code> change "english" into the 
Dimitri van Heesch's avatar
Dimitri van Heesch committed
102
     name of your language (use lower case characters only). Depending
Dimitri van Heesch's avatar
Dimitri van Heesch committed
103
     on the language you may also wish to change the member functions 
104 105
     latexLanguageSupportCommand(), idLanguageCharset() and others
     (you will recognize them when you start the work).
Dimitri van Heesch's avatar
Dimitri van Heesch committed
106 107 108 109 110 111
   <li>Edit all the strings that are returned by the member functions that 
     start with tr. 
     Try to match punctuation and capitals!
     To enter special characters (with accents) you can:
     <ul>
     <li>  Enter them directly if your keyboard supports that and you are 
112 113 114
           using a Latin-1 font. Doxygen will translate the
           characters to proper \f$\mbox{\LaTeX}\f$ and leave the
           HTML and man output for what it is (which is fine, if
Dimitri van Heesch's avatar
Dimitri van Heesch committed
115 116 117 118 119 120 121 122 123 124
           idLanguageCharset() is set correctly).
     <li>  Use html codes like \&auml; for an a with an umlaut (i.e. &auml;).
           See the HTML specification for the codes.
     </ul>
   </ul>
<li>Run configure and make again from the root of the distribution, 
    in order to regenerated the Makefiles.
<li>Now you can use <code>OUTPUT_LANGUAGE = your_language_name</code> 
    in the config file to generate output in your language.
<li>Send <code>translator_xx.h</code> to me so I can add it to doxygen.
125 126
    Send also your name and e-mail address to be included in the
    \c maintainers.txt list.
Dimitri van Heesch's avatar
Dimitri van Heesch committed
127 128
</ol>

129

Dimitri van Heesch's avatar
Dimitri van Heesch committed
130 131
<h3>Maintaining a language</h3>

132 133 134 135 136 137 138 139 140
New versions of doxygen may use new translated sentences.  In such
situation, the \c Translator class requires implementation of new
methods -- its interface changes.  Of course, the English
sentences need to be translated to the other languages.  At least,
new methods have to be implemented by the language-related
translator class; otherwise, doxygen wouldn't even compile.  Waiting
until all language maintainers have translated the new sentences and
sent the results would not be very practical. The following text
describes the usage of translator adapters to solve the problem.
141 142 143 144 145

<b>The role of Translator Adapters.</b> 
Whenever the \c Translator class interface changes in the new
release, the new class \c TranslatorAdapter_x_y_z is added to the \c
translator_adapter.h file (here x, y, and z are numbers that
146 147 148
correspond to the current official version of doxygen). All
translators that previously derived from the \c Translator class now
derive from this adapter class.
149 150 151 152 153 154 155 156 157

The \c TranslatorAdapter_x_y_z class implements the new, required
methods.  If the new method replaces some similar but obsolete
method(s) (e.g. if the number of arguments changed and/or the
functionality of the older method was changed or enriched), the \c
TranslatorAdapter_x_y_z class may use the obsolete method to get the
result which is as close as possible to the older result in the
target language.  If it is not possible, the result (the default
translation) is obtained using the English translator, which is (by
158
definition) always up-to-date.  
159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231

<b>For example,</b> when the new \c trFile() method with
parameters (to determine the capitalization of the first letter and
the singular/plural form) was introduced to replace the older method
\c trFiles() without arguments, the following code appeared in one
of the translator adapter classes:

\verbatim
    /*! This is the default implementation of the obsolete method
     * used in the documentation of a group before the list of
     * links to documented files.  This is possibly localized.
     */
    virtual QCString trFiles()
    { return "Files"; }

    /*! This is the localized implementation of newer equivalent
     * using the obsolete method trFiles().
     */
    virtual QCString trFile(bool first_capital, bool singular)
    {
      if (first_capital && !singular)
        return trFiles();  // possibly localized, obsolete method
      else
        return english.trFile(first_capital, singular);
    }
\endverbatim

The \c trFiles() is not present in the \c TranslatorEnglish class,
because it was removed as obsolete.  However, it was used until now
and its call was replaced by 

\verbatim
    trFile(true, false)
\endverbatim

in the doxygen source files.  Probably, many language translators
implemented the obsolete method, so it perfectly makes sense to use
the same language dependent result in those cases. The \c
TranslatorEnglish does not implement the old method.  It derives
from the abstract \c Translator class.  On the other hand, the old
translator for a different language does not implement the new \c
trFile() method.  Because of that it is derived from another base
class -- \c TranslatorAdapter_x_y_z. The \c TranslatorAdapter_x_y_z
class have to implement the new, required \c trFile() method.
However, the translator adapter would not be compiled if the \c
trFiles() method was not implemented. This is the reason for
implementing the old method in the translator adapter class (using
the same code, that was removed from the TranslatorEnglish).

The simplest way would be to pass the arguments to the English
translator and to return its result.  Instead, the adapter uses the
old \c trFiles() in one special case -- when the new
<code>trFile(true,&nbsp;false)</code> is called.  This is the
mostly used case at the time of introducing the new method -- see
above.  While this may look too complicated, the technique allows
the developers of the core sources to change the Translator
interface, while the users may not even notice the change.  Of
course, when the new \c trFile() is used with different arguments,
the English result is returned and it will be noticed by non English
users.  Here the maintainer of the language translator should
implement at least that one particular method.

<b>What says the base class of a language translator?</b>
If the language translator class inherits from any adapter class the
maintenance is needed.  In such case, the language translator is not
considered up-to-date.  On the other hand, if the language
translator derives directly from the abstract class \c Translator, the
language translator is up-to-date.

The translator adapter classes are chained so that the older
translator adapter class uses the one-step-newer translator adapter
as the base class.  The newer adapter does less \e adapting work
than the older one.  The oldest adapter class derives (indirectly)
232 233 234 235 236 237 238 239 240 241 242 243 244 245
from all of the adapter classes.  The name of the adapter class is
chosen so that its suffix is derived from the previous official
version of doxygen that did not need the adapter.  This way, one can
say approximately, when the language translator class was last
updated -- see details below.

The newest translator adapter derives from the abstract \c
TranslatorAdapterBase class that derives directly from the abstract
\c Translator class.  It adds only the private English-translator
member for easy implementation of the default translation inside the
adapter classes, and it also enforces implementation of one method
for noticing the user that the language translation is not up-to-date
(because of that some sentences in the generated files may appear in
English).
246 247

Once the oldest adapter class is not used by any of the language
248 249 250
translators, it can be removed from the doxygen project.  The
maintainers should try to reach the state with the minimal number of
translator adapter classes.
251 252

<b>To simplify the maintenance of the language translator classes</b>
253
for the supported languages, the \c translator.py Python
254
script was developed (located in \c doxygen/doc directory). 
255 256 257
It extracts the important information about obsolete and
new methods from the source files for each of the languages.  
The information is stored in the <em>translator report</em> ASCII file
258 259 260
(%(translatorReportFileName)s). 

\htmlonly If you compiled this documentation
261
from sources and if you have also doxygen sources available the
262
link %(translatorReportLink)s should be valid.\endhtmlonly 
263 264 265

Looking at the base class of the language translator, the script
guesses also the status of the translator -- see the last column of
266
the table with languages above.  The \c translator.py is called
267
automatically when the doxygen documentation is generated.  You can
268
also run the script manually whenever you feel that it can help you.
269 270 271 272
Of course, you are not forced to use the results of the script.  You
can find the same information by looking at the adapter class and
its base classes.

273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293
<b>How should I update my language translator?</b> Firstly, you
should be the language maintainer, or you should let him/her know
about the changes.  The following text was written for the language
maintainers as the primary audience.

There are several approaches to be taken when updating your
language.  If you are not extremely busy, you should always chose
the most radical one.  When the update takes much more time than you
expected, you can always decide use some suitable translator adapter to
finish the changes later and still make your translator working.

<b>The most radical way of updating the language translator</b> is
to make your translator class derive directly 
from the abstract class \c Translator and provide translations for the
methods that are required to be implemented -- the compiler will
tell you if you forgot to implement some of them.  If you are in
doubt, have a look at the \c TranslatorEnglish class to recognize the
purpose of the implemented method.  Looking at the previously used
adapter class may help you sometimes, but it can also be misleading
because the adapter classes do implement also the obsolete methods
(see the previous \c trFiles() example).
Dimitri van Heesch's avatar
Dimitri van Heesch committed
294

295 296 297 298 299
In other words, the up-to-date language translators do not need the
\c TranslatorAdapter_x_y_z classes at all, and you do not need to
implement anything else than the methods required by the Translator
class (i.e. the pure virtual methods of the \c Translator -- they 
end with <code>=0;</code>).
Dimitri van Heesch's avatar
Dimitri van Heesch committed
300

301
If everything compiles fine, try to run \c translator.py, and have a
302
look at the translator report (ASCII file) at the \c doxygen/doc
303
directory. Even if your translator is marked as up-to-date, there
304
still may be some remarks related to your source code. Namely, the
305
obsolete methods--that are not used at all--may be listed in the
306 307 308 309
section for your language. Simply, remove their code (and run the \c
translator.py again). Also, you will be informed when you forgot to
change the base class of your translator class to some newer adapter
class or directly to the Translator class.
Dimitri van Heesch's avatar
Dimitri van Heesch committed
310

311 312 313 314
<b>If you do not have time to finish all the updates</b> you should
still start with <em>the most radical approach</em> as described
above.  You can always change the base class to the translator
adapter class that implements all of the not-yet-implemented methods.
Dimitri van Heesch's avatar
Dimitri van Heesch committed
315

316 317 318 319 320 321 322 323 324 325 326
<b>If you prefer to update your translator gradually</b>, have a look
at \c TranslatorEnglish (the \c translator_en.h file). Inside, you
will find the comments like <code>new since 1.2.4</code> that separate
always a number of methods that were implemented in the stated
version. Do implement the group of methods that are placed below the
comment that uses the same version numbers as your translator adapter
class. (For example, your translator class have to use the \c
TranslatorAdapter_1_2_4, if it does not implement the methods below
the comment <code>new since 1.2.4</code>. When you implement them,
your class should use newer translator adapter.

327
Run the \c translator.py script occasionally and give it your \c xx
328 329 330 331 332 333 334 335 336 337 338 339 340 341 342
identification (from \c translator_xx.h) to create the translator
report shorter (also produced faster) -- it will contain only the
information related to your translator. Once you reach the state when
the base class should be changed to some newer adapter, you will see
the note in the translator report.
 
Warning: Don't forget to compile Doxygen to discover, whether it is
compilable. The \c translator.py does not check if everything is
correct with respect to the compiler. Because of that, it may lie
sometimes about the necessary base class.

<b>The most obsolete language translators</b> would lead to
implementation of too complicated adapters. Because of that, doxygen
developers may decide to derive such translators from the \c
TranslatorEnglish class, which is by definition always up-to-date.
Dimitri van Heesch's avatar
Dimitri van Heesch committed
343 344 345 346 347 348 349 350 351 352 353 354 355

When doing so, all the missing methods will be replaced by the
English translation.  This means that not-implemented methods will
always return the English result.  Such translators are marked using
word \c obsolete.  You should read it <b>really obsolete</b>. No
guess about the last update can be done.  

Often, it is possible to construct better result from the obsolete
methods.  Because of that, the translator adapter classes should be
used if possible.  On the other hand, implementation of adapters for
really obsolete translators brings too much maintenance and
run-time overhead.

Dimitri van Heesch's avatar
Dimitri van Heesch committed
356 357
*/