| Path: | README |
| Last Update: | Thu Jun 14 19:11:00 -0700 2007 |
Globalite is meant to be a breed of the best internationalization/localization plugins available for Rails.
Globalite should provide you with a 3-in-1 solution:
On top of that: yml files are used for most of the localization, which makes Globalite a light and fast solution. The Locale is set on the user‘s session making Globalite a perfect solution for multilingual support. The developer can pass dynamic values to be used in the localization.
Gibberish is a nice plugin but it doesn‘t handle locales, you can‘t have your application in British English and American English. I also don‘t really like the syntax :p I based the UI localization of Globalite on Chris’ work on Gibberish.
Globalize is a great plugin but man, it‘s bloated… I would like to have something a bit lighter and easier to use. (less options, less setup time, less database usage). I decided to trim down Globalize to offer less options and fulfill the needs of most developers.
Also, Globalite doesn‘t have the concept of a base language. Mainly because I think that‘s a bad idea. If you use English as your base language and you need to fix a string in English(you did a typo), you will break all the other translations. That‘s why Globalite uses localization keys only.
script/plugin install http://globalite.googlecode.com/svn/trunk/
rename the vendor/plugins/trunk => vendor/plugins/globalite or from your vendor/plugins folder:
svn checkout http://globalite.googlecode.com/svn/trunk/ globalite
Create a lang folder at the root of your project. Add your localization files in the lang/ui folder if you want to localize your interface.
Declare the current locale or language >
Globalite.current_language :fr
Localize a key >
:localization_key.l
or
:localization_key.localize
Easy, isn‘t?
Advanced users can also do more:
You can also pass an optional localization string only used if the localization is missing
:missing_localization_key.l("text used if the key is not localized yet")
You can also pass values to the localization, and the translator can do whatever he wants with them:
:welcome_user.l_with_args({:user => @user.name}) would render "Welcome Matt!"
Note that variables can be used in any order the translator wants
Localize a time object by using a predefined format (defined in the date_helper_time_formats variable that you can find in globalite/lang/rails/[lang].yml)
Globalite.current_language = :fr
Time.now.l(:long)
Localize a date object by using a predefined format (defined in the date_helper_date_formats variable that you can find in globalite/lang/rails/[lang].yml)
Date.today.l
In your views, create a select box with a list of all countries(listed in the locale language):
country_options_for_select
In your views, create a select box with a list of all the months(listed in the locale language) with the current month selected:
select_month(Time.now)
In your views, create a set of html select-tags (one for year, month, day, hour, and minute):
select_datetime
In your views, create a set of html select-tags (one for year, month, and day):
select_date
Get a number returned in currency, for instance if the locale was set to ‘fr’ the returned value would be 123,00 € but if the locale was set to ‘en-US’ it would return $123.00
number_to_currency(123)
Get a distance of time in words localized.
distance_of_time_in_words(Time.mktime(2005, 6, 4, 15), Time.now)
Active record errors are automatically rendered in the locale language
Globalize was already taken ;) Most seriously, I was looking for a i18n/l10n solution for a project I was working on, after few hours testing Globalize, Josh joshknowles.com, Matt heidmotron.com/ and I railsontherun.com saw it wouldn‘t work for us. Since we only had the choice between very simple solutions and a complicated solution, I decided to make a "lite" version of Globalize ;)
Internationalization refers to the process of modifying an application’s design so that it can support locale differences like text orientation, currency, date and time format, sorting, and so forth. This can be done by externalizing text strings into files or a database, and by developing currency and date formatting utilities.
Localization means adapting an application to a specific language or locale; for example, by translating text into multiple languages. A locale is identified by the user’s language and country, and specifies how, for example, numbers, currencies, and dates are displayed on the screen. The code for the US English locale is en-US. Locales are specified by RFC 3066 and consist of two parts. The first is an ISO 639 language code and uses lowercase letters. The second is usually an ISO 3166 country code in uppercase letters. [from Ruby on Rails Commerce (Hellsten, Laine)]
Some code was very influenced from different projects such as:
Matt Aimonetti railsontherun.com mattaimonetti AT gmail DOT com
your name here if you submit a patch :)