 |
|
 |
 |
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
 John O'Conner's Blog
Localizing JavaScript files with JSPsPosted by joconner on August 18, 2008 at 11:42 PM | Permalink | Comments (2)Last week a friend asked an interesting web-based localization question. He surprised me with it. I wish that I had considered it before, but I had not. In my less than complete analysis of his problem, I found a solution, but I don't know if he'll like it. Hell, I barely like it myself, but it's what I came up with quickly. Here's the question: I want to localize a bit of JavaScript, nothing fancy now, just localized text strings. Once the JavaScript in pulled down into my browser, I don't want to make any more trips to the server to get text. You have any idea how I can get localized strings in my JavaScript? So here are a couple options:
The first option is certainly simple enough. Want a Japanese version of the JavaScript file? Great, create a second copy and localize the text in that file. Now you have two .js files: an original (maybe English) version and a localized second version. In your HTML or JSP file, which are presumably localized as well, you include the localized JavaScript file specifically. <!-- English html file --> <SCRIPT LANGUAGE="JavaScript" SRC="script/hello_en.js"></SCRIPT> Then, of course, in your Japanese HTML file, you'd have this: <!-- Japanese html file --> <SCRIPT LANGUAGE="JavaScript" SRC="script/hello_ja.js"></SCRIPT> But I have a problem with this. I don't like duplicating the JavaScript code across multiple files, knowing that only the localized text is different. I suppose it doesn't matter much really, but there's always the possibility of getting code out of synch. In some ways I prefer the more complex second option. Instead of loading entirely different localized JavaScript files, this option loads a single JavaScript file but injects the localized strings into it at runtime. In this option, you make a call to a single script but provide a language parameter along with the script link. <head> <title>Localized JavaScript Demo</title> <SCRIPT LANGUAGE="JavaScript" SRC="script/hello.js?lang=en"></SCRIPT> </head> Of course, in order to make this work, you now have to introduce a servlet or jsp to intercept this request, inject the localized strings, and return the localized JavaScript file. That's not that tough. The following jsp file accomplishes part of that:
<%@page contentType="text/JavaScript" pageEncoding="UTF-8"%>
<%@ taglib uri="http://java.sun.com/jsp/jstl/fmt" prefix="fmt"%>
<fmt:setLocale value="${param['lang']}"/>
<fmt:setBundle basename="com.joconner.demo.res.hello"/>
var localizedStrings = {
HELLO: "<fmt:message key="HELLO"/>",
GOOD_MORNING: "<fmt:message key="GOOD_MORNING"/>",
GOOD_AFTERNOON: "<fmt:message key="GOOD_AFTERNOON"/>",
BYE: "<fmt:message key="BYE"/>"
};
function sayHello() {
alert(localizedStrings.HELLO);
};
The final JavaScript file has a Although they aren't shown here, resource bundles hold the localized text -- one bundle for each language. That's my quick solution. Have another idea for creating localized JavaScript files? Let me know! Changing project encodings in NetBeans 6.5 M1Posted by joconner on August 04, 2008 at 10:11 PM | Permalink | Comments (2)I reported that NetBeans 6.1's project charset encoding feature would allow an unsuspecting user to destroy file data. That's still true...through no fault of NetBeans really. It's just a matter of fact -- if you start out with UTF-8 and convert your project files to ASCII or ISO-8859-1 or any other subset of Unicode, you will lose any characters that are not also in the target charset.
But NetBeans isn't going to let you hang yourself, at least not without warning you first. NetBeans 6.5M1 has added a warning dialog that alerts you when you change from the default UTF-8 encoding. Now instead of blindly following your request to change charsets, NetBeans will tell you the following: Just out of curiosity, I tried the same thing in Eclipse. When I tried to save, Eclipse said this: Eclipse would not allow me to save the file until I actually returned the encoding back to Cp1252...or as it suggests, until I removed the offending character. That's certainly one reasonable way to approach the problem. There is a 3rd way to do this, one that I like slightly better. One could simply \uXXXX encode the characters that are not in the target charset. So, for example, if you start in Cp1252, type the word "José" as a String or variable, then change the project to ASCII encoding, the IDE could simply \u-encode the string as "Jos\u00E9". Better? Maybe. After all, the IDE doesn't have to display "Jos\u00E9" to you. It could continue to display "José" in the editor regardless of the underlying "encoding" of the character. After all, when you edit your file, you don't typically care if the file is UTF-8, or UTF-16, ASCII, or even \uXXXX -- just as long as the characters display correctly and are not lost. What do you think of these options -- 1, 2, or 3? Or do you prefer something else from your IDE of choice? Discovering Java outside of SunPosted by joconner on July 23, 2008 at 02:29 AM | Permalink | Comments (30)After leaving the protective cocoon of Sun Microsystems, I have discovered a Java world I never knew. Of course, the blogosphere hinted that this world existed, but I didn't care. I barely noticed since that world had little relevance to me in my comfy space at Sun where it was always ok to use the latest release of the JDK and NetBeans. What is that world...a world where Java is NOT the primary business focus, where Java is just another tool, and where it's not even the shiniest tool either! I've discovered several facts since marching out into the lone and dreary world outside the Santa Clara or Menlo Park offices:
How can it be true? I wouldn't have believed it had I not actually worked with this team for the last 6+ months. The company's primary product runs on a Resin app server, and that runs on a 1.5 version of Java. 1.5...when 1.6 has been around so very, very long? What can this mean? Why? Eh, it turns out that, well, Java 1.5 has everything the company needs at this time. Well what about 1.6? Maybe one day...if we need it. Teams like Eclipse When I first arrived, the team used IntelliJ. When we decided to go to a freely available IDE (partly as a result of my nagging), the options were NetBeans and Eclipse. All along, my plan was to move myself and everyone else to NetBeans. Unfortunately, NetBeans didn't stay in the race long because of a problem with UNC paths and spaces in project path names. Maybe that's fixed now, maybe not. This team won't find out anytime soon. They're too busy coding and fixing bugs from the Eclipse IDE. The move to Eclipse was smooth, practically uneventful. Dare I even complain? The biggest problem with Eclipse is that it offers so many "perspectives" of a project that one can get lost in the various "views". The end result is that Eclipse allowed this team to use their existing source code structure to create Eclipse projects. NetBeans threw one too many hurdles up. Right or wrong, it didn't take much to throw it out of contention. And the group just wasn't in the mood for making something work. Eclipse seemed to meet needs immediately. Flash, not Java, as the rich client No Java 6. OK, fine, use 5 then. You want Eclipse instead. Brother! Sure, go ahead...despite my insistence that NetBeans can work equally as well. But Flash as the client! Come on, we have to be reasonable. Java is a perfectly good rich client platform, right? Apparently not in this shop. I blogged about this briefly before, and no one has budged on their opinion since then either. Sigh...another battle lost before I could even get a good head of steam. Is there a silver lining? Sure there is. Despite working without Java 6, NetBeans as my IDE, or Swing (or maybe Java FX), I'm learning loads about Spring, Hibernate, and web application development. I'm learning that web application software teams love Java, but they tend to relegate it to the backend, business logic space. Rich client apps? No way. How about Java Web Start? No need. So, how about just a little, teeny, tiny applet then? Get outta here. Flash, flex, swf files...sure, but no Java on the front end. This particular team won't even consider Java there. I can't even begin to argue against Flash at this point. 3 battles lost. So, really is there anything good here. Again, sure there is. From my one perspective, sitting in my cube at a web-oriented, software-as-a-service company, it seems clear to me that Java definitely hasn't lost any ground on the server side. Maybe it's even gaining momentum there. But what of Java on the client side? If Java ever had any momentum on the desktop, that momentum has all but sputtered out -- at least here. What I need is a few good tales of client side Java. Somebody please raise my spirits and tell me I'm just going through a particularly dark phase of my career! Maybe I'll wake tomorrow morning to find that companies really are producing desktop Java apps, Java 6 is everywhere, and NetBeans is *the* IDE of choice among all developers. [Added after original post] At 2 in the morning, my brain doesn't speak in complete sentences. Thoughts jump randomly. So now after a couple hours of sleep, I've gone back through this post and made some very minor edits just to clarify.  |
|
August 2008
Search this blog:CategoriesAccessibilityBusiness Community Community: Global Education and Learning Community Community: Java Communications Community: Java Games Community: Java Specification Requests Community: Java Tools Community: Java Web Services and XML Community: JavaDesktop Community: JDK Community: Mac Java Community Community: NetBeans Databases Deployment J2EE J2ME J2SE JavaOne JXTA Open Source Programming Swing Tools Web Applications Archives
August 2008 Recent EntriesLocalizing JavaScript files with JSPs Changing project encodings in NetBeans 6.5 M1 Discovering Java outside of Sun ArticlesSynchronizing Properties with Beans Binding (JSR 295) All articles by John O'Conner » | |||||||||||||||||||||||||||||||||||||||||||||||||
John O'Conner is a software architect, consultant, author, and speaker.
After many years developing the internationalization features of the
Java platform at Sun Microsystems, he is now actually trying to use
those features in real world projects.
 java.net RSS Feeds
|
