On 6 Aug 2012, at 2:33 AM, Athelionas <athelio...@gmail.com> wrote: > Yes, it seems like that is the problem. I couldn't find a way of dealing with > this case in routes.py so I guess my only option is to handle these cases > separately in my nginx config. It is a shame, though, that there's not a > simple way of dealing with this directly in web2py by rewriting outgoing > URLs. Please correct me if I'm wrong or you have a better idea. > Also, as I'm in the process of migrating from cherokee to nginx I could use > some help regarding nginx mapping from someone with a better knowledge of the > topic. What I wrote in the config file this far is quite straightforward but > I barely have an idea how something like the above mentioned solution should > be accomplished.
I have a fix in mind. If you go ahead with explicit nginx mapping of all your static files, please leave map_static set to its default (None); do *not* set it to False. I intend to use False as a flag to the router (when language mapping is in use) to generate static/lang/file URLs instead of lang/static/file. Once you have the change, you can set map_static=False and simplify your nginx routing. > > 2012. augusztus 6., hétfő 4:20:24 UTC+2 időpontban Jonathan Lundell a > következőt írta: > On 5 Aug 2012, at 7:10 PM, pbreit <pbreitenb...@gmail.com> wrote: >> Shouldn't it be: >> >> root /home/www-data/web2py/applications/myapp/; >> >> > > No, he was saying it works OK without a language specified. Setting > map_static=False (which is the default) means that static URLs have a full > URL, including the app name. > > I think I know what the problem is, though. When a language is specified, the > URL is /app/lang/static/..., which the router would map to > /app/static/lang/..., but nginx is not. > > I don't know the nginx mapping syntax. If possible, you want to map > /app/en/static/... to /app/static/en/..., and the same for hu. I'm thinking > that the router should have another variation to handle this case in a more > straightforward way. Or else this case should always put the language in the > same order as the physical file layout. I don't *think* that'd cause backward > compatibility problems... > > --
