On Thu, 2 May 2002, Thomas Reinke wrote:
> Vincent Renardias wrote:
>
> > I see the following pros:
> > - only 1 translation file per language for all the plugins. Thus making
> > the translators' work much easier: only one file to edit instead of ~900
> > nasl files.
>
> This really depends in a big way on how the translation will be
> done. If you're going to have one translator, fine - this makes
> sense. If, on the other hand, you are going to have a community
> of 20 or 30 translators/script writers, then this becomes a major
In my experience, this is not an issue. Even for big projects like The
Gimp or GNOME. Translators just need to use patch and have a minimum of
coordination between them (like in any software projects anyway).
> headache. Not to mention - having one file introduces at least
> one other major problem: script writers that decide to re-use
> "string"s across NASL scripts - that would be a disaster from a
> long term perspective.
gettext comes with a tool to automatically retrieve strings to be
translated from the code. If there have been previous translation, it's
pretty smart to merge them.
> IMHO, I don't think this would be the right way to go given the
> distributed nature of the NASL script contributions.
Although gettext is certainly not perfect, it is as far as I know the best
solution. Having people edit hundreds of nasl files to hunt for strings to
translate is not IHMO a good way.
Not to mention that many translations would be duplicated between plugins,
and after the 3rd language, the nasl file will contain more translation
information than actual code, this will make the situation even worse.
Which alternative to gettext do you suggest ?
Cordialement,
--
Vincent RENARDIAS
Directeur Technique
StrongHoldNET / http://www.strongholdnet.com
