Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Using AspectJ for internationalization


Bo,

Your first problem is trying to determine what should and should not be translated using context that is not necessarily available at the join point. Your next problem is determining how it should be translated. Most messages contain inserts e.g. resource names which should not be translated and whose position in the message changes from language to language. For these reasons you are better off using a messaging framework which is called explicitly. You can still use an aspect with declare error/warning to ensure no-one calls System.out.println().

Matthew Webster
AOSD Project
Java Technology Centre, MP146
IBM Hursley Park, Winchester,  SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal)
Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
http://w3.hursley.ibm.com/~websterm/



"Bo Zimmerman" <bo.zimmerman@xxxxxxxxxxxxxxxxxxxxx>
Sent by: aspectj-users-bounces@xxxxxxxxxxx

15/12/2006 17:06

Please respond to
aspectj-users@xxxxxxxxxxx

To
<aspectj-users@xxxxxxxxxxx>
cc
Subject
[aspectj-users] Using AspectJ for internationalization





Hello all you AOP gurus.
 
An amusing idea occurred to me, and I'm doing my darndest to try and implement it, but having troubles...
 
My idea is to use AspectJ as an internationalization mechanism for Java programs to go multi-lingual "on the cheap".  It would work by putting Around pointcuts for string literal references that will, when they are referenced, get themselves replaced with a matching hashed string from a ResourceBundle in another language.
 
The idea is simple.  The idea is beautiful.  The implementation is neither.
 
My first idea was to capture String.new(..) calls, assuming that, when a string literal like:
String STR="blah blah"
.. occurs, there is a string creation for the STR variable, and another for the "blah blah" literal, which is then copied into the s under the covers.
 
The idea then would be to detect and ignore STR's creation, and advise the creation of "blah blah" by returning a string different than the one created.
 
Such detection becomes even more vital when one considers the following example:
 
String INPUT=new BufferedReader(System.in).readLine();
if(!INPUT.equals("GOODINPUT"))
    System.out.println("Your input, "+INPUT+", was not GOODINPUT.");
 
In this case, we would need to advise the creation of literals "GOODINPUT", "Your input," and ", was not GOODINPUT" but *ignore* the creation of INPUT itself and any value it is assigned.
 
This is also why it is insufficient to advise System.out.println(String) calls -- since by the time it gets to that point, the string has been mangled with the users INPUT, and is no longer in a translatable state.
 
So that's the plan: what have I tried?
 
1. I can advise StringBuffer calls, which appear to occur when a String needs to manipulate itself by appending data and the like.
2. I can advise System.out.println(..) calls, for what good that's worth (NONE).
3. I can NOT advise java.lang.String.new(..) init()'s.  They are ignored, utterly, completely, and always.
 
That last is my real sticking point.  I was hoping to somehow capture those String inits and somehow (don't know how) "detect" whether the init is of a string literal, or a new user variable.
 
Good input is, as always, greatly appreciated.
 
- Bo Zimmerman
(http://www.coffeemud.org)
 
 
 _______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users


Back to the top