"In principle" setting `SCRIPT_NAME` is enough. The way we do this is [1] using
`FORCE_SCRIPT_NAME` (which does not depend on messing with reverse proxy
settings and [2] by deducing the correct value from `BASE_URL` (which must be
set anyway) automatically.
By works I mean: `reverse` and `{% url` pick it up from there.
However, there are subtleties / extra work:
* `STATIC_URL` is needed too b/c https://code.djangoproject.com/ticket/34028
* in many pre-existing code I just created a path manually in the html. Such
hrefs are obviously not magically fixed for script_name. Rather than doing
the "full rewrite" (into `{% url`) this commit just prepends the
`script_name` in those cases. That's the way forward that will least likely
break and it gives us something to grep for if we ever want to 'do it
right'.
* `LOGIN_REDIRECT_URL` and `LOGIN_URL` needed to use a view-name for this to
work (using a view-name gets revolved using the thing that introduces
`script_name`)
Checked, no work needed:
* views (`redirect` and `HttpResponseRedirect`)
* html uses of action="..."
Fix#93
Having this as a model field is "annoying" because each added language
will trigger a (potentially costly) migration even though no real database
work is actually done for it.
Also implements a selector that shows languages in both their own language
and the currently activated language.
Correct spelling to "zh-hans" (lowercase); see https://stackoverflow.com/a/7729311
See #161
Implement delete functionality with confirmation modals for users. Ensure
proper authorization checks are in place before deletion. Add corresponding
JavaScript files to handle modal interactions and form submissions.
Based on #84
Signed-off-by: Animesh Agrawal <animesh@flick2know.com>
