Comments on: Converting a Rails application from Gettext to I18n

By: Hack to Learn : Converting a Rails application from Gettext to I18n

Hack to Learn : Converting a Rails application from Gettext to I18n — Fri, 29 May 2009 22:17:15 +0000

[...] by Administrator Fri, 29 May 2009 22:23:00 GMT ‘jaap’ wrote a rake task to convert your Rails application from using Gettext translation into the new I18n support, which [...]

By: grosser

grosser — Sat, 21 Feb 2009 12:55:14 +0000

simply stay with gettext, its simpler

fast+threadsave+simple Gettext http://github.com/grosser/fast_gettext

2.2+ rails plugin for gettext and i18n http://github.com/grosser/gettext_i18n_rails

Example 2.3 application fast_gettext+i18n http://github.com/grosser/gettext_i18n_rails_example

By: Andre Foeken

Andre Foeken — Mon, 08 Dec 2008 08:20:49 +0000

Uglyness == i18n in rails 2.2

By: Willem van Bergen

Willem van Bergen — Wed, 03 Dec 2008 15:39:27 +0000

I forgot to mention that we have implemented a fallback to English if a string is not available in the current locale. So there is no fallback to the identifier, because we always have an English string available.

By: Willem van Bergen

Willem van Bergen — Wed, 03 Dec 2008 15:38:05 +0000

I understand the concerns you have with the new i18n API. However, I can argue against the gettext approach as well:

We tend to adjust the English strings from time to time, to correct grammar mistakes or create more fluent sentences. This is usually NOT done by the developers. Using gettext, this means that all the translations for that string are no longer valid, because the key has changed. This was a common problem for us when we were using gettext. Using i18n and translation keys, this problem doesn’t occur, and somebody other than the developers can adjust it.

Another problem is strings that are exactly the same in English but can mean different things, like “bank”. In other languages, these different meanings can be the cause of different translations.

To overcome your problems, you can make the identifiers a bit nicer than your example: t(:cannot_parse_this_shit). This makes it much more clear for developers as well.

By: Gunnar Wolf

Gunnar Wolf — Mon, 01 Dec 2008 03:16:22 +0000

Oops… I have to agree with Fabio: So far, the Rails improvements have felt just right. However, this time… It feels I’m going to stick with gettext for all of my projects :-/
Writing an application with just the labels as symbols, which have to be referenced from an external table, looks like the oldest and most awkward way to solve a problem. One of gettext’s biggest selling points, which has mad it a Unix-wide standard, is the ability to just write English applications – and use the English as the message identifiers themselves. Switching everything back to :ecannotparse (instead of a ‘cannot parse this shit’) just means more work to authors. And translators will also have a harder time, as they might not be technically skilled people, and will now have to open the to-be-translated files as well as the English ones to understand really what needs to be translated.
And of course, gettext degrades quite nicely – a missing string gets sent as English. Now… even the English translation might be missing. It is much preferrable for an i18n application to give an English string every now and then than to fail towards an internal-use-onl string.

By: jaap

jaap — Thu, 18 Sep 2008 16:31:11 +0000

@Fabio The call can be more simple, you can just use t(:message_1) without the I18n before it, and if you don’t use the scopes, you even don’t have to include them. So only t(:message_1) can be enough!

By: jaap

jaap — Thu, 18 Sep 2008 16:26:22 +0000

@Evgeny: that’s the advantage of the I18n API, we can now use this API and switch to whatever we plugin(that makes use of I18n) we want! Maybe if we find it usefull we switch to such a plugin, but for now the SimpleBackend is enough, as this is only a test for us.

By: Fabio

Fabio — Thu, 18 Sep 2008 13:33:47 +0000

This tool is very interesting. I’m following with interest Rails I18n evolutions
but replacing the more concise

_(”to be translated”)

with

I18n.t :message_0, :scope => [:txt, :controller, :controller_name])

is not exactly what I would expect from a brand new API.
I’m still looking concrete advantages (performance, code clarity, etc…)
to left gettext and switch to new I18n API.

Anyway, thanks for your post.

Ciao.
– fabio

By: Evgeny

Evgeny — Thu, 18 Sep 2008 12:10:28 +0000

But why don’t you want to use Gibberish, or some other existing i18n plugin?