How to overwrite translated fields.

[Gobi]

Dear all

Is it possible overwrite default accessors of translated fields in
data model.

May be something like this:

class A < ActiveRecord::Base
translates :body

def body
b = read_attribute(:body)
...
b
end
end

It seems that above gives me nil result. How should I do it, Someone
help me please.

Thank you.
Gobi.

[Gobi]

Dear all

Is it possible to overwrite translated fields. However I tried to do
it like following it wasn't successful.

class A < < ActiveRecord::Base
translates :title, :body

def body
b = read_attribute(:body)

.... some processing
b
end
end

But it was not successful. The body is always nil. How should I do it?
Someone help me please?

Thank you.

Gobi.

[tim]

Hi there,

maybe I'm a little late to the party and this has already been
discussed sufficiently. But looking at the way locale files for
human_attribute_name are organized led me to the following question:

User.human_attribute_name(:email) looks up
"active_record.attributes.user.email". While it's perfectly fine with
me to store ActiveRecord specific strings (like
active_record.errors.messages) under the active_record scope, I find
it contra intuitive to have application specific keys in the
active_record scope. The same goes for things like
active_record.errors.models.user.blank etc.

I would much rather advocate introducing a convention to have
application specific scopes. config/locale/en.yml could look something
like this:

models:
user:
name: "User"
attributes:
email: "Email"
errors:
blank: ....

Or maybe even without the "models" part. This would make sense from my
point of view, since I often find myself needing model specific scopes
anyway.

Thoughts?

[tim]

What is wrong here? Why do all new posts end up in the same thread? I
didn't mean to change the subject of the discussion.

[stonefield]

I have no definite answer to this. However, I think it is important to
take into consideration that you may have a model that derives from
ActiveResource.
Then I think use of activerecord scope would be somewhat awkward. Even
if ActiveResource would support localization, and you were required to
use activeresource scope. The abstraction from implementation would be
good here. Lets say you refactor your app to use ActiveResource
instead of ActiveRecord, there would be no need to change the
translation files.
So: I agree with removing the activerecord scope, and it could be used
cross base class. However, I do not agree that even model should be
removed, as it keeps the code scope clean.

[tim]

I just think it would be great if there was some standard way of
organizing the translation files. Just like the directory structure or
REST patterns: It's a thoughtful set of conventions that makes Rails
really shine. Once a certain style is agreed upon it could also be
used in the scaffolding/generated files etc.

Maybe a first step would be to collect a couple of alternative ways of
structuring translation files.

My first idea would be to mimic the directory layout:

controllers:
users:
flash:
...
models:
user:
name: ...
attributes:
...
errors:
...
views:
users:
titles:
...
texts:
...

What are others using in their apps?

[Sven Fuchs]

Hey guys,

thanks for nudging me on this one.

Structuring and naming translation keys, whether to reuse keys or
not ... has always caused tons of discussions and you can imagine that
everybody has their favorite bikeshed color depending on their type
and scale of applications, requirements, work environments ...

In the end, we're a bit late with this discussion because the ship has
sailed with the release of 2.2.2

I agree that :activerecord as a scope might be a tad too technical for
some peoples taste. But, if you think about it, the :activerecord
scope isn't that bad either. It's a tighter scope than :model would be
(as already mentioned by others there can be other model types that
might require different translations because they're a different
context) - and that means it's the more defensive way of scoping. And
picking a more defensive option is not a bad thing for a framework to
do imo.

That said ... I haven't thought this through, but we already discussed
the idea of having "symlinks" or "aliases" in the backend, somewhere,
too:

What happens when the result of a lookup is a symbol? IIRC that case
is not defined, yet, and the obvious thing might be to treat it as a
key, i.e. as a pointer to somewhere else. This would allow you to
structure your translations in any way you want, even those that are
used by the framework.

models:
user:
email: ymmayhle

activerecord:
attributes:
user:
name: :"models.user.email"

I'm pretty sure this wouldn't go into the SimpleBackend at once, but I
can't see a reason why it wouldn't integrate nicely as a tiny plugin
either. So you could give it a shot and we could see how it works out.

[tim]

sorry for the delayed answer. Maybe you are right and this really is a
bikeshed color - though I would really love to see some rails
conventions evolve. Using symlinks is a nice idea. But in the end I'm
not sure whether the added complexity is worth it. I guess I will have
to think about this some more.

[Christophe Gimenez]

Hi, those who are not affraid by unfinished tools can have a look to
acts_as_translated, a small in-model data translation plugin (attribute
access, validation, views)
It's available on rubyforge http://rubyforge.org/projects/translated/

I would be glad if somebody is interested to help me to finish/improve
it. It's my first plugin so don't expect any good code here ;-)

Chris