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:
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.
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?
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?
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
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:
to load empty translation records for all supported languages when
new model record is created
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?
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.
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.
