Sneaky Abstractions

Subscribe to my Feed, follow me on , recommend me on Working With Rails or see my code on GitHub

Use English Everywhere

Posted on August 10, 2009 09:53, 5 comments. Tagged with english, languages, programming, elbonian.

One common question for many new Rails developers is “How do i make Rails’ pluralisation rules work with the X language?”. There’s a simple answer to that question:

Use English Everywhere.

And by everywhere, I mean everywhere. All non-user-facing (and preferably also user-facing) parts of your application should be in English. This includes, but is not limited to:

  • Class names, module names, variable names, etc.
  • Table, column and model names
  • All comments
  • All other documentation, rake tasks, scripts, etc.

Ideally, your entire process should use English: Tickets, TODOs, stories, what have you should also be in English. If you do everything in Elbonian there’s no way for a developer who doesn’t speak Elbonian to participate in developing your application.

But our entire team speaks Elbonian, can’t we use Elbonian in our app?

Nope. Even if you all speak Elbonian, there’s no way you can know that other developers in the future working on your app will speak Elbonian, but there’s a good chance they’ll understand English. If you use Elbonian in your app, you limit your pool of potential developers to the 6 Rails/whatever developers who actually speak Elbonian instead of the thousands who speak English at some level.

But our English isn’t that good

Doesn’t matter. Poor English is much better than no English.

But the user-facing parts of our app can still be in Elbonian, right?

Possibly, but you really, really should use English as the main language even in the user interface. You can then use i18n tools to provide the app in other languages.

But our entire user base speaks Elbonian!

You can’t possibly know that. What if your user base is actually twice as large as you think, but you didn’t realise this because the other half doesn’t speak Elbonian and thus couldn’t use your app? By not providing your app in English you’re restricting your user base to include only those who speak Elbonian. Why would you do that?

As an added bonus, if your app uses i18n from the start, adding even more languages becomes really easy.

Our app targets the English-speaking market, should we use i18n anyway?

Absolutely. You never know when your boss will go on holiday to Europe and suddenly realise people speak other languages than English and then decide you should “go international” to “tap into those markets”. But when he does, you’re ready for it. Plus, using i18n has other benefits such as separating content from structure.

But we fear that if we use English everywhere it will be easier for our employer or client to outsource the app somewhere else

Then you’re not doing a good enough job. Get better at it.

Comments

Atom feed

By onno.solin.eu at

You forgot to mention that all Rails app developers should also use Globalize 2. Try using Redmine in various languages at once, for instance, and you’ll be in for a lot of pain. Redmine supports your language, but the installation process fills a number of models with defaults in that language. If you subsequently switch to another language, you’ll still get to see all default strings in the original installation language…

Onno

By Promotional gifts at

Yes Its a good idea to approach the feeling of code sense.

By مركز الاتصال at

You can’t possibly know that. What if your user base is actually twice as large as you think, but you didn’t realise this because the other half doesn’t speak Elbonian and thus couldn’t use your app? By not providing your app in English you’re restricting your user base to include only those who speak Elbonian. Why would you do that?

By CRM at

Fully agree with you on this

By CRM at

Fully agree with you on this

Leave a comment

OpenID

Or..

Old school

Search out the door of Namtara. Bring a baked loaf into his presence.