Translator workplace in Globalize

Hello!

I’m going to use Globalize in my app. While playing with Globalize I
tried translation view example from globalize-rails.org. I like the way
those things work – text appears in translator’s view (and also in
globalize_translations table) after it is first time requested by app.
Anyway there are some rough edges. Here are the ones that bother me
more:

  1. When a text is requested by application record dedicated to it’s
    translation is put for current language only. My application should use
    only 5 languages and it seem reasonable for me to create empty
    translations for all languages simultaneously.
  2. Model translations seem to be created only when such translation is
    saved. I think it will be useful to have empty model translations
    created automatically as view translations or to be created
    simultaneously for all languages after a record in translatable table is
    created.
    My questions are:
    What is supposed/prefered/recomended way to organize translators
    workplace with Globalize? Is it supposed to manage already created
    records in globalize_translations or it should create records by itself
    based on translatable tables?
    Can described behaviors be achieved using current version of
    Globalize? If not, probably someone could give me some hints of how to
    fix Globalize to work this way?

Tim

Hi Tim,

Your first proposal makes a lot of sense, and should be easier if we
add a SUPPORTED_LANGUAGES = [ ‘en’, ‘es’ ] type constant. We’re
thinking of adding something like that anyway for other features.

I didn’t understand your second question. Why do you need to have
actual records in globalize_translation for a model if there’s no
translation for that model in the given language? What’s the
connection to view translations?

Best,
Josh

Joshua Harvey wrote:

Hi Tim,

Your first proposal makes a lot of sense, and should be easier if we
add a SUPPORTED_LANGUAGES = [ ‘en’, ‘es’ ] type constant. We’re
thinking of adding something like that anyway for other features.
Good news :slight_smile:

I didn’t understand your second question. Why do you need to have
actual records in globalize_translation for a model if there’s no
translation for that model in the given language? What’s the
connection to view translations?
My idea is to create web interface which would allow it’s user to
inspect and translate both already translated model data and model data
which is supposed to be translated. Easy way is to reproduce example
translator logic to work with all texts which appear in
globalize_translations table. That’s the reason I’d like to have empty
records in translations table for model data that need to be translated
but isn’t translated yet.
I see two way of reaching this effect:

  1. to load empty translation records for all supported languages when
    new model record is created
  2. to load empty records to translations table once corresponding
    model records have been used (it’s the same way it is done with view
    translations).

I’m not sure it’s the best way to organize tranlator’s interface but
it’s the easiest I think of.
The other idea is to take records directly from model (instead of
using globalize_translations as the only data source) and to save
translations. Probably it’s the better way. This way it would be good
idea to be able to get the list of all models and all translatable
attributes. Is there a way to get it all?

Tim

Hi Tim,

Yes, I’d go with your second idea, pulling the data from the models
themselves. To get the translatable fields use
YourModel.globalize_facets, which will give you an Array of symbols
representing the field names that are translatable. The method should
be renamed, but that’s what it is now.

For finding all the models in the app, check out this blog entry:
http://sporkmonger.com/articles/2006/10/22/a-question

I’ll bet there are better ways of doing it, and probably some of those
ways are in the Rails code itself, but I don’t know where to point you
off-hand. Maybe somebody else here does.

– Josh

Hello, Josh!

Thanks for the answers and for Globalize :slight_smile:

Tim

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs