Support temporary language switch inside a request #2

Closed
rslinckx opened this Issue Aug 26, 2010 · 14 comments

Comments

Projects
None yet
10 participants

It would be nice to be able to stash the current language somewhere and use another one for a while during a request execution.

The main use-case I see is sending out emails with Flask-Email. The email should be translated according to the recipient's language and not the current user's language.

Something like:

from flaskext.babel import stash, unstash

# do stuff with current user's language
print _('foo')
# Now switch to th recipient language
stash(new_lang=recipient.language)
send email with i18n tags
unstash()
# Now the language is back to the current user's lang

Well the API is terrible, but you get the idea..

Owner

mitsuhiko commented Aug 26, 2010

You can do that actually. You will just have to push a new request context with a different language in:

with app.test_request_context(environ_overrides={'HTTP_ACCEPT': 'en_US'})
    ...

[assumes that the language getter looks at the accept header]

But I agree that there should be a saner API for that.

This won't allow me to set a given lang easily, because it will go through the localeselector which may do stuff I don't want when i need a particular language.

What i ended up doing is the following:

@contextmanager
def lang_override(lang):
    ctx = _request_ctx_stack.top
    if ctx is None:
        yield
        return
    g._force_lang = lang
    babel_refresh()
    yield
    del g._force_lang
    babel_refresh()

And in the localeselector code:

@i18n.localeselector
def get_user_locale():
    # Check for a forceful language override
    if hasattr(g, '_cvscan_force_lang'):
        return g._cvscan_force_lang

    # Rest of the code to sniff browser header, user from db, etc

It's not particularly elegant but works in the context of my project, i can then do the following:

with lang_override(recipient.language):
    mail.send(Message(
        subject=_('Test'),
        body=_('blablabl'),
        recipients=[recipient.email],
    ))

And inside the with-block the language returned by the babel extension will be forced to be recipient.language (or the platform default if it's None)

void commented Jan 3, 2011

The correct header in the example provided by mitsuhiko is HTTP_ACCEPT_LANG

@lalinsky lalinsky added a commit to lalinsky/flask-babel that referenced this issue Mar 9, 2012

@lalinsky lalinsky New function to temporarily switch the current locale (#2) 09ee170

Any feedback on the attached pull request ? Seems like what i originally wanted to do ?

Apparently the mail rendering use case is an often one. At MoinMoin we also need mails in different languages to send out notifications to users.
Would be nice to have a context manager inside flask-babel for a temporary/forced locale.

yup, +1 ;)

+1, when sending notification emails etc. this is a must-have and going through a new request context is insane(-ly ugly)

Member

kvesteri commented Mar 18, 2014

+1

razor-1 commented Dec 10, 2014

+1

@adarshk7 adarshk7 added a commit to adarshk7/flask-babel that referenced this issue Feb 1, 2015

@lalinsky @adarshk7 lalinsky + adarshk7 New function to temporarily switch the current locale (#2) aacf66a

A nice API for this would be awesome.

Btw last commit to this project was almost three years ago. What happened?...

Member

kvesteri commented Mar 2, 2016

Our company took over this project couple of months ago. We promise there will be a commitfest to this project soon. This is probably the first issue we are going to address.

@kvesteri: Nice to hear this! Are you also going to include everything from Flask-BabelEx (which is a fork of this project anyway)?

Member

kvesteri commented Mar 2, 2016

I have to see the differences between this and Flask-BabelEx and go through those case by case. So yes, at least many things will be included.

@kvesteri That's great news! 😀Sign me up for incorporation of Flask-BabelEx's features as well. I think the only reason I started using it was for its py3 compatibility though.

TkTech referenced this issue Apr 29, 2016

Merged

Tracking PR - WIP #88

TkTech closed this May 5, 2016

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