f_langs= is statement, in lower case.
+ \@allowed= in upper case.
+ Now, in setTranslator() add
+\verbatim
+#ifdef LANG_xx
+ else if (L_EQUAL("your_language_name"))
+ {
+ theTranslator = new TranslatorYourLanguage;
+ }
+#endif
+\endverbatim
+ after the if { ... }. I.e., it must be placed after the code
+ for creating the English translator at the beginning, and before the
+ else { ... } part that creates the translator for the
+ default language (English again).
+
translator_xx.h:
+ TRANSLATOR_EN_H to TRANSLATOR_XX_H
+ twice (i.e. in the \c \#ifndef and \c \#define preprocessor commands at
+ the beginning of the file).
+ 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(), idLanguageCharset() and others
+ (you will recognize them when you start the work).
+ OUTPUT_LANGUAGE = your_language_name
+ in the config file to generate output in your language.
+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
+ \c maintainers.txt list.
+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 \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.
+
+What says the base class of a language translator?
+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)
+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).
+
+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 \c translator.py Python
+script was developed (located in \c 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
+(%(translatorReportFileName)s).
+
+\htmlonly If you compiled this documentation
+from sources and if you have also doxygen sources available the
+link %(translatorReportLink)s should be valid.\endhtmlonly
+
+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 \c translator.py is called
+automatically when the doxygen documentation is generated. You can
+also run the script manualy 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? 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.
+
+The most radical way of updating the language translator 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).
+
+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 =0;).
+
+If everything compiles fine, try to run \c translator.py, and have a
+look at the translator report (ASCII file) at the \c doxygen/doc
+directory. Even if your translator is marked as up-to-date, there
+still may be some remarks related to your souce code. 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 \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.
+
+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 \c TranslatorEnglish (the \c 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 \c
+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 newer translator adapter.
+
+Run the \c translator.py script occasionaly and give it your \c xx
+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.
+
+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 \c
+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
+word \c 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.
+
+*/
+