Forum: NGINX Multilanguage Websites

I would like to realize a website in multiple languages. Is there a way 
to implement the project with Nginx, or recommends you other ways?


Thanks for help and Greetings
Silvio

Hey Silvio, I've seen implementations of nginx with rewrites for 
different languages, but from personal experience in PHP, I've found it 
easy to implement language modules on the code side instead of having to 
worry about the webserver configuration side.. (just my opinion, and im 
a lazy php dev :))

If anyone would like to rebuttal, I would love to learn myself, just to 
see how it's done :D

Brad Riemann
Systems Engineer
FTW Entertainment LLC

Web server can help with multilanguage when yo uwanna use URL rewriting.

The problem start to arise when considering SEO. Separate languages per:
- Subdomains?
- Subdirectories?
- Tag in file names?

You may then wanna store language file is different directories on your 
Web
server to help you sort everything out.

Make the pros/cons and choose your solution.
Nginx is then a nice tool to help.

The rest is code in application, but that's not our concern here, 
talking
about Nginx...

---
*B. R.*

On Thu, 27 Dec 2012 11:36:56 -0500
"B.R." <reallfqq-nginx@yahoo.fr> wrote:

> Web server can help with multilanguage when yo uwanna use URL rewriting.

Yes that i've found on web, the way but not where goes the rewriting. 
What
i've found was most with index.php.

http://www.justasysadmin.net/en/practical/site-mul...

> The problem start to arise when considering SEO. Separate languages per:
> - Subdomains?
> - Subdirectories?
> - Tag in file names?

I think best where subdomains, thats the best result. When nginx it can.

> The rest is code in application, but that's not our concern here, talking
> about Nginx...

Thats normal, that why i ask. What were the best and secure way. Nginx 
or use
PHP? What is expirence of Nginx User.


Thanks for help and Greetings
Silvio

Hello,

On Thu, 27 Dec 2012 16:17:05 +0000
Brad Riemann <brad@ftwentertainment.com> wrote:

> Hey Silvio, I've seen implementations of nginx with rewrites for different 
languages, but from personal experience in PHP, I've found it easy to implement 
language modules on the code side instead of having to worry about the webserver 
configuration side.. (just my opinion, and im a lazy php dev :))

With php i was thinking, but work it correct that's why i ask. Is Server 
or Script better?


Thanks for help and Greetings
Silvio

I Think it is best for an Application to be webserver agnostic. That way 
it
does not matter what web server that is in front of your application.

There is cases where it makes sense to depend on NGINX for rewrites, but 
I
don't believe language is one of them.
For an example we run a big Ruby On Rails platform that hosts lots of
articles. We need to count the article hits every hour, and to do
article.hits = article.hits + 1 for every hit on an article hit.
To not stress our backend, and because hitting rails is costly, we do a
rewrite like this:
Http://site.com/article/15753/articlehit

Which is hitting a NodeJS application that does the before mentioned
operation and saves the result in memcache.

We do localization like this:
H = Hostname.find('kaspergrubbe.dk')
H.locale # returns 'da' for Danish locale

We then load up our i18n localization API with the locale and scope 
content
based on locale.

This solution is great for multiple domains. If you are not that 
fortunate
do site.com/:locale and if the locale is not there you could redirect 
the
user based on location/ip/etc.

On 27 December 2012 17:18, Silvio Siefke <siefke_listen@web.de> wrote:
> Is Server or Script better?

Distinguishing between different versions of content that should be
served to different users for a single URI is the job of the
application, not the system underlying it.

Whilst there are cases where nginx (or "your HTTP server", as this
isn't an nginx-specific discussion) should do some of this work (e.g.
choosing between gzipped output or not), switching content based on
the user's desired language is absolutely not one of them.

There *are* nginx configuration options which look like they might
help you with this, like http://wiki.nginx.org/HttpSplitClientsModule.
Do not be fooled. They should *not* be used for something as complex
as language selection.

Read the 5 very informative posts here (read from bottom to top) for
much more information about the complexities that you'll face during
an internationalization process. Then imagine trying to solve those
problems just using an nginx config. Then realise that that's a daft
idea: http://codeascraft.etsy.com/category/internationalization/

Jonathan
--
Jonathan Matthews // Oxford, London, UK
http://www.jpluscplusm.com/contact.html

Hello,

http://nginx.2469901.n2.nabble.com/rewrite-don-t-w...

If I understand it, nginx passes the language requests on on a directory
in the webroot. But on which module? Geoip? Basically I want to achieve 
that.
Default is German and the corresponding forwarding from the Accept 
Language.

Which module from nginx make that?


Regards, Thanks and Happy new Year
Silvio

On 31 December 2012 00:04, Silvio Siefke <siefke_listen@web.de> wrote:
> Hello,
>
> 
http://nginx.2469901.n2.nabble.com/rewrite-don-t-w...
>
> If I understand it, nginx passes the language requests on on a directory
> in the webroot. But on which module? Geoip? Basically I want to achieve that.
> Default is German and the corresponding forwarding from the Accept Language.

I strongly suggest to you that this is a dreadful idea. Do not do this.

Jonathan
--
Jonathan Matthews // Oxford, London, UK
http://www.jpluscplusm.com/contact.html

On Mon, 31 Dec 2012 00:16:06 +0000
Jonathan Matthews <contact@jpluscplusm.com> wrote:

> I strongly suggest to you that this is a dreadful idea. Do not do this.


Ok, but what ways have nginx? I'm looking for a way for days. With PHP,
the implementation seems complicated. Nginx offers Geoip module, but 
that
is a poor choice. I myself am often travel abroad, but I use German.
Accept Language looks good, but with Gentoo I can use the module only
without package manager. The websites in different languages ​​are done,
I needed a redirect and a default solution.


Greetings, Thank you and Happy new Year
Silvio

On Mon, Dec 31, 2012 at 05:50:14PM +0100, Silvio Siefke wrote:

Hi there,

> Ok, but what ways have nginx? I'm looking for a way for days.

What, precisely, do you mean by "Multilanguage Websites"?

If you mean "separate content for each of language1, language2,
language3; all available at separate urls", then you need no
special web server cleverness after the user has chosen to go to
http://language1.example.org/ or to http://www.example.org/language1/
(depending on how you deploy it).

All you need is for the index page on the "main" web site to offer a
series of links to each of the known separate language index pages.

Have a look at (for example) http://www.wikipedia.org/ or (as you've
previously linked to) http://www.justasysadmin.net/

The former looks like it serves the same content to all; the latter 
tries
some guessing of preferred language which fails on some of my browsers.


If you want to implement some cleverness on the index page to avoid the
user having to manually choose language, you must decide what you want
the choice to be based on. Whatever you do choose, it may be worth your
while making clear to the user why you chose that one, and what the user
can do to get to the language version they actually prefer.

The HTTP Accept-Language header is probably a reasonable choice, if your
users know how to change it or to override it for your site.

You are unlikely to be able to write a correct interpreter for the
content of that header in the confines of the nginx.conf language.

So you are probably better off writing an application to do it --
maybe in one of the embedded languages, or maybe as external code
altogether. That application will need up-to-date information on which
languages are currently available, so I suggest that external code is
probably simpler to maintain.

> Accept Language looks good, but with Gentoo I can use the module only
> without package manager. The websites in different languages ​​are done,
> I needed a redirect and a default solution.

The only modules used in the nginx.conf versions that you have linked
to are core, map, and rewrite, as far as I can see. I suggest you use
one of the "other server" modules, such as fastcgi.

The only unusual part of nginx.conf would then be special handling for

  location = / {}

where you would cause your external code to return either a redirect to
the appropriate language index page, or the content (or a redirect to 
the
content) of the "here are the various links, click the one you like" 
page.

If you want to know how to properly interpret the content of the
Accept-Language header, read the RFC or examine (for example) apache's
mod_negotiation.c. You should compare "languages available" with 
"ordered
list of languages acceptable", being aware of how (for example) "de-DE",
"de-AT", and "de" compare within and between those lists.

It's complicated. That's why I suggest you do it outside of nginx.conf.



If, instead of all of that, you want "same url gives different content
to different clients based on their preferred language", then there's
probably a lot more work involved.

  f
--
Francis Daly        francis@daoine.org

On Mon, 31 Dec 2012 17:55:18 +0000
Francis Daly <francis@daoine.org> wrote:

> If you mean "separate content for each of language1, language2,
> language3; all available at separate urls", then you need no
> special web server cleverness after the user has chosen to go to
> http://language1.example.org/ or to http://www.example.org/language1/
> (depending on how you deploy it).

Yes at moment i have my webroot so
htdocs/de -> Default
htdocs/en
htdocs/fr
htdocs/ar

It need only be redirected.

> All you need is for the index page on the "main" web site to offer a
> series of links to each of the known separate language index pages.

The best way it is when it happens automatically. I find the language
selection boxes unappealing.

> Have a look at (for example) http://www.wikipedia.org/ or (as you've
> previously linked to) http://www.justasysadmin.net/

The CMS or wiki systems use different languages that's normal for the
Design and the use of the Software. I use never this Systems.

> If you want to implement some cleverness on the index page to avoid the
> user having to manually choose language, you must decide what you want
> the choice to be based on. Whatever you do choose, it may be worth your
> while making clear to the user why you chose that one, and what the user
> can do to get to the language version they actually prefer.
>
> The HTTP Accept-Language header is probably a reasonable choice, if your
> users know how to change it or to override it for your site.

We must again use this language selection boxes. Web 2.0 let's rock.


Regards
Silvio

Hello,

ok i have make with PHP a Redirect from Accept Language. It's running
perfect and was easy. How do I make the best with nginx? For each site
a server? In the webroot subfolder is that the solution? How can I best
be used to ensure that the search engines are also satisfied.


Thanks for help. Greetings
Silvio

On Wed, Jan 02, 2013 at 03:26:14PM +0100, Silvio Siefke wrote:

Hi there,

> ok i have make with PHP a Redirect from Accept Language. It's running
> perfect and was easy. How do I make the best with nginx? For each site
> a server? In the webroot subfolder is that the solution? How can I best
> be used to ensure that the search engines are also satisfied.

It's good that you got the nginx-related part working -- deciding to use
external code for the redirect, and using fasctcgi_pass or proxy_pass
or whichever you chose.

For the questions in this mail, you'll probably get better answers from
a list which deals with that topic.

"better answers" really means "when one person gives bad advice, others
are knowledgeable and interested enough to correct it".

nginx.conf can handle each of http://language1.example.org/ and
http://www.example.org/language1/ as easily as the other, so there's no
"best" from an nginx perspective.

Good luck with it,

  f
--
Francis Daly        francis@daoine.org