RejectedSoftware Forums

On Tue, 02 Sep 2014 10:20:20 GMT, Sönke Ludwig wrote:

On Mon, 01 Sep 2014 22:35:52 +0200, Lemonfiend wrote:

As far as I can tell, localization via .po files is chosen based on HTTP
headers.
Is it also possible to manually choose the language?
I would like to let the user choose their language, instead of forcing
ie. German on everyone in Germany, even through they're a foreigner, or
have different preferences.

Thanks :)

Currently there is no hook to override that, but I'll add that for the next version. But the languages can also be configured in the user's browser and are not dependent on the location. They are usually chosen at installation time based on the system locale settings.

Done: da90308

On Tue 02 Sep 13:46, Sönke Ludwig wrote:

On Tue, 02 Sep 2014 10:20:20 GMT, Sönke Ludwig wrote:

On Mon, 01 Sep 2014 22:35:52 +0200, Lemonfiend wrote:

As far as I can tell, localization via .po files is chosen based on HTTP
headers.
Is it also possible to manually choose the language?
I would like to let the user choose their language, instead of forcing
ie. German on everyone in Germany, even through they're a foreigner, or
have different preferences.

Thanks :)

Currently there is no hook to override that, but I'll add that for the next version. But the languages can also be configured in the user's browser and are not dependent on the location. They are usually chosen at installation time based on the system locale settings.

Done: da90308

I finally got a chance to look into this a bit further.

Am I correct in that you have to choose between EITHER the
Accept-Language header, OR determineLanguage, but not both?

As in, when returning null from determineLanguage it defaults to the
TranslationContext's languages default (the first?), and disregards the
header completely? This means you HAVE to have a default language which
is the same for everyone, which is bad.

I'd like it to first check determineLanguage. If it return non-null, use
that. If it's null, use the regular headers method.
This would make the following common scenario possible.
User visits page: language == header
User chooses language/logs in: language == determineLanguage (via a
sessionvar).

Thanks!

Am 24.09.2014 04:31, schrieb Lemonfiend:

On Wed 24 Sep 03:17, Lemonfiend wrote:

On Tue 02 Sep 13:46, Sönke Ludwig wrote:

On Tue, 02 Sep 2014 10:20:20 GMT, Sönke Ludwig wrote:

On Mon, 01 Sep 2014 22:35:52 +0200, Lemonfiend wrote:

As far as I can tell, localization via .po files is chosen based on
HTTP
headers.
Is it also possible to manually choose the language?
I would like to let the user choose their language, instead of forcing
ie. German on everyone in Germany, even through they're a
foreigner, or
have different preferences.

Thanks :)

Currently there is no hook to override that, but I'll add that for
the next version. But the languages can also be configured in the
user's browser and are not dependent on the location. They are
usually chosen at installation time based on the system locale
settings.

Done:
da90308

I finally got a chance to look into this a bit further.

Am I correct in that you have to choose between EITHER the
Accept-Language header, OR determineLanguage, but not both?

As in, when returning null from determineLanguage it defaults to the
TranslationContext's languages default (the first?), and disregards the
header completely? This means you HAVE to have a default language which
is the same for everyone, which is bad.

I'd like it to first check determineLanguage. If it return non-null, use
that. If it's null, use the regular headers method.
This would make the following common scenario possible.
User visits page: language == header
User chooses language/logs in: language == determineLanguage (via a
sessionvar).

Thanks!

While the example works fine, I had some trouble getting it to work in
my own project. I finally realized the difference: render vs renderCompat.
It works in render, but not in renderCompat!

Yes, and it also works only with vibe.web.web.render! So using
res.render!() in particular won't work, as well as
res.renderCompat!(). Those are just the plain template rendering
functions without any translation support.

I'll change the logic of determineLanguage to fall back to the default
algorithm instead of the default language.

On Thu 25 Sep 08:13, Lemonfiend wrote:

Yes, and it also works only with vibe.web.web.render! So using
res.render!() in particular won't work, as well as
res.renderCompat!(). Those are just the plain template rendering
functions without any translation support.
Ah I see.

I'll change the logic of determineLanguage to fall back to the default
algorithm instead of the default language.
Thanks!

Btw. Is it possible to translate things like this?
input&(type="text", placeholder=myi18nplaceholder)

Oh, and is it possible to mark a method as NOT being a route?

It seems render can only be called from a method that is public, and
public methods are parsed added as a @path automatically. But the method
where I call render is a helper function, something like:

class Webber
{

@path(`/`)
void get()
{
	if(something)
		_getA();
	else
		_getB();
}

protected void _getA()
{
	// do stuff

	render!(indexA.dt);
}

// etc.

}