I am staying India(has more than 20 languages) I am trying to implement java-internationalization in the website.
But in Locale.getAvailableLocales() the local languages are not available. is it possible to implement internationalization in my case?
If possible what will happen to the fonts? How am i going to load the proper fonts in the client browser?
Which framework to implement Struts or Spring?
I can't claim to be an expert in Java internationalization - all of my work which cared about localization dates back to when we had to do all that by hand.
If you don't want to do that (which is no harder now than it was back then), it appears that you can still make use of Java's automated I18N services.
It appears that in order to support languages, number formats, etc, which are for locales not yet supported, you'll have to create a Locale-sensitive service provider, which got much easier in 6
There's what looks like a good tutorial here.
I think you are asking multiple questions here, and they are orthogonal to each other.
For the Locale.getAvailableLocales() question. If the built-in locales are not enough, you can simply create more. The locale object just represent the locales that your program knows, it has nothing to do with you the system performs --- more specifically, no corresponding locale object does not mean you cannot support the locale.
For the font, typically you will use UTF-8 for a i18n site, so as long as your content type and charset is set properly it should render correctly in the client browser.
The framework question really depends on what you are trying to accomplish, and what do you want to gain from it.
I believe there are more locales available when using a JDK than a JRE.
Locale.getAvailableLocales() returns a list of locales whose LocalData is installed in sun.text.resources package of JRE.
This list may not matter to you. Currently, the LocalData only contains local number and date formatting information. If you don't have any special format, you can just pick a locale whose format is the same as yours, like "en_IN".
Charset is another issue. If you localized resources are in Unicode, you are all set. Otherwise, you need to make sure the charset/encoding is supported by Java so it can convert it correctly.
Don't worry about font. It has nothing to do with server. It's either specified in HTML or CSS. As long as the browser supports the fonts, you will be fine.
Java itself is I18N ready so it doesn't matter which framework you use. Struts provides taglib for I18N (bean:message) but you can also use JSTL (fmt:message).
Related
I am developing an android application in which the user requirement is to have that app in multi language. I need to know which is the best way to do so.
By storing the languages(string.xml) in a folder. For eg: For french in a folder named as value-fr.
By storing all labels and respective languages in a Db table and retrieving those on different language selection.
From the above two method which is the best way to be done considering the app performance.
The best way is to go for the resources folder by storing all the languages of French in the res/values-fr folder and reflect it all over the application.
By following the resources way you do not need to bother about managing the each and everything in your application flow. The application will be directly changed according to the French language as the user will change its language to french. It will directly access all the resources from the value-fr folder if you have kept.
If you will go by database way then in that case you are supposed to check for the locale and you will have to manage all the values of your application according to the local each and everytime which will lead you to complexity of handling resources.
So, Why not go for the best way if android is providing you such great functionality.
You can do either way, but the best way is option 1. i.e. By storing the languages(string.xml) in a folder like values-Fr. Using this will allow android to do the handling automatically instead of you telling database which is the current locale you need.
You should make the different folder in the res to support your application in multiple language.
Android handle all the things automatically, it picks the string resources from that file which is your current language of the device.
Just playing the Devil's Advocate - Android only supports ISO 639-1 (2-letter) codes at this point, Java 7 which supports ISO 639-2 (the three-letter language codes) is not natively supported by the device's framework for resource directories.
If your requirements expect you to adhere to the three letter language codes set in the standard than you may have to look elsewhere for this support (be it an in-house solution or another third party solution).
My organisation is about to embark on the long process of internationalizing (i16g?) its corporate website. The website is a mix of Java EE (JSP/Servlets, no EJB) and static content pushed from the (Documentum) WCM.
While I have experience using the "built-in" mechanism of using ResourceBundle's along with the associated properties files for each language/locale (containing the "KEY=Translated value" approach), where we simply reference the KEY value where we want the translated text to appear.
My director has mentioned that he has used a different approach at a previous organisation whereby they used a 3rd-party library (he does not recall the actual name) which included the actual [english] text in the webpage (to aid developers) which was replaced at run time with the translated content from the config xml file. (anyone know which library this would be?)
I am interested in what other approaches/libraries/frameworks there might be out there to facilitate this.
Thanks
Your boss probably meant gettext, just like #Pawel Dyda mentioned, but cosmopolitan may also be of interest to you.
My company also maintains a GNU gettext-related library for Java (and very soon with extensions aimed at Scala).
Not only does it support all of the goodness of GNU gettext, it also simplifies output AND input of date/timestamps and currency, include facilities for using "wiki" formatting in translations (so you can output HTML bold on a word, for example), java message formatting, generalized "escape" support (so the output can be auto-escaped for inclusion, say, in HTML), and currency rounding.
It is open-source, and currently on github at https://github.com/awkay/easy-i18n/
When I hear you are using ResourceBundles, I see something like this:
ResourceBundle rb = ResourceBundle.getBundle("messages", locale);
String someString = rb.getString("some.key");
If this is your approach for Java Server Pages (using such snippets in scriplets), this is wrong. Instead, you should use JSTL or Spring message tags.
As for your inquiry, I believe they used Gettext (sorry no link, as I am running out of time).
This is not necessary the best approach. JSTL approach is the most common for JSP and you should stick to it, unless you have very good reasons not to.
It worth looking at http://alexsexton.com/blog/2012/03/the-ux-of-language/ it has a good explanation of the idea behind gettext and the limitations of the gettext design a better approach to gettext is the ICU message format this is what the JDK MessageFormat class is based, on http://site.icu-project.org/home there is also a javascript library based on the ICU message format https://github.com/SlexAxton/messageformat.js
I hope, it's not too late to suggest one more solution: https://github.com/resource4j/resource4j
This library has integration with Thymeleaf web page renderer, which solves the problem you've mentioned: you include in page template the English text and then substitute it with localized version in runtime.
I need to parse a simple HTML page with a simple form in it. The answers to similar questions on StackOverflow suggest using one of a large variety of non-standard Java libraries such as TagSoup, JSoup, HTMLParser and many others.
However, a web search revealed that there exists some standard functionality in Java SE via this class: http://docs.oracle.com/javase/7/docs/api/javax/swing/text/html/parser/ParserDelegator.html
My sub-questions are:
Is it really true that the standard ParserDelegator class can parse a use case like mine?
What are the limitations of the standard library that create the need for so many non-standard libraries?
Does the fact that ParserDelegator is within swing preclude using it in a regular EC2 cloud server for a web application? Would I have to jump through a lot of hoops to get around the headless aspect or would it be just a small tweak to the configuration?
If the standard one is not recommended, which non-standard one should I use, given: (a) my desire to not stray far from the standard; (b) my simple use case; (c) desire for a mature reliable implementation; and (d) no size or weight limitations since this is a server application as opposed to an embedded client. API is a far lower priority so while I do appreciate JSoup's CSS selector like API, the other concerns (a) through (d) override it.
Thank you.
JDK has built-in HTML parser that supports HTML 1.0 or so. It should support parsing of base text formatting tags and forms.
The reason to use other, third party parsers is requirement to support "real" HTML pages DHTML, JavaScript etc.
JSoup is one of popular parsers that can do the job. For more information about other implementations please take a look on the following discussion:
Pure Java HTML viewer/renderer for use in a Scrollable pane
Atlassian JIRA is a powerfull issue tracker which I am using it for a long time, as it is a good issue trakcer I bound to Localize it to my locale.
I found Their page in Linkedin and asked them if I can translate it, as it was welcomed in the community I started translating, I'd post first part of my translation for them and after a while they told me here that
Java does not support fa_IR locale.
and
try to force java to support fa_IR
refactor TAC so having locale is
What can I do to get JAVA attention to support fa_IR locale or something else to help JIRA supporting it? Actually I didn't get the minning of refactor TAC so having locale is how can I deal with it?
The Sun/Oracle Java implementation is based on OpenJDK (or rather, they've released the initial official implementation under GPL, as OpenJDK) and the two projects are closely linked.
You can check the contributor guidelines here: http://openjdk.java.net/contribute/ (which includes a link to http://bugs.sun.com/)
Update : Here is the page you can find the guidline to add another locale to JAVA
http://openjdk.java.net/groups/i18n/ look for Include locale in JRE in that page
Here's the original text
Alternatively, if the locale is
correct we will have to postpone the
implementation. There are two
solutions we can explore, but neither
in the short term:
try to force java to support fa_IR
refactor TAC so having locale is optional
Neither of these is anything you can fix. The first means Sun / Oracle will have to ship an additional Locale with their JRE, the second means Atlassian will have to rewrite their code to not use Locales. Neither of these are things you can do anything about.
You can't force Oracle to support "fa_IR". You can ask them. You can offer them large amounts of money to do it. But that's about the limit of your leverage.
Somehow, I don't think that attempting to put moral pressure on Oracle is going to work. They are a commercial organization whose primary responsibility is to make money for their share-holders.
You could consider implementing the locale yourself by modifying and building your own version of OpenJDK 6 / 7. Indeed, you could then contribute this back to the OpenJDK project so that other people will benefit from it in some future release. (Probably not until OpenJDK 8 now ...)
You can provision your own Java locales through the SPI - here's an example.
When it comes to I18N-enabling software, you'll have to make a decision about how far you want to go - currencies, calendars, time zones, UI layout, etc. Swapping strings is the easy bit.
How can I use ServletRequest.getLocale() in JSF application, when Servlet is absent in my code and is provided by JSF implementation? I'm trying to use ServletContextListener, but is it possible to reach ServletRequest from ServletContextEvent?
Anyway, what is the correct approach?
FacesContext.getCurrentInstance().getExternalContext().getRequestLocale();
?
The correct way in my opinion is to provide the links on your home page for various locales your application needs to support. This is less intrusive for the end user. Otherwise the end user has to keep changing the locales browser specific way. Also different browsers send the locale different ways to the server which is also problematic depending on your usecase.
I strongly suggest you go through this tutorial.