4

I have seen the locale added to an URI as a path variable:

/en-US/blah/

or

/blah/en-US

and I have seen it as a request parameter:

/blah?lang=en-US

Is there a standard way that I should be doing it? If not what are the pros and cons of each approach?

I kind of like the request parameter approach because it doesn't require you to pass the locale with every URI (unless you use the second approach and add the locale to the end of the path). Any additional thoughts?

testing123
  • 11,367
  • 10
  • 47
  • 61

2 Answers2

5

I believe the "standard way" is to use an HTTP "accept language" header. Other than that, if you think it ought to be a parameter (because it's a system-system call or you might request a language other than the browser locale) then it's just a parameter the same as anything else and you should handle it in a similar fashion.

PaulProgrammer
  • 16,175
  • 4
  • 39
  • 56
0

Fun fact: even with this notation "/blah/en-US" it could still be a request parameter. Magic of mod_rewrite and friends.

If you need it as request parameter or part of the url depends of what you want to achieve. If you want to serve static content, you should have it be part of the path. If you want to act dynamically on the chosen locale, you should use it as request parameter, since you don't want to have your scripts replicated several times over different paths just to add different locales.

noamik
  • 756
  • 6
  • 22
  • And that's true even for `/en-US/blah`, especially with frameworks like RestEasy or WSGI that can pull variables from just about anywhere in the request... Thus, it's more important to behave in a consistent manner, if nothing else so that your programmers will have an easier time maintaining the solution. BTW: +1 for discussion static vs. dynamic content, but -1 for mentioning mod_rewrite (ick, IMHO). – PaulProgrammer May 09 '13 at 21:18
  • To be fair I mentioned "and friends" as well ;) – noamik May 13 '13 at 16:39