django 1.4.1 has built-in support for locale-prefixed URLs and translatable URLs, including reverse()-type helpers that are aware of this.
Priority: -- → P1
Whiteboard: u=developer c=infrastructure p= → u=developer c=infrastructure s=2012-06-05 p=
Whiteboard: u=developer c=infrastructure s=2012-06-05 p= → u=developer c=infrastructure s= p=
Component: Website → Landing pages
Product: Mozilla Developer Network → Mozilla Developer Network
Are we using this already?
Component: Landing pages → Localization
Whiteboard: u=developer c=infrastructure s= p=
deflecting to ubernostrum.
Flags: needinfo?(lcrouch) → needinfo?(jbennett)
We should not attempt to use this right now. Django's current locale-prefixed URL support is not compatible with what we need: * It has issues with mixed-case language identifiers, so "en-US" may not be accepted, for example (needing "en-us" instead). * It has issues with some language/country combinations. The one I know of right now is one we don't use ("de-AT"), but I'd want to stay away until we know that's fixed. So for now probably best to just stay on our own homegrown prefixing middleware, though might be worth investigating whether the code that's now in Django -- which is not a middleware, and instead does the work at the level of URL resolution -- is something we could build a cleaner version on.
Going to close this one out. We can open a separate bug for the work James mentions in comment 3 as needed.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.