R18n::Translated and Sinatra

[rickthomasjr]

I have an api running on Sinatra that has active record models using R18n::Translated. I'm having some major consistency issues with this feature - sometimes the correct translation returns, sometimes it's english. Is there some way I can explicitly set the desired local when I instantiate one of these models?

Please help! I love this gem, and I would hate to re-architect my multi-lingual support.

[rickthomasjr]

As a follow-up, I am doing this, and it's not helping:

before do
    @locale = (params[:locale] || 'en').downcase
    I18n.locale = @locale.to_sym
end

[rickthomasjr]

I found this in the comments in translated.rb:

you must call i18n helper in Sinatra before use models.

How do I call this helper, and when?

[ai]

It is old documentation. Now R18n use before filter to set I18n object. R18n::Translated get I18n-object from R18n.get try to test.

[ai]

Why you call I18n.locale? It is Rails I18n API, not R18n. R18n use R18n.set R18n::I18n.new(locales), because it work with list of locales, not with just one.

[rickthomasjr]

If I want to pick which locale to use for a specific request, what do I do
to force it to show just that locale?
On Jun 23, 2011 8:01 PM, "ai" <
reply@reply.github.com>
wrote:

Why you call I18n.locale? It is Rails I18n API, not R18n. R18n use
R18n.set R18n::I18n.new(locales), because it work with list of locales,
not with just one.

Reply to this email directly or view it on GitHub:
#30 (comment)

[ai]

I think, I didn’t understand you :). If you want to set user locale manually use:

R18n.set R18n::I18n.new('en', options.translations)

If ou want to print to console user locale:

p R18n.get.locales

[rickthomasjr]

My problem is that my model will be translated correctly based on the locale
param in the url, and then it will randomly switch back to english. I want
to prevent that from happening.
On Jun 23, 2011 8:53 PM, "ai" <
reply@reply.github.com>
wrote:

I think, I didnt understand you :). If you want to set user locale
manually use:

R18n.set R18n::I18n.new('en', options.translations)

If ou want to print to console user locale:

p R18n.get.locales

Reply to this email directly or view it on GitHub:
#30 (comment)

[akzhan]

I had another Sinatra-R18n issue - sometimes translations are absent (as discussed in #20).

[rickthomasjr]

@akzhan That's a shame - looks like I'll need to abandon this gem too

[fbernier]

I've got this issue too. If I go to the /en page, then go to the /fr, the translations are still in english. Once I reload the page, they're in french. I worked around it by settings the language manually using R18n.set. Not that much of an issue since it's a small 2 languages app but it could be a huge pain for a larger app.

[ai]

If you can fix translated locale by reload page, I think you have problem with caching, not with R18n.

[fbernier]

Possibly. I'm using a simple sinatra app and I have not enabled any caching unless It's done by default. It also happens in development mode. I would have looked into it but was too much in a hurry for this app. Maybe later!

[ai]

Maybe you can show me your app source, if it is small and open source?

[akzhan]

@ai You can use https://github.com/Undev/runit-man/tree/1.10.3 as typical open source Sinatra application that based on R18n.

It can be runned without gem using ./local-run.rb

P.S.: 1.10.3 is last R18n-based version so use this tag.

[AlexWayfer]

P.S.: 1.10.3 is last R18n-based version so use this tag.

I can't run it. :(

Traceback (most recent call last):
	20: from ./local-run.rb:6:in `<main>'
	19: from /home/alex/.rbenv/versions/2.5.1/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
	18: from /home/alex/.rbenv/versions/2.5.1/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
	17: from /home/alex/Projects/ruby/runit-man/lib/runit-man/runner.rb:2:in `<top (required)>'
	16: from /home/alex/.rbenv/versions/2.5.1/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
	15: from /home/alex/.rbenv/versions/2.5.1/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
	14: from /home/alex/Projects/ruby/runit-man/lib/runit-man/app.rb:11:in `<top (required)>'
	13: from /home/alex/Projects/ruby/runit-man/lib/runit-man/app.rb:79:in `<class:RunitMan>'
	12: from /home/alex/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/sinatra-2.0.3/lib/sinatra/base.rb:1386:in `get'
	11: from /home/alex/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/sinatra-2.0.3/lib/sinatra/base.rb:1604:in `route'
	10: from /home/alex/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/sinatra-2.0.3/lib/sinatra/base.rb:1629:in `compile!'
	 9: from /home/alex/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/sinatra-2.0.3/lib/sinatra/base.rb:1641:in `compile'
	 8: from /home/alex/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/mustermann-1.0.2/lib/mustermann.rb:67:in `new'
	 7: from /home/alex/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/mustermann-1.0.2/lib/mustermann/pattern.rb:59:in `new'
	 6: from /home/alex/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/mustermann-1.0.2/lib/mustermann/equality_map.rb:39:in `fetch'
	 5: from /home/alex/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/mustermann-1.0.2/lib/mustermann/pattern.rb:59:in `block in new'
	 4: from /home/alex/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/mustermann-1.0.2/lib/mustermann/pattern.rb:59:in `new'
	 3: from /home/alex/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/mustermann-1.0.2/lib/mustermann/regular.rb:26:in `initialize'
	 2: from /home/alex/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/mustermann-1.0.2/lib/mustermann/regexp_based.rb:19:in `initialize'
	 1: from /home/alex/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/mustermann-1.0.2/lib/mustermann/regular.rb:32:in `compile'
/home/alex/.rbenv/versions/2.5.1/lib/ruby/gems/2.5.0/gems/mustermann-1.0.2/lib/mustermann/regular.rb:41:in `check_anchors': regular expression should not contain ^: "^\\/([^\\/]+)\\/log(?:\\/(\\d+))?\\/?$" (Mustermann::CompileError)

[AlexWayfer]

Almost 9 years, wow! Sorry, I'm going to close this issue: as I wrote earlier, I couldn't reproduce. If you still experience something similar, and especially if you can provide example — I'd be glad to re-open and resolve it.