[Openvas-discuss] Security language is english !?
Hi, I once again stumbled across problems caused by the mutlilingual features of OpenVAS server (as inherited by Nessus). I wonder whether it makes sense at all to have the NASL scripts allow for other languages than english. IMHO this adds only unnecessary source codes, user confusion, extra-time writing NASL scripts and potentials for inconsistencies. Not to forget the maintenance problem! AFAIU, the security language is english. All relevant sources of security alerts are in english and need to be understood anyway by the auditors. (Yes, there are some non-english sources of security alerts, but in fact these could even be better implemented as separate base NASL scripts and form some sort of a profile of its own). So, I'd be interested in your opinion/thoughts on whether we should remove any of the Server-side localization support for NASL scripts ? Best Jan -- Dr. Jan-Oliver WagnerIntevation GmbH, Osnabrück Amtsgericht Osnabrück, HR B 18998 http://www.intevation.de/ Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner ___ Openvas-discuss mailing list Openvas-discuss@wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss
Re: [Openvas-discuss] Security language is english !?
On Wed, 30 Apr 2008, Jan-Oliver Wagner wrote: AFAIU, the security language is english. All relevant sources of security alerts are in english and need to be understood anyway by the auditors. (Yes, there are some non-english sources of security alerts, but in fact these could even be better implemented as separate base NASL scripts and form some sort of a profile of its own). True. So, I'd be interested in your opinion/thoughts on whether we should remove any of the Server-side localization support for NASL scripts ? I've just done a quick poll of our office regarding this. Amongst a Turk, a German, an Indian and a native English speaker, the opinion is that at a technical level, yes English is expected. However, the German also gave tha business justification that not everyone who might use OpenVAS might be technical. The Turk also made an interesting point, that in Turkey there is a large community of developers who spend their time porting applications to Turkish because they do not wish to use an English based application. I'm not sure of any specific conclusions to draw from this but maybe it's a problem to let the community solve. I do however wonder what effort would be required to port OpenVAS to GLib et al which might solve I18N issues. Tim -- Tim Brown mailto:[EMAIL PROTECTED] http://www.nth-dimension.org.uk ___ Openvas-discuss mailing list Openvas-discuss@wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss
Re: [Openvas-discuss] Security language is english !?
2008/4/30 Jan-Oliver Wagner [EMAIL PROTECTED]: Hi, I once again stumbled across problems caused by the mutlilingual features of OpenVAS server (as inherited by Nessus). I wonder whether it makes sense at all to have the NASL scripts allow for other languages than english. IMHO this adds only unnecessary source codes, user confusion, extra-time writing NASL scripts and potentials for inconsistencies. Not to forget the maintenance problem! Ok. My opinion: everything should be translated as much as possible, with mechanisms to guarantee that: a- translations are consistent with the text being tranlsated (this is easy to do the first time, but more difficult to do when the original text changes) b- when translations are not consistent they are not used (i.e. not presented to the user) I can assure you that if OpenVAS provided a way to properly i18nize the NASL scripts there would be people eager to use it. Some technical people use vulnerability scans to generate reports that they later have to translate to their mother language (hopefully after including additional info) to upper management. Actually, I think I saw once a Nessus translated into Spanish that a company intented to (illegally) sell it without contributing the translations to the community (even if the NASL scripts where GPLd). The problem with the current i18n features with the NASL scripts is that they cannot guarantee a) or b) like you can currently do with, for example, gettext (PO files). The translations are included in the script and there's no way to know that a translation has to be updated because the original (english) description changed. I think that the NASL scripts information in english should be converted into PO content that the GUI or server would read to present to the user (if translated) information in the reports (be it the GUI or printed reports) in their native language. It wouldn't be difficult to provide a conversion from NASL descriptions and informative texts to gettext, to make translations easy. It would be slightly more difficult to change the GUI (not the server) to use those translations if available. I do agree that the common technical language will always be (and will still be) english. But there are many countries in which english is, and will still be, a barrier which hinders use of certain technologies. Just my 2 c Regards Javier ___ Openvas-discuss mailing list Openvas-discuss@wald.intevation.org http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss
