Ruby on Rails | Screencasts | Download | Documentation | Weblog | Community | Source

Ticket #9726 (new enhancement)

Opened 9 months ago

Last modified 4 months ago

[PATCH] i18n plugin agnostic API for Rails 2.0

Reported by: saimonmoore Assigned to: core
Priority: normal Milestone:
Component: ActiveSupport Version: edge
Severity: major Keywords: localization i18n translation
Cc: mislav, matt, tarmo, norbert, cch1, brandon, ylugrin, chuyeow, face

Description

Hi,

Joshua Sierles and myself have started work on adding hooks into rails edge to provide a common api for plugin developers working on internationalizing or localizing rails.

What's in the patch is very rough and only meant to be considered as a peek at the direction were taking. Right now we're looking for feedback before we push on any further.

What's there:

  • Inclusion of a .t method into String/Time/Date/DateTime (via activesupport)
  • Very basic default implementation of .t for english strings.
  • If no args are supplied, it's a noop as the same string is returned
  • Argments:
    • Integer -> Singularize/Pluralize string
    • String -> Basic interpolation (multiple)
    • Symbol -> Namespaces (just swallowed in default impl.)
    • Array -> Combination of above
  • Very basic tests for .t method implementations (Mostly focussing on String right now)
  • Modification of the following areas:
  • active_record_helper.rb#error_messages_for
  • date_helper#distance_of_time_in_words
  • AR:Validations
  • All tests that currently pass (actionpack/activesupport/activerecord) still pass with this patch.

So we'd appreciate it if people interested in this issue take a peek (patched against r7661) and provide us with plenty of feedback (+ve/-ve).

Regards,

Saimon Moore

(Globalize for Rails plugin developer)

Attachments

i18n_agnostic_api.patch (36.0 kB) - added by saimonmoore on 09/28/07 15:38:37.

Change History

09/28/07 15:38:37 changed by saimonmoore

  • attachment i18n_agnostic_api.patch added.

09/28/07 19:31:40 changed by mislav

  • cc set to mislav.
  • severity changed from normal to major.
  • summary changed from Beginnings of a i18n plugin agnostic api for rails edge to [PATCH] i18n plugin agnostic API for Rails 2.0.

+100!!

09/28/07 19:46:07 changed by matt

  • cc changed from mislav to mislav, matt.
  • keywords changed from localization i18n to localization i18n translation.

What about keeping it even simpler and just add a .translate method into - String - Array - Symbol - Time - Date - DateTime.

(choose whatever alias you want but make the original method obvious such as String#translate)

The default .translate method would just return the object passed to it so rails Core wouldn't break if no translation plugin is installed.

Each plugin developer could then extend/overwrite the .translate method to deal with translation/localization, pluralization, interpolation... the way they want.

I agree that having some basic hooks into Rails would really help us i18n/l10n plugin developers but I would hope it stays as agnostic as possible.

Matt (GlobaLite plugin developer)

(follow-up: ↓ 4 ) 09/28/07 21:18:19 changed by jsierles

The problem with simplifying this any further is that rails already does interpolation and pluralization in its own way, which would be incompatible with just adding a translate method to strings. This is an opportunity to define a simple and flexible api for plugin authors to override as they please.

In any case, this implementation mostly has no effect on the original string and requires no plugins, it just adds a couple things we think are basically vital to i18n like namespaces.

(in reply to: ↑ 3 ) 09/28/07 21:40:28 changed by matt

Replying to jsierles:

The problem with simplifying this any further is that rails already does interpolation and pluralization in its own way, which would be incompatible with just adding a translate method to strings. This is an opportunity to define a simple and flexible api for plugin authors to override as they please. In any case, this implementation mostly has no effect on the original string and requires no plugins, it just adds a couple things we think are basically vital to i18n like namespaces.

Right, so what about creating a translating method/hook which by default uses Rails' interpolation and pluralization but doesn't add what the 'vital' features you are talking about?

Namespacing for instance is really useful if you have a big application but absolutely useless if you have a simple app. I think my main problem with this patch are the assumptions you guys made.

I think we should keep it as simple as possible so we will have a greater diversity in plugins. Also, you have different ways of addressing the same problem and some of your basic suggestions wouldn't let me deal with translation the way I want.

In my case I use symbols as translation keys. I believe that a key doesn't belong to any language and should never be changed. If you decide to use symbols to specify a namespace, then I can't use the hook anymore.

Don't get me wrong, I really appreciate your initiative but I want to make sure that if we add an i18n/l10n API it stays as low level and unbiased as possible.

09/28/07 22:11:35 changed by jsierles

Matt,

I'd be delighted if you could find a simple way to do this but still use the old Rails way of interpolating/pluralizing.

In your case of symbolic keys, you could change the implementation and it would work, since rails internals dont use them. The suggested implementation here only one method to be overriden.

I don't think it's simpler not using symbols for namespaces, it's just different, and can be overriden if it doesn't work for your case. The benefit of providing a suggested standard is that if a few plugins do use namespaces, they could do it the same way.

since right now we're close to 2.0, it would be great to see real changes to this patch from the various interested parties for comparison. Also specific pointers to other things that might trip up plugin authors.

(follow-up: ↓ 11 ) 09/28/07 22:44:28 changed by tarmo

  • cc changed from mislav, matt to mislav, matt, tarmo.

09/28/07 23:54:00 changed by norbert

  • cc changed from mislav, matt, tarmo to mislav, matt, tarmo, norbert.

Interesting topic, might work on this when needed.

09/29/07 01:51:16 changed by cch1

  • cc changed from mislav, matt, tarmo, norbert to mislav, matt, tarmo, norbert, cch1.

09/29/07 15:38:30 changed by cch1

Support for internationalization is critical for greater acceptance. Hook methods (that by default return the string unchanged) seem like a smart way of addressing the problem. I like the idea of using a complete and obvious name (.translate) instead of a more succinct name (.t). It should be trivial for the various internationalization plugins to add a short alias, if so desired.

+1

09/29/07 16:21:48 changed by norbert

Having just #t as a method name is quite clear in my opinion. The benefits of calling it so are quite large when you look at the points within Rails core where the method is used, because the translation calls are much less obtrusive this way.

For now, I can't give my +1 to the patch as it needs some cleaning up. Debug lines, reverting extract_options!, coding style quirks, whatnot. But soon it will become a very valuable addition.

(in reply to: ↑ 6 ) 09/30/07 00:10:45 changed by matt

Replying to tarmo:

I'd be glad to help coming up with simple translation method only returning the passed while not breaking the original Rails pluralization.

Should we continue this discussion in the mailing list and discuss what the api should actually do? It sounds like there's a disagreement about what the API should cover.

10/01/07 01:14:13 changed by brandon

  • cc changed from mislav, matt, tarmo, norbert, cch1 to mislav, matt, tarmo, norbert, cch1, brandon.

10/01/07 01:22:45 changed by danielmorrison

+1

This sounds like a great way to add translation hooks in without breaking anything. Great work.

10/01/07 13:52:38 changed by matt

2.0 is almost out, let's not rush but take our time to think things through and come up with a great solution in 2.x.

10/15/07 13:41:34 changed by ylugrin

  • cc changed from mislav, matt, tarmo, norbert, cch1, brandon to mislav, matt, tarmo, norbert, cch1, brandon, ylugrin.

11/02/07 11:08:07 changed by chuyeow

  • cc changed from mislav, matt, tarmo, norbert, cch1, brandon, ylugrin to mislav, matt, tarmo, norbert, cch1, brandon, ylugrin, chuyeow.

03/01/08 17:05:48 changed by face

  • cc changed from mislav, matt, tarmo, norbert, cch1, brandon, ylugrin, chuyeow to mislav, matt, tarmo, norbert, cch1, brandon, ylugrin, chuyeow, face.

thanks.