Internationalization

### Support for multiple languages

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 option OUTPUT_LANGUAGE in the configuration file (with default name and known as Doxyfile). To switch between languages inside a comment block the \~ command can be used.

Currently (version 1.9.8), 42 languages are supported (sorted alphabetically): Afrikaans, Arabic, Armenian, Brazilian Portuguese, Bulgarian, Catalan, Chinese, Chinese Traditional, Croatian, Czech, Danish, Dutch, English, Esperanto, Finnish, French, German, Greek, Hindi, Hungarian, Indonesian, Italian, Japanese (+En), Korean (+En), Latvian, Lithuanian, Macedonian, Norwegian, Persian, Polish, Portuguese, Romanian, Russian, Serbian, SerbianCyrillic, Slovak, Slovene, Spanish, Swedish, Turkish, Ukrainian, and Vietnamese..

The table of information related to the supported languages follows. It is sorted by language alphabetically. The Status column was generated from sources and shows approximately the last version when the translator was updated.

Language | Maintainer | Contact address (replace the at and dot) | Status
Afrikaans | Johan Prinsloo | johan at zippysnoek dot com | 1.6.0
Arabic | Moaz Reyad Muhammad Bashir Al-Noimi | [resigned] mbnoimi at gmail dot com | 1.4.6
Armenian | Armen Tangamyan | armen dot tangamyan at anu dot edu dot au | 1.8.0
Brazilian Portuguese | Fabio "FJTC" Jun Takada Chino | jun-chino at uol dot com dot br | up-to-date
Bulgarian | Kiril Kirilov | kpkirilov at abv dot bg | 1.9.4
Catalan | Maximiliano Pin Albert Mora | max dot pin at bitroit dot com [unreachable] | 1.8.0
Chinese | Lian Yang Li Daobing Wei Liu | lian dot yang dot cn at gmail dot com lidaobing at gmail dot com liuwei at asiainfo dot com | 1.9.4
Chinese Traditional | Daniel YC Lin Gary Lee | dlin dot tw at gmail dot com garywlee at gmail dot com | 1.8.15
Croatian | Boris Bralo | boris dot bralo at gmail dot com | 1.8.2
Czech | Petr Přikryl | prikryl at atlas dot cz | 1.9.6
Danish | Poul-Erik Hansen Erik Søe Sørensen | pouhan at gnotometrics dot dk eriksoe+doxygen at daimi dot au dot dk | 1.8.0
Dutch | Dimitri van Heesch | doxygen at gmail dot com | up-to-date
English | Dimitri van Heesch | doxygen at gmail dot com | up-to-date
Esperanto | Ander Martínez | ander dot basaundi at gmail dot com | 1.8.4
Finnish | Antti Laine | antti dot a dot laine at tut dot fi | 1.6.0
French | David Martinet Xavier Outhier Benoît BROSSE | contact at e-concept-applications dot fr xouthier at yahoo dot fr Benoit dot BROSSE at ingenico dot com | 1.9.5
German | Peter Grotrian Jens Seidel | Peter dot Grotrian at pdv-FS dot de jensseidel at users dot sf dot net | 1.8.15
Greek | Paul Gessos | gessos dot paul at yahoo dot gr | 1.9.6
Hindi | Harsh Rathod | hrathore50 at ymail dot com | 1.9.4
Hungarian | Ákos Kiss Földvári György | akiss at users dot sourceforge dot net [unreachable] | 1.8.15
Indonesian | Hendy Irawan | ceefour at gauldong dot net | 1.8.0
Italian | Alessandro Falappa Ahmed Aldo Faisal | alex dot falappa at gmail dot com aaf23 at cam dot ac dot uk | 1.8.15
Japanese | Suzumizaki-Kimikata Hiroki Iseri Ryunosuke Satoh Kenji Nagamatsu Iwasa Kazmi | szmml at h12u.com goyoki at gmail dot com sun594 at hotmail dot com [unreachable] [unreachable] | 1.8.15
JapaneseEn | see the Japanese language |  | English based
Korean | Kim Taedong SooYoung Jung Richard Kim | fly1004 at gmail dot com jung5000 at gmail dot com [unreachable] | 1.8.15
KoreanEn | see the Korean language |  | English based
Latvian | Lauris | lauris at nix.lv | 1.8.4
Lithuanian | Tomas Simonaitis Mindaugas Radzius Aidas Berukstis -- searching for the maintainer -- | [unreachable] [unreachable] [unreachable] [Please, try to help to find someone.] | 1.4.6
Macedonian | Slave Jovanovski | slavejovanovski at yahoo dot com | 1.6.0
Norwegian | Lars Erik Jordet | lejordet at gmail dot com | 1.4.6
Persian | Ali Nadalizadeh | nadalizadeh at gmail dot com | 1.7.5
Polish | Piotr Kaminski Grzegorz Kowal Krzysztof Kral | [unreachable] [unreachable] krzysztof dot kral at gmail dot com | 1.8.2
Portuguese | Rui Godinho Lopes Fabio "FJTC" Jun Takada Chino | [resigned] jun-chino at uol dot com dot br | up-to-date
Romanian | Ionut Dumitrascu Alexandru Iosup | reddumy at yahoo dot com aiosup at yahoo dot com | 1.8.15
Russian | Brilliantov Kirill Vladimirovich Alexandr Chelpanov | brilliantov at byterg dot ru cav at cryptopro dot ru | 1.8.15
Serbian | Dejan Milosavljevic | [unreachable] | 1.6.0
SerbianCyrillic | Nedeljko Stefanovic | stenedjo at yahoo dot com | 1.6.0
Slovak | Kali+Laco Švec Petr Přikryl | [the Slovak language advisors] prikryl at atlas dot cz | 1.8.15
Slovene | Matjaž Ostroveršnik | matjaz dot ostroversnik at ostri dot org | 1.4.6
Spanish | Bartomeu Francisco Oltra Thennet David Vaquero | bartomeu at loteria3cornella dot com [unreachable] david at grupoikusnet dot com | 1.9.6
Swedish | Björn Palmqvist | bjorn.palmqvist at aidium.se | 1.9.6
Turkish | Emin Ilker Cetinbas | niw3 at yahoo dot com | 1.7.5
Ukrainian | Olexij Tkatchenko Petro Yermolenko | [resigned] python at i dot ua | 1.8.4
Vietnamese | Dang Minh Tuan | tuanvietkey at gmail dot com | 1.6.0

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 please read the next section.

### Adding a new language to doxygen

This short HOWTO explains how to add support for the new language to doxygen:

Just follow the following steps:

1. Tell me for which language (say `YourLanguage`) 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.
2. Add to the file `doxygen/src/config.xml`, at the appropriate place in the OUTPUT_LANGUAGE part, the line:

             <value name='YourLanguage'/>

3. Create a copy of `doxygen/src/translator_en.h` and name it `doxygen/src/translator_<your_2_letter_country_code>.h` I'll use `xx` in the rest of this document (and `XX` for the uppercase version).

4. Edit `doxygen/src/language.cpp`: Add the following code:

       #include<translator_xx.h>

   Now, in `setTranslator()` add

       case OUTPUT_LANGUAGE_t::YourLanguage: theTranslator = new TranslatorYourLanguage; break;

5. Edit `doxygen/src/translator_xx.h`:
   - Use the UTF-8 capable editor and open the file using the UTF-8 mode (non BOM mode).
   - Rename `TRANSLATOR_EN_H` to `TRANSLATOR_XX_H` twice (i.e. in the `#ifndef` and `#define` preprocessor commands at the beginning of the file).
   - Rename `TranslatorEnglish` to `TranslatorYourLanguage`
   - In the member `idLanguage()` change "english" into the name of your language (use lower case characters only). Depending on the language you may also wish to change the member functions `latexLanguageSupportCommand()` and other (you will recognize them when you start the work).
   - 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:
     - Enter them directly if your keyboard supports that. Recall that the text is expected to be saved using the UTF-8 encoding. Doxygen will translate the characters to proper and leaves the HTML and man output in UTF-8.
     - Use HTML codes like `&auml`; for an `a` with an `umlaut` (i.e. `ä`). See the HTML specification for the codes.
6. Edit `doxygen/doc/maintainers.txt` and add yourself to the list of maintainers like:
   TranslatorYourLanguage
   <your name>: <your dot email at your dot domain>
7. Build the documentation by giving the appropriate build command (like: `make docs`).
8. Now you can use `OUTPUT_LANGUAGE = your_language_name` in the config file to generate output in your language.
9. The preferred way is to clone the doxygen repository at GitHub and make a Pull Request. Alternatively send `translator_xx.h` to me so I can add it to doxygen. Send also your name and e-mail address to be included in the `maintainers.txt` list.

### Maintaining a language

New versions of doxygen may use new translated sentences. In such situation, the `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.

The role of Translator Adapters. Whenever the `Translator` class interface changes in the new release, the new class `TranslatorAdapter_x_y_z` is added to the `translator_adapter.h` file (here x, y, and z are numbers that correspond to the current official version of doxygen). All translators that previously derived from the `Translator` class now derive from this adapter class.

The `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 `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 definition) always up-to-date.

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

        /*! 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);
        }

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

        trFile(true, false)

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 `TranslatorEnglish` does not implement the old method. It derives from the abstract `Translator` class. On the other hand, the old translator for a different language does not implement the new `trFile()` method. Because of that it is derived from another base class – `TranslatorAdapter_x_y_z`. The `TranslatorAdapter_x_y_z` class has to implement the new, required `trFile()` method. However, the translator adapter would not be compiled if the `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 `trFiles()` in one special case – when the new `trFile(true, false)` 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 `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.

What says the base class of a language translator? If the language translator class inherits from any adapter class then maintenance is needed. In such case, the language translator is considered not up-to-date. On the other hand, if the language translator derives directly from the abstract class `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 adapting work than the older one. The oldest adapter class derives (indirectly) 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 `TranslatorAdapterBase` class that derives directly from the abstract `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 notifying the user that the language translation is not up-to-date (because of that some sentences in the generated files may appear in English).

Once the oldest adapter class is not used by any of the language 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.

To simplify the maintenance of the language translator classes for the supported languages, the `translator.py` Python script was developed (located in `doxygen/doc` directory). 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 translator report ASCII file (`translator_report.txt`).

You can find this file as `translator_report.txt`.

Looking at the base class of the language translator, the script guesses also the status of the translator – see the last column of the table with languages above. The `translator.py` is called automatically when the doxygen documentation is generated. You can also run the script manually whenever you feel that it can help you. 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.

How should I update my language translator? First, 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.

The most radical way of updating the language translator is to make your translator class derive directly from the abstract class `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 `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 `trFiles()` example).

In other words, the up-to-date language translators do not need the `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 `Translator` – they end with `=0;`).

If everything compiles fine, try to run `translator.py`, and have a look at the translator report (ASCII file) at the `doxygen/doc` directory. Your translator is marked as up-to-date only if the script does not detect anything special. If the translator uses the `Translator` base class, there still may be some remarks related to your source code. In the case, the translator is marked as almost up-to-date. Namely, the obsolete methods–that are not used at all–may be listed in the section for your language. Simply, remove their code (and run the `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.

If you do not have time to finish all the updates you should still start with the most radical approach as described above. You can always change the base class to the translator adapter class that implements all of the not-yet-implemented methods.

If you prefer to update your translator gradually, have a look at `TranslatorEnglish` (the `translator_en.h` file). Inside, you will find the comments like `new since 1.2.4` 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 `TranslatorAdapter_1_2_4`, if it does not implement the methods below the comment `new since 1.2.4`. When you implement them, your class should use a newer translator adapter.

Run the `translator.py` script occasionally and give it your `xx` identification (from `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 `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.

The most obsolete language translators would lead to implementation of too complicated adapters. Because of that, doxygen developers may decide to derive such translators from the `TranslatorEnglish` class, which is by definition always up-to-date.

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 the word `obsolete`. You should read it really obsolete. 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.

Go to the next section or return to the index.