[OWASP-ESAPI] Internationalization

Tue Feb 17 12:06:26 EST 2009

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/ <https://webmail.aspectsecurity.com/exchweb/bin/redir.asp?URL=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 Williams
Sent: Tue 2/17/2009 8:00 AM
To: 'Jim Manico'; 'Andrew van der Stock'
Cc: owasp-esapi at lists.owasp.org
Subject: 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 Manico
Sent: Tuesday, February 17, 2009 12:33 AM
To: Andrew van der Stock
Cc: owasp-esapi at lists.owasp.org
Subject: 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 all
other ESAPI libraries will use when displaying user data
2) 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 locales
4) 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 Engineer
jim.manico at aspectsecurity.com
(301) 604-4882 (work)
(808) 652-3805 (cell)

Aspect Security(tm)
Securing your applications at the source
http://www.aspectsecurity.com <http://www.aspectsecurity.com/> 

_______________________________________________
OWASP-ESAPI mailing list
OWASP-ESAPI at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-esapi

________________________________

_______________________________________________
OWASP-ESAPI mailing list
OWASP-ESAPI at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-esapi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-esapi/attachments/20090217/d1eece2b/attachment.html 