Re: [Openvas-discuss] Security language is english !?
2008/5/6 Jan-Oliver Wagner [EMAIL PROTECTED]: Opinions? Even though client and server releases are different I don't suggest bundling the PO files with the openvasd release and have the server handle gettext translations. For several reasons: - the NASL code is actually in the openvas-plugins package, not in the server - it adds complexity to the server for a task unrelated to vulnerability scanning - you (probably?) have to modify the Nessus client-server protocol so that the client can provide the server its language settings (the client knows the settings based on the user's environment). I suggest taking this approach instead: - adding PO support for NASL scripts through a wrapper that takes the message text calls and generates POT files for them in the openvasl-plugins's po/ (or intln/) directory that translators can work with. - Separately, have the PO files be distributed by a separate openvas-plugins-XX package (with XX the language code). That package installs the proper /usr/share/openvas just like you provide openvas-plugins packages that installs the appropiate MO files for a given gettext domain (say 'openvas-plugins') at its proper location under /usr/share/locale/XX/LC_MESSAGES/OpenVAS-plugins.mo (with XX the language code) - Since the gettext domain would be different (different MO files) have the client change its gettext domain when parsing NASL input, so that it gets translated (you can see a way to do this in Squirrel's Mail plugins at http://www.squirrelmail.org/wiki/HelpTranslating, basically the OpenvAS client would have to swith to the 'OpenVAS-plugins' gettext domain when generating its output associated with the NASL info and then switch back to its own gettext domain after it. It might sound complicated, but to me it looks easier to do than the other approach (server side) which involves introducing gettext in the server and change the Nessus protocol so that client can provide it's language environment to the server. Regards Javier ___ 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 Tuesday 06 May 2008 16:18, Javier Fernandez-Sanguino wrote: 2008/5/6 Jan-Oliver Wagner [EMAIL PROTECTED]: Opinions? Even though client and server releases are different I don't suggest bundling the PO files with the openvasd release and have the server handle gettext translations. For several reasons: - the NASL code is actually in the openvas-plugins package, not in the server yes, I indeed hat the this module in mind, not openvas-server. - it adds complexity to the server for a task unrelated to vulnerability scanning yes, my intention is to get the code base of openvasd further reduced. - you (probably?) have to modify the Nessus client-server protocol so that the client can provide the server its language settings (the client knows the settings based on the user's environment). I thought that this could be neglected for a first step. The server is simply configured with a default language and will deliver corresponding strings if available. It is my understanding that most users of OpenVAS-Client have also installed and configured OpenVAS Server. I suggest taking this approach instead: - adding PO support for NASL scripts through a wrapper that takes the message text calls and generates POT files for them in the openvasl-plugins's po/ (or intln/) directory that translators can work with. yes, this is a working option. However, I thought I would be nice to add a _() integrated function to NASL and call gettext from it with the textdomain set to whatever is configured. Thus, openvasd would automatically deliver the translated strings to the client (or to log files) without more complexity than 5-10 lines of code calling gettext in a proper way. - Separately, have the PO files be distributed by a separate openvas-plugins-XX package (with XX the language code). That package installs the proper /usr/share/openvas just like you provide openvas-plugins packages that installs the appropiate MO files for a given gettext domain (say 'openvas-plugins') at its proper location under /usr/share/locale/XX/LC_MESSAGES/OpenVAS-plugins.mo (with XX the language code) or it comes with the feed. And we need some concept to have trusted (signed) translations like we currently have for the NASL scripts. - Since the gettext domain would be different (different MO files) have the client change its gettext domain when parsing NASL input, so that it gets translated (you can see a way to do this in Squirrel's Mail plugins at http://www.squirrelmail.org/wiki/HelpTranslating, basically the OpenvAS client would have to swith to the 'OpenVAS-plugins' gettext domain when generating its output associated with the NASL info and then switch back to its own gettext domain after it. I fear that it will get a update/maintenance problem when trying to have the po files at the client. Shouldn't the translations be where the original text is? It might sound complicated, but to me it looks easier to do than the other approach (server side) which involves introducing gettext in the server and change the Nessus protocol so that client can provide it's language environment to the server. hm, without having really tried it, I think it should be only few lines of code on the server side to apply a specific text domain. Maybe I should simply try to see whether I can proove myself wrong ;-) Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH 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 Tuesday 06 May 2008 18:05, Thomas Reinke wrote: So, I'd be interested in your opinion/thoughts on whether we should remove any of the Server-side localization support for NASL scripts ? While I've been a fan of localization support (given our environment, we often deal with more casual, less security oriented individuals who may not have a great working knowledge of English), I've NOT been a fan of doing it in the server itself. In my mind it doesn't make sense for the simple reason that if you take days and weeks to run a set of scans on a large network, it seems wrong that you are stuck with whatever language you used at the time you ran the scan. It would seem to me that if you change the language at the client level, the reporting language ought to change as well. Based on that, the current server-side localization code that was previously done is in my mind is pretty much useless (but hey, that's just my 0.02 worth). seems we all agree the current concept is broken by design :-) You bring up an interesting aspect: Should a scan result be translatable into more than one language? Does the gettext / po implemenations allow for easy back-to-english? If so, I could imagine solutions to allow a translation to various languages inside the OpenVAS-Client. But I have to move my mind a bit more about this... Best Jan -- Dr. Jan-Oliver Wagner Intevation GmbH 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
[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
