English | Deutsch
Home »

OpenVAS Change Request #36: NASL: Remove current i18n concept

Status: Voted +7. Done.


To get rid of a unmaintainable concept for internationalization (i18n) of NVT descriptions.

To lower the amount of source code lines and code complexity of NASL scripts.

To prepare for a realistic concept for i18n.


Automatic clean-up script by Markus Schröders on openvas-plugins


Currently, the description part of NASL scripts allows to specify strings in different languages via script_name(), script_description(), script_summary(), script_copyright() and script_family().

The translations are defined in the same code which is regarded a broken concept. Approving a script change can't be done for languages not understood. English is the only realistic basis as it is the generally used language in the area of IT security.

In fact, i18n support should work in the same way as the classic gettext works: mark strings that can be translated and have translation tables outside of the actual code. Changed strings automatically will lead to invalidation of translation until these are updated manually.

Before introducing a real solution for i18n, the broken concept needs to be removed entirely from the code base.


With regard to translated strings, almost no effect is expected because it was already hard-coded to use English. Only personal NASL scripts that did not specify any English texts will cause an effect for the user.

Considerable reduction of code volume, perhaps some speedup for launch of openvasd.

Design and Implementation

Since OpenVAS 1.0, a default fall-back is implemented in a way that instead of e.g. set_description(english:"text", francais:"test") also set_description("text") will do the same. Thus, any i18n elements in the NASL source codes can be removed. However, this should be done step by step to have readable svn commits, e.g. first all German and Portuguese strings, then any French, then the superfluous "desc["english"]=" style and finally the "english=" parameters. The scripts by Markus Schröder should mostly automatize this task.

Once the NASL scripts are cleaned up, the module openvas-libnasl can be adapted as well. However, this should be introduced for the 2.1 branch to ensure consistent behaviour for 1-0 and 2.0 branches.

Finally, documentation and sample files should be updated accordingly.