|
setTranslator() add
\verbatim
else if (L_EQUAL("your_language_name"))
{
theTranslator = new TranslatorYourLanguage;
}
\endverbatim
after the if { ... }
translator_xx.h:
TRANSLATOR_EN_H to TRANSLATOR_XX_H twice.
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 newest adapter class derives
directly from the abstract class \c Translator.
The name of the adapter class was chosen so that its suffix is
derived from the previous version of doxygen. This way, one can say
approximately, when the language translator class was last updated
-- see details below. The newest adapter translator for CVS release
(i.e. non official) is named \c TranslatorAdapterCVS. As it derives
only from the \c Translator class, it can be used only for language
translator classes that were up-to-date in the time of the last
release.
Status of the translators that derive from the \c
TranslatorAdapterCVS is named as almost up-to-date.
Its code is moved into the new \c Translator_x_y_z when new version
of doxygen is officially released.
Once the oldest adapter class is not used by any of the language
translators, it can be removed from the doxygen project. This also
means, that there probably still is some language which uses the
oldest adapter. 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.pl perl
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
(doxygen/doc/translator_report.txt). \htmlonly If you compiled this documentation
from sources and if you have also doxygen sources available the
link
doxygen/doc/translator_report.txt 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.pl 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.pl, 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.pl again).
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, look
at the translator report generated by the \c translator.pl script
and choose one of the missing method that is implemented by the
translator adapter, that is used as your base class. When there is
not such a method in your translator adapter base class, you probably
can change the translator adapter base to the newer one.
Do not blindly implement all methods that are implemented by your
translator adapter base class. The reason is that the adapter
classes implement also obsolete methods. Another reason is that
some of the methods could become obsolete later.
*/