Globalize WrongLanguageError on attribute _read_?

Rails Rails I18n
1

Dear List,

Can somebody enlighten me as to why a WrongLanguageError is thrown when
I access a stale copy of a model? I fully understand why such an error
is required upon writing to the object, but on read access? It seems to
make code more complicated than it needs be. Probably there is some
blindingly obvious reason for this that helps me see it.

– code example –
Globalize::Locale.set_base_language ‘en-US’

p = Page.find(1) # returns an english page
Globalize::Locale.set ‘fr-CH’ # p is now the ‘wrong’ language
puts p.title # This throws WrongLanguageError. Why? The value is
perfectly ok!
– code example –

Thank you for any answer you might have.
kaspar

neotrivium.com - the swiss ruby shop

2

Kaspar S. wrote:

Dear List,

Can somebody enlighten me as to why a WrongLanguageError is thrown when
I access a stale copy of a model? I fully understand why such an error
is required upon writing to the object, but on read access? It seems to
make code more complicated than it needs be. Probably there is some
blindingly obvious reason for this that helps me see it.

– code example –
Globalize::Locale.set_base_language ‘en-US’

p = Page.find(1) #�returns an english page
Globalize::Locale.set ‘fr-CH’ # p is now the ‘wrong’ language
puts p.title # This throws WrongLanguageError. Why? The value is
perfectly ok!
– code example –

because you have to reload your object before. the correct language is
loaded with the ‘find’, and with the access reader method.

…
Globalize::Locale.set ‘fr-CH’
p = Page.find(1)
puts p.title

will be ok.

Thank you for any answer you might have.
kaspar

neotrivium.com - the swiss ruby shop

3

because you have to reload your object before. the correct language is
loaded with the ‘find’, and with the access reader method.

Thank you for answering. I guess the question was more a ‘why’ than a
‘how’ question. I really don’t see why we would put this limitation
forward and not have a ‘french instance’ always return ‘french data’ and
an ‘english instance’ always return ‘english data’. More localized
language context, instead of it being always a global variable.

But since I have asked this question, I have used globalize_extension
and am quite happy with the resulting code. ie:

@page.switch_language(base_language.code) { @page.title }

Which is more or less clean. Globalize Extension seems to support these
local context switches I was looking for, not requiring me to

change locale

read the value (that I have already in memory, but can’t access

because of bad GLOBAL locale

change locale back

I profoundly dislike this kind of procedural style. Besides, it just
screams ‘non thread safe’ and ‘race condition’ - implemented as a global
variable that is.

So there I went and basically answered my own question - that is
something of a bad habit. :wink:

best greetings,
kaspar