Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Alternative I18n convention for namespaced models is not supported in Rails 3.1 #1402

Closed
paneq opened this Issue May 30, 2011 · 16 comments

Comments

Projects
None yet
6 participants
Contributor

paneq commented May 30, 2011

During Rails 3.0.6 release it was decided that 2 conventions for storing translations for namespaced models should be supported. The alternative convention was added. It is not supported anymore in Rails 3.1.0.rc1 currently.

http://groups.google.com/group/rubyonrails-core/browse_thread/thread/eca57305b1a3ea0d

Also. The convention was not fully established for Rails 3.0.* . It could be used for
Namespaced::Model.model_name.human
Namespaced::Model.human_attribute_name
but not for
Namespaced::Model.new.errors.add(...)

I think we should keep and expand the support for alternative translation convention that uses dots instead of slashes.

Member

sikachu commented Jun 1, 2011

@tenderlove do you mind looking into this one?

Member

sikachu commented Jun 8, 2011

Part of it has been merged in to master and 3-1-stable. Do you mind making a pull request for that?

@tenderlove tenderlove was assigned Jun 8, 2011

Member

sikachu commented Jun 8, 2011

Forgot to refer to this pull request: #1556

Contributor

paneq commented Jun 10, 2011

So what about Namespaced::Model.new.errors.add ? I can provide patch for that for rails 3.0.* and rails 3.1.* during the weekend. Would you merge it ?

thoefer commented Jun 10, 2011

@paneq: Of course, provide a patch. I´m sure sikachu will merge if you solve the problem.

Member

sikachu commented Jun 10, 2011

@paneq yep, send 'em in. ;)

Owner

spastorino commented Jun 11, 2011

If I'm not wrong this was fixed in #1556, if it's still an issue please add a comment and I will reopen it.

@spastorino spastorino closed this Jun 11, 2011

@sikachu sikachu reopened this Jun 11, 2011

thoefer commented Jun 11, 2011

@spastorino
Just for clarification: Currently you cannot use both conventions for "Namespaced::Model.new.errors.add(...)" (as per paneq´s issue description, I´ve not tested this) which may confuse users. I think paneq works on it over the weekend. The original problem with either support for one or the other convention from ealier rails versions (3.0.x) is solved by supporting both. This is what pull request 1556 did.

thoefer commented Jun 11, 2011

Sorry @paneq I couldn´t resist ;) Any comments on this implementation?

thoefer commented Jun 11, 2011

If it´s good enough I will provide a backport for 3.1-stable. I established an external .yal-file for testing namespaced translations, too. I hope this is ok.

thoefer commented Jun 11, 2011

@paneq @sikachu
Just to let you know: Looks like the namespaced model feature will be removed completely...

Contributor

paneq commented Jun 11, 2011

@thoefer - What are you talking about? Who told you that? I highly doubt that I won't be possible to use namespaced models in Rails. That wouldn't make any sense.

Contributor

paneq commented Jun 11, 2011

Be precise next time please :-) Jose comment in the pull request is about translations of namespaced models errors. Not about namespaced models per se

thoefer commented Jun 11, 2011

The way I understand it is that he want to remove the support for "[...]nested namespaced setting[...]". I think he refers to the entire possibility of nesting and using "dot-syntax".

Contributor

josevalim commented Jun 11, 2011

Yes, nested I18n lookup was removed.

@josevalim josevalim closed this Jun 11, 2011

@bryanmtl bryanmtl pushed a commit to bryanmtl/g-refinerycms that referenced this issue Jan 28, 2014

Jamie Winsor Fix for [DEPRECATION WARNING] Nested I18n namespace lookup under "act…
…iverecord.attributes.refinery" is no longer supported

Fix for [DEPRECATION WARNING] Nested I18n namespace lookup under "activerecord.models.refinery" is no longer supported

See rails ticket rails/rails#1402 for details
f55c48c
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment