Fallback algorithm #8

Closed
tute opened this Issue Aug 4, 2011 · 4 comments

Comments

Projects
None yet
2 participants
@tute
Contributor

tute commented Aug 4, 2011

Hi,

While seeding the database (with english default language) table get's populated in english, but it has no translations. If we add translations, but ask for some attribute in the default language, the first translation will get listed instead of the "default" english one.

Shouldn't it show the original's table attribute? For now I'll copy english translations on seeds, but if you agree I'll make the change so you can merge it.

Thank you in advance,

Tute.

@dmitry

This comment has been minimized.

Show comment Hide comment
@dmitry

dmitry Aug 4, 2011

Owner

As I understood, you replaced virtual attributes, with your own attribute, for example:

User have name
UserTranslation have name aslo

you did

translations :name in Users, and trying to set both names in User and UserTranslation.

If this is true, then I don't agree that this algorithm is a good one. Better is use default_name virtual attribute, with:

def default_name; all_translations[:en].name; end

Something like that. I can update gem for improved version of all_translations, so it will be more or less optimized with includes and where (conditions).

Owner

dmitry commented Aug 4, 2011

As I understood, you replaced virtual attributes, with your own attribute, for example:

User have name
UserTranslation have name aslo

you did

translations :name in Users, and trying to set both names in User and UserTranslation.

If this is true, then I don't agree that this algorithm is a good one. Better is use default_name virtual attribute, with:

def default_name; all_translations[:en].name; end

Something like that. I can update gem for improved version of all_translations, so it will be more or less optimized with includes and where (conditions).

@tute

This comment has been minimized.

Show comment Hide comment
@tute

tute Aug 4, 2011

Contributor

Hi, @dmitry, thanks for your gem and swift response!

My idea was to add translations only for "new" languages. As we are adding translations to an existing app, it felt intuitive to have the actual User table as an english default, having translations for new languages on UserTranslation.

Then, if the application calls for user.role in it's default language it would use the default table's information, only caring for non-english translations. With this schema, creating a new user would by default load it's first "translation".

Please, let me know if this would bring more problems than solutions! :-)

Thank you again!

Eugenio.

Contributor

tute commented Aug 4, 2011

Hi, @dmitry, thanks for your gem and swift response!

My idea was to add translations only for "new" languages. As we are adding translations to an existing app, it felt intuitive to have the actual User table as an english default, having translations for new languages on UserTranslation.

Then, if the application calls for user.role in it's default language it would use the default table's information, only caring for non-english translations. With this schema, creating a new user would by default load it's first "translation".

Please, let me know if this would bring more problems than solutions! :-)

Thank you again!

Eugenio.

@dmitry

This comment has been minimized.

Show comment Hide comment
@dmitry

dmitry Aug 4, 2011

Owner

Hi again @tute, thanks for the good words.

I don't like code duplication, all similar data should be in one place (it's just my thought, some exceptions could be, but at the most of the time it's true). If I did something like that you described, I'd better do something like

TRANSLATABLE_ATTRIBUTES = [:name, :description]

translations TRANSLATABLE_ATTRIBUTES
has_one :default_translation, :conditions => {:locale => I18n.default_locale.to_s}

validates_presence_of :default_translation

and generate something like:

TRANSLATABLE_ATTRIBUTES.each do |attr|
  send :define_method, attr do
    translation.nil? ? has_translations_options[:nil] : default_translation.send(name)
  end
end

I guess in that case you'd better just to take some code from the has_translations.rb, move it to the lib path, and do some changes. For example in that case you should generate virtual attributes, eg name in the previous example.

Owner

dmitry commented Aug 4, 2011

Hi again @tute, thanks for the good words.

I don't like code duplication, all similar data should be in one place (it's just my thought, some exceptions could be, but at the most of the time it's true). If I did something like that you described, I'd better do something like

TRANSLATABLE_ATTRIBUTES = [:name, :description]

translations TRANSLATABLE_ATTRIBUTES
has_one :default_translation, :conditions => {:locale => I18n.default_locale.to_s}

validates_presence_of :default_translation

and generate something like:

TRANSLATABLE_ATTRIBUTES.each do |attr|
  send :define_method, attr do
    translation.nil? ? has_translations_options[:nil] : default_translation.send(name)
  end
end

I guess in that case you'd better just to take some code from the has_translations.rb, move it to the lib path, and do some changes. For example in that case you should generate virtual attributes, eg name in the previous example.

@tute

This comment has been minimized.

Show comment Hide comment
@tute

tute Aug 4, 2011

Contributor

Ok, thank you @dmitry. It felt like duplication having same strings on User and on UserTranslations, and felt natural to fallback to users table on no translations, but they are just feelings, not issues!

It's important to have the original table filled for querying it by attributes, which is in fact why we're using your library instead of puret, as puret didn't fill it and would make find_by_{attr}'s useless.

Your code seems a good solution for this, anyway we'll stick with your standards. Thanks again!

Contributor

tute commented Aug 4, 2011

Ok, thank you @dmitry. It felt like duplication having same strings on User and on UserTranslations, and felt natural to fallback to users table on no translations, but they are just feelings, not issues!

It's important to have the original table filled for querying it by attributes, which is in fact why we're using your library instead of puret, as puret didn't fill it and would make find_by_{attr}'s useless.

Your code seems a good solution for this, anyway we'll stick with your standards. Thanks again!

@tute tute closed this Aug 4, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment