[OWASP-ESAPI] Internationalization
Nishi Kumar
nishi787 at hotmail.com
Tue Feb 17 14:29:48 EST 2009
Google API sounds interesting but in a production environment how effective it is going to be is doubtful. I would suggest to do some testing on its effectiveness before using it.
Date: Tue, 17 Feb 2009 12:06:26 -0500From: pawan.singh at aspectsecurity.comTo: jeff.williams at owasp.org; jim.manico at owasp.org; vanderaj at owasp.orgCC: owasp-esapi at lists.owasp.orgSubject: Re: [OWASP-ESAPI] Internationalization
While researching for translation I came across a google-API. So, I was wondering how about translating the message strings on the fly with help of API like: http://code.google.com/p/google-api-translate-java/
So, to avoid maintaining resource bundle for different Locales:
We need to have current Locale set in the User object
We can get current Locale as ESAPI.getCurrentUser().getLocale();
In the EnterpriseSecurityException.java we can translate the user message into the current Locale with the help of the API and update it with the translated message string (which will be US en by default).
We can do same thing for both the user and server messages.
I am not sure about the performance of this API and how effective it will be to translate on the run time. But it will certainly avoid the need of maintaining Resource bundles for various Locales.
Thoughts?
--Pawan Singh
From: owasp-esapi-bounces at lists.owasp.org on behalf of Jeff WilliamsSent: Tue 2/17/2009 8:00 AMTo: 'Jim Manico'; 'Andrew van der Stock'Cc: owasp-esapi at lists.owasp.orgSubject: Re: [OWASP-ESAPI] Internationalization
I’m no expert in I18n or L18n, but I’m missing the MessageFormat part of this. I’d was expecting to have the current code change from something like this…
Logger.warning( “Bad stuff: “ + name + “ = “ + value );
To something like this…
Logger.warning( MSGKEY1, { name, value } );
I don’t see the need for an Internationalizer class here. What am I not understanding??? I thought the Logger interface can handle getting the Locale from the User, getting the message pattern from the resource bundle, formatting the message, and logging it.
Note that there is some support in Eclipse for extracting strings and putting them in a resource bundle. I haven’t used this.
--Jeff
From: owasp-esapi-bounces at lists.owasp.org [mailto:owasp-esapi-bounces at lists.owasp.org] On Behalf Of Jim ManicoSent: Tuesday, February 17, 2009 12:33 AMTo: Andrew van der StockCc: owasp-esapi at lists.owasp.orgSubject: Re: [OWASP-ESAPI] Internationalization
How about this for i18n....ESAPI doesn't really care how you manage your translations, it just wants to know how to translate a string for the current locale (which will be part of the ESAPI users object like ESAPI.getCurrentUser().getLocale();If we just wrap all of ESAPI's static strings through a simple i(String text) function and be done with it, that might be all we need to do and pass the rest of the task of translation management be up to each app....- Jim
Gettext uses _("text") for the primary translation function; I prefer Drupal's i("text") myself.Gettext also operates on flat files (.po) files and is more of a low-level UNIX utility. Folks in the Java world do indeed use it at times.... The most common Java abstraction to gettext http://xnap-commons.sourceforge.net/gettext-commons/apidocs/org/xnap/commons/i18n/I18n.html is really tied to resource bundles. I think we want to aim higher up the stack.... I (am many others) want to build an Internationalization engine for our apps that is database driven. As long as the ESAPI abstraction allows for that, I'm good.- Jim
Jim,
There is already a GNU gettext interface which many platforms (C, PHP, etc) use. We should sub-class from that, as it's an interface that would be familiar to many.
http://www.gnu.org/software/gettext/
http://au2.php.net/gettext
PHP is appalling for I18N, so any effort you make will improve their lot until PHP 6 arrives.
.NET has a very sophisticated locale, I18N, culture and location environment, and we should make ESAPI transparent for that platform. Folks who are more familiar with .NET should pipe up now!
thanks,
Andrew
On 16/02/2009, at 2:19 PM, Jim Manico wrote:
I've been talking with Pawan off-line about ESAPI internationalization,here are my thoughts: 1) We need a basic Internationalization interface for ESAPI that allother ESAPI libraries will use when displaying user data2) We need to add a "locale" attribute to the ESAPI User object.3) Functions in the Internationalization interface supported should include a) convert a string to a specific locale (this one only will be used mostly by the other ESAPI classes) b) edit a certain string/locale combinatio c) delete a certain string/locale combination d) list all supported locales4) The interface should be able support several different kinds of persistence engines - resource bundles or a database. Here, let me just bust out some psuedocode... Interface Internationalizer { //sourceData is a token to represent a label on a GUI in the apps base language, usually US english String result function i(String sourceData, Locale l); //handles add or edit events void editTranslation(String sourceData, String editData, Locale locale); void deleteTranslation(String sourceData, Locale locale); //delete all translations for a specific token void deleteTranslation(String sourceData); //delete all translations for a specific locale void deleteTranslation(Locale locale); List<Locale> getLocales(); List<String> getTokens(Locale locale); } Thoughts?- Jim
-- Jim Manico, Senior Application Security Engineerjim.manico at aspectsecurity.com(301) 604-4882 (work)(808) 652-3805 (cell) Aspect Security™Securing your applications at the sourcehttp://www.aspectsecurity.com
_______________________________________________OWASP-ESAPI mailing listOWASP-ESAPI at lists.owasp.orghttps://lists.owasp.org/mailman/listinfo/owasp-esapi
_______________________________________________OWASP-ESAPI mailing listOWASP-ESAPI at lists.owasp.orghttps://lists.owasp.org/mailman/listinfo/owasp-esapi
_________________________________________________________________
Windows Live™: E-mail. Chat. Share. Get more ways to connect.
http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_allup_howitworks_022009
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-esapi/attachments/20090217/370c1ab7/attachment-0001.html
More information about the OWASP-ESAPI
mailing list