RE: [Doxygen-users] Again about translations...

[Prikryl,Petr <PRI...@sk...>]

Hi Alessandro,

Alessandro Falappa wrote...
> [...] italian doesn't have a saxon genitive form.
> [...] Many section titles in the documentation generated 
> by Doxygen adopt the saxon genitive form: in a project
> called Foobar we have "Foobar Documentation" [...]

This is also the Czech language problem.  I had a disussion with
Dimitri earlier.  The conclusion was that there is no
general way how to put translated pieces of text together
so that well looking sentence is produced for all languages.

The only solution is to have trXxxx() with all the 
parameters necessary for composition of a meaningful
sentence.  Then the language maintainer is responsible
for puting the things together -- possibly using results
of other translator methods for generating the pieces.

As you adviced, the approach like this...

>  QCString trMemberList(const QCString& className)

...is the right way.

Fortunately, the new internal mechanism for deriving
national translators was introduced with doxygen 1.2.7.
It uses adapter classes that allow change the interface of 
the Translator class and still preserve the functionality 
of older TranslatorXxxx classes for the Xxxx language.

In other words, changing the trMemberList() and similar
to take some arguments will affect the core code, but 
will not break the other maintainers work, nor require from 
them any effort until they decide to update their translator.
[ This means that the changes will be less painful (for 
Dimitri and others) and the development here can be 
more rapid (because of avoiding dependency on
the language maintainers). ]

The method can even change the name.  Some other
argument can also signalize that the translation should
have some special form like:

 1) for the HTML head title
     "Project, version, class: Member List"

  2) for HTML page heading (i.e. on the page)
     "Member List for class"
  
etc.

So, the main problem is to find, where the old method
was called and think deeply whether newly proposed
method will not create some apparent obstacles in future.

Once this is decided, Dimitri (or someone closely 
cooperating with him) can change the interface of 
the decided method and create its appropriate 
default implementation in the adapter class which
takes advantage of the older method, which
already gives translated string or substring.

The maintainters could always look inside a documentation
whether their implementation is up-to-date or should
be updated.  (This was not released yet, but the 
perl script for generating the documentation will probably
be released soon.)

There already are examples of the changed interface
in the last CVS releases.  You may have a look at
trFiles() which was totally replaced by trFile(params).
There also are good candidates to use exactly the same
approach, like trAuthors() and trAuthor() -- not done yet.

Conclusion: Let's start discussing the changes and 
select the first candidates.

Petr
 
-- 
Petr Prikryl, SKIL, spol. s r.o., pri...@sk...