User’s language preference added in osm rails-port

In last couple of days, I added the user language preference in the osm rails-port. It is basically implemented by a drop-down menu in the settings page of the user, from where he can easily select & save the desired locale. When the selection is saved, it’s saved in the database where a locale column has been added to user table by migration (012_add_user_locale.rb).  The drop-down menu is implemented in the view (account.rhtml) by a helper method called “select” as given,

select ("user", "locale", { "English(US)" => "en-US", "Bengali(IN)" => "bn-IN", "Hindi(IN)" => "hn-IN", "Spanish" => "es-ES" })

Correspondingly, the user’s model & controller has been updated. Here, i have used a hash within the select method for specifying languages, which can be easily replaced by a hash variable defined in config/environment.rb for convinience. Another approach maybe to find all the locale codes from globalize_translation table migrated by the globalize plugin using “collection_select” helper method. But, in the previous one we actually will have the flexibility to add only those languages we prefer (it may be based on availabity of translations or rather request for the language branch by an l10n team).

This language preference option is somewhat independant of the plugin problems. But the locale-routing part is yet to be decided, regarding how to do that, because click-to-globalize also implements some sort of routing associated with locale_controller.rb. The screenshot of the user settings page:

User's language preference added!

User's language preference added.

More importantly, a sort of bug that came with the globalize plugin as i have posted earlier (error log) is now fixed. As it can seen in the log, while I tried to create a new user, <% error_messages_for 'user' %> is called in the app/view/user/new.rhtml. Now, globalize plugin overrides the “error_messages_for” helper method for it’s own requirements. The helper method tried to execute nil.errors? (from the error log) which is quite obvious, since the object user is created after rendering the view and resulted with errors. I first tried to take care of this by a small change in active_record_helper.rb within the globalize plugin:

return "" if object_name.nil?

But it didn’t do much good. Later i found a better fix from rails-forum which actually worked flawlessly. Here’s the new active_record_helper.rb. So one of the two big problems i previously blogged with these plugins is solved. Since, globalize started working i could also test the views related to ‘user’. There were some sillymistakes for example, forgot to use to_s in @user.messages.size in the globalized view.

"You have %s new messages and".t(nil,@user.new_messages.size.to_s) + " %s old messages".t(nil,(@user.messages.size - @user.new_messages.size).to_s)

I have commited all these updates in the i18n branch. Also, apart from the inherent loopholes in click-to-globalize, we are also focussing on other areas that needs to addressed including translation notifications etc. Please put up your comments and suggestions 🙂


5 responses to “User’s language preference added in osm rails-port

  1. Great to see work going into localisation for OSM!

    I think it’d be good to extend this to the diary section of the site as well, so that it lets you specify a language for each post, and also lets you filter by language (probably defaulting to your own language).

  2. Shouldn’t users be setting their language preferences in their browser rather than on random websites?

  3. Arindam Ghosh


    Well…that’s an interesting thought. The default language will obviously be the one selected in user’s settings. Now, it seems that having this language option in a diary entry provides a sort of language-tagging for them. And also enabling filtering of posts. This can be implemented sometime down the line after core i18n things are done.

  4. Arindam Ghosh


    That really doesn’t apply when the user is working from a different system say in his university lab etc. So, adding global locale preference for user appears more consistent 🙂 Browser preferences can be kept as an extra, but once logged in s/he has self-preferred environment.

  5. Pingback: Language filtering of diary entries!! « Arindam’s Weblog