Mailing List Archive: multi-lingual plugins and results

multi-lingual plugins and results

Sep 22, 2002, 5:25 AM

Post #1 of 3 (480 views)

As I was spec-ing out the requirements and time needed to translate the
plugins into spanish, and put spanish named and information into the
nasl's, it occurred to me that 'normal' plugins with no custom results
would work fine, but plugins that had results overrides would not.

As an example, this would be fine, it picks up the language from the
nessusrc

security_hole(80);

While the original nasl concept does a great job in the multi-lingual
area, more and more plugins do have custom results, based on additional
string values and/or making a severity decision (like safe_checks()
results vs full dos attack type results)

but this would most likely only show the results in english:
despite having different 'desc' in different languages in the description
sections.

security_hole(port:80,data:"English only results);

Is there a way to do some 'language' test on those, like:

results["english"] = "English report";
results["French"] = "well, whatever";

security_hole(port:80, data:results);

or:

if (_language >< "French")
security_hole(port:80, data:"french stuff");
else
security_hole(port:80, data:"English stuff");
--
Michael Scheidell, CEO
SECNAP Network Security, LLC
Sales: 866-SECNAPNET / (1-866-732-6276)
Main: 561-368-9561 / www.secnap.net
Looking for a career in Internet security?
http://www.secnap.net/employment/

Re: multi-lingual plugins and results [ In reply to ]

schmitt at TI

Sep 22, 2002, 11:32 PM

Post #2 of 3 (474 views)

Permalink

Michael Scheidell wrote:

>Is there a way to do some 'language' test on those, like:
>
>
>if (_language >< "French")
> security_hole(port:80, data:"french stuff");
>else
> security_hole(port:80, data:"English stuff");
>
Hm, I don't think this is a good solution. Imagine what the code looks
like if we support German, Spanish, Greek, Russian, etc. as well. You
also have to face the problem that you must find all occurrences of
strings that are to be translated.

I know that this would cost much more effort but stealing some ideas
from gettext might result in a better solution.

Michael

--
=======================================================================
Michael Schmitt Telefon: +49 651 97551-40
Institut für Telematik Telefax: +49 651 97551-12
Bahnhofstrasse 30-32 WWW: http://www.ti.fhg.de
D-54292 Trier E-Mail: mailto:schmitt@ti.fhg.de
=======================================================================

Re: multi-lingual plugins and results [ In reply to ]

arboi at noos

Nov 12, 2002, 4:19 AM

Post #3 of 3 (462 views)

Permalink

Michael Schmitt <schmitt@TI.FhG.DE> writes:

> I know that this would cost much more effort but stealing some ideas
> from gettext might result in a better solution.

Here is another trick:
let's say that we define in the NASL parser a couple of variables that
looks like
LANG2=fr_FR
LANG1=fr
And maybe PREFERED_CHARSET=ISO-8859-1

We modiy the include() function so that it returns 0 if the file
cannot be found or parsed and 1 it everything is OK.
We add a script_output_charset() function. If the parameter is void,
it doesn't modify the default charset.

Then :
-------- gizmo.nasl -------
desc="This script is just a demo
Risk: none";
name= "gizmo";
summ=" gizmo demo script";
fam = "Demo";

if (! include("gizmo." + LANG2))
include("gizmo." + LANG1);

script_summary(summ);
script_description(desc);
script_output_charset(charset);
etc.
----------------------------

We just have to write into gizmo.fr:
----------------------------
desc="Ce script est just une démo
Risque: aucun";
name= "Bidule";
summ="script de démonstration bidule";
fam = "Démo";
charset="ISO-8859-1";
----------------------------

If we do not want to put everything in the same directory, we can
create one subdirectory for each language.

--
mailto:arboi@bigfoot.com
GPG Public keys: http://michel.arboi.free.fr/pubkey.txt
http://michel.arboi.free.fr/ http://arboi.da.ru/
FAQNOPI de fr.comp.securite : http://faqnopi.da.ru/