Rails agnostic?

[chipairon]

Could we do this Rails agnostic?

i18nline is a Rails engine which enables to do:

1. Integrate routes with hosts routes, mounting them at /i18nline
2. Have access to rake and generators. This is used to create our translation table in host application (rake db:migrate) and to copy over the initializer to hotsapp/config/initializers/i18nline.rb
3. Rails translation helper is used to detect missing translations in host views with this code
4. Asset pipeline integration in host application so the host has available i18nline_to_host.js and i18nline_to_host.css assets.
5. Script inclusion in host: a hook on ActionView initialization enables us to pass our view helper methods. At this point in time, we only use this so the host appliction can include our assets calling our helper

Points 2, 4 and 5 could be taken out of Rails easily, although I guess the end user will need to do some steps manually or adopt some convention about where to copy our migration, assets and initializer files.

Point 1 is problematic. Any ideas?

Point 3 needs more thought. The point of using Rails translation helper is that any existing application using it, can install this gem and benefit instantly. No need to change the views. I guess we could conditionally monkey patch the t view helper to provide the same functionality even if the host is not using Rails (i.e. render missing translations inside a span like this <span class=“translation_missing” title=“translation missing: en.blog.post.title”>Title</span>.

What do you guys think?

[arnauti]

I think we must do this for Rails first, even if points 1 and 3 are not stoppers. Let's discuss this while we work on it :D

[rubencaro]

I also think we should make it work with Rails first, but keeping in mind the idea of making it work out of Rails too.

Rails style of coding has the ability to introduce into the code so many conventions and hidden dependencies that I'm afraid that if we do this for Rails without keeping the code away from Rails itself, then it would be way too hard to adapt afterwards.

I see two strategies to adopt here:

• Develop it entirely within Rails, but enabling its use as an independent app (the translation system app).
• Develop it by abstracting Rails with the driver paradigm, making all translation logic completely clean and usable from ruby, and then integrating it into Rails (or any other specific environment) by implementing a specific driver.

I see pros and cons for both. Too many to be pointed here now.

When I look at the code it becomes clear that almost everything is already Rails dependant. And by that I mean it depends on Rails, and not just uses Rails or works with Rails. Not only the whole idea of Engine, but the use of ActionView, ActiveSupport, Railtie, ActionController, ActiveRecord itself, the asset pipeline, the migrations, the tests, even suggestions for authentication (devise), roles (cancan) or pagination (kalimari) are Rails-only software. I see Rails dependance everywhere.

Maybe the whole idea of translation system needs to be relieved of some responsabilities. I mean, for example, that maybe there's no need to integrate to any authentication or roles system, so it may be responsability of the main app. The same could be argued for the routes system, controllers, views, etc.

Maybe i18nline should initially be simply a plain ruby library with some helpers that you can use wherever you need. Maybe to manage translation's values (plain db access here), and to add translation support to some template (only HTML/JS/CSS here). The app could decide where and how to use these helpers. Then evolve from that clean position. Maybe adding a thin driver layer for Rails, that consist on specific helpers to add some routes, a simple to-be-implemented controller, simple to-be-customized views, etc...

Too many things. Let's talk it better that write it down.

Cheers.

[rubencaro]

An example of the structure I imagine for this gem:

• https://github.com/collectiveidea/interactor
• https://github.com/collectiveidea/interactor-rails

The main gem simply does its job. Plain old usable testable rock solid ruby. The rails gem adds every Rails sugar you may want, nothing to do really with the gem's job, but with Rails conventions.

[chipairon]

It will be easy to implement the translations manager section as a Sinatra app instead of a Rails app.

The tricky part would be the host integration for the translation method 'ti' (this is the method used in the views that underlines translations). For Rails this is done from the railtie file: https://github.com/elpulgardelpanda/i18nline-rails/blob/master/lib/i18nline/railtie.rb#L1 That script is making available the ti method to the Rails views.

@rubencaro Let me know if you have an alternative way to make the helper method available on the views for non-rails projects. Then I can change the manager app from Rails to Sinatra :seedling: :seedling: :seedling: