My requirement is to display localized text messages in a J2EE web application. I know J2EE provides very good support for this.
My question is what is the practice followed to have the localized messages stored to be used by the application. If I want to display Japanese / Chinese kind of messages which are not like English like char sets how do we get that messages/text into the properties files or Database tables.
Resource Bundle. The basic idea is for all text to be localized/internationalized to be abstracted out and replaced by 'key' in source code, and at runtime you can switch among locales. Different implementation of resource bundles are available to be selected from, e.g. list resource bundle or properties resource bundle. It's also possible to write your own implementation, like database-backed.
Java Internationalization: Localization with ResourceBundles is a good and quick starting point.
Interestingly, Try alternatives to ResourceBundle lists some disadvantages of resource bundle and provides an alternative.
Related
What is considered the best strategy for URLs of translated websites? Something I see happen frequently is:
http://example.com/english-slug.html
http://example.com/de/english-slug.html
http://example.com/fr/english-slug.html
This has the (minor) advantage that a user can manually switch to another language by modifying the URL. The disadvantage seems to be that the URL consists of a slug in the wrong language for every page not in the default language. That would cause a SEO penalty, I think.
The alternative would be to translate the slugs as well and optionally omit the language identifier as well:
http://example.com/english-slug.html
http://example.com/deutscher-slug.html
http://example.com/slug-francois.html
Some languages do not really lend themselves to be 'sluggified', such as Russian, Chinese and Arab. You'll end up with transliterations that make little sense.
I think you should use language tags and translated slugs:
http://example.com/en/hello-world
http://example.com/de/hallo-welt
Why language tags? To avoid collisions.
Sometimes you might want to have the same slug for different languages (for example, "team" in English as well as in German).
Why translated paths? For better usability.
Not all users understand the "default" language, and depending on its script, they might not even be able to type/remember/dictate the slug. (It doesn’t make sense in the first place to use human-readable slugs that only part of your users are able to understand.)
Yes, it would be a "(minor) advantage that a user can manually switch to another language by modifying the URL". But it’s unlikely that users or search engines would expect this to work (see my related answer on Webmasters). So you would gain little (URL hacking for advanced users) and lose much (bad usability for users using the non-default language).
That said, it would still be possible to enable this URL hacking feature in most cases: When users change the language tag de (in /de/hallo-welt) to en (/en/hallo-welt), you could check if it exists (if yes, show it), and if not, check if there exists a slug "hallo-welt" in any language, find its English translation and redirect to it (from /en/hallo-welt to /en/hello-world).
Another way is setting the language as a query string parameter, such as:
http://example.com/hello-world?hl=en
http://example.com/hallo-welt?hl=de
for example Google Flights web site uses this method.
The best solution, if you can afford it, is to send the document with the right name, that means, using the right word on each language.
Of course each document should be sent with the respective language setting on the headers.
For storing them, you can use folders and let the web server choose the right document according to the language preference; or you can use server side technology, like PHP, perl, etc to send the document and adjust the URL.
In any case, you have to have a default language to be sent when you don't have the requested language.
If you can't or don't want to send document with the right name, using subdomains is the best next option. This option, is not as common as adding the language after the domain, and that means, that people may not be used to it, although, it has some advantages, for instance;
Each language behaves like a whole new URL/site (almost).
People feel like visiting a dedicated site, not a subsection where the second language is relegated and may fail at any moment (some content may not be translated).
Some people are not familiar with their two letter representation of language, but everybody knows how his language is called and spelled.
It generates cleaner URL's.
It is believed that having subdomains increases appearance on SERPs (I don't have knowledge of this and it may have changed).
It's easier to have different layouts if you want to.
It's easier to set different servers according to language.
Of course subdomains have some disadvantages, like:
A bit more work to set properly from the server perspective.
Less collaboration from the part towards high ranking.
Some people may not expect it but expect a subfolder.
Next would be the subfolder option, as you show on the question. This is the recommended way if your main perspective is SEO since all the relevance of the domain stays on that same domain and each language helps to a common "pot" of ranking.
My perspective when choosing a solution, is never SEO, under any circumstance. Whatever ranking I get is due to the content itself and the best use I can give to technology. But I understand that my point ov view is not the most common.
One thing to consider also, is that you should provide some kind of explanation or help the user so he can take actions to change to the preferred language. It may be using icons, a tooltip, or any other method that works for your design and verbosity.
One thing to avoid, and you didn't ask for it, but is related; is using language autodetection. Lots of times, the user is in a different country or using a version of a browser that has a different language from what he can understand and the autodetction just makes a big mess. Offer the default version and a clear way to change it.
I am using Ruby on Rails 3.1.0 and I would like to know if it is possible to handle text translations for data stored in database tables. Is it possible? If so, how?
For example, if I have a database table column named Title and in that I have a record with the Title value set\stored to "car", I would like to show
the text "automobile" for italian people;
the text "auto" for german people;
and so on...
For user generated content it's best to store the language with the content.
You can then have your users create "copies" of this data with a different language reference.
Depending on how much data you need to change per table a different gems might be suitable for your needs. I18n gem is NOT a good choice here, as it's meant for static content. See: https://www.ruby-toolbox.com/categories/i18n
Ruby can help you translate the words from one language to another, but only by providing hashes and structures or code algorithms that allow you to do lookups. By itself it knows nothing of the meaning of words, and cannot translate words.
For your purpose, you should build a table of translations, with the primary language words in a primary field, and their translations in secondary fields, one field for each language. Then you can quickly look up all the words for a form in German, or Italian, and substitute them into the form.
You can setup your rails application for internationalization using Rails Internationalization (i18n) API. You would need to pass and set the locale. The locale files would reside in config/locales. As mentioned by the tin Man, the locale file is a key:value file. Here you can override custom rails defaults.
Locale can be set from params and also from domain name. The Rails guide is actually the best place to start with in my opinion.
http://guides.rubyonrails.org/i18n.html
As already mentioned in the other answers, you'll want to use the rails i18n functionality to get this to work.
There are however alternative ways of storing your translations. This railscast describes how to set up a redis-based translation backend, as well as links to a whole bunch of different backends.
If you just want to store your translations in a database using ActiveRecord, I'd suggest you have a look at i18n-active_record.
With these plugins you can easily store your translations in the database, and have your application look them up for you using I18n.t('some_translation_key').
I am writing a site with more than one language, is there any easy way or technique to reduct the workload of changing which text to another language.I have an idea, but I don't know whether it is suitable or easy enough. I create a XML that contain all the text in my web, when the user change their language, my program will base on the language the user choose, and get the suitable tags from the XML, and fill in the page. What do you think? or maybe is there any more easy way to do?
(Assuming I am using RoR, if suggest any gems.)
Check out Rails Internationalization (I18n) API:
The Ruby I18n (shorthand for
internationalization) gem which is
shipped with Ruby on Rails (starting
from Rails 2.2) provides an
easy-to-use and extensible framework
for translating your application to a
single custom language other than
English or for providing
multi-language support in your
application.
I wrote a blog post about "Scoping By Locales". It suggests to put all your content in the database and when you want to fetch it, use the I18n API to set the user's locale to be their language and the fetcher will default to that language.
While I have experience developing Rails apps in English, I am a blank slate when it comes to handling globalization, so please don't shoot me in the head if my question 'doesn't make sense' :)
I have been asked to add multi language feature to a part of a Rails app that I am working on. Initially its only going to be 2 languages, French and German. The content that will be translated (which is in English now) is rendered using partials at the moment hence I am getting a bit inclined on creating partials with different languages and then based on the users language selection call the relevant partial - Would you recommend this approach?
Although it seems a heavy weight solution for this particular purpose, but I am also looking at the Rails Globalize plugin. This seems to appeal if I look at the long term gains, something like what if later I am asked to translate the entire app.
Any insights on what would be a proper structured approach to handle globalization in Rails?
Many Thanks
Have you had a look at the i18n (internationalization) API that is in Rails itself as of 2.2? It makes it easy to store your language translation files as .yml files, so a fr.yml and a de.yml or whatever. It also steps through different approaches of making languages accessible via browser prefs, or URLs, subdomains, etc. In your HTML template files you use symbols to specify the keys for the string you've translated. At least in my basic usage and testing, it was very easy to work with.
I preffer using translator instead of Rail's i18n, since the former handles "scoping of translation" automatically. I recommend you give it a look.
This is a great article on how to use Ruby's GetText to localise you Rails App.
I am making a RoR site that is delivered in several languages, and want to change a part of the url by its language.
ex.
http://xxxx/en/index.html
http://xxxx/fr/index.html
I know I can do this via the route.rb
map.locale ':lang/index.html'
and designate the language when calling this in view. However, there is an exception
to this, when in the default language of the site, I want the url to be without the language identifier,
http://xxxx/index.html
as so.
Currently I cannot find a way to git rid of the / after the language identifier,
http://xxxx//index.html
is there a better way to do this?
It's not (yet) possible.
But you'll find some solution on this stackoverflow question.