Re: Ignoring accept_language in localization middleware based on prefixed URL patterns

[Janez Kranjc]

So regarding the implementation my proposal is this:

instead of checking if a prefixed url pattern exists, resolve the current
request path to a pattern and check if it is i18n prefixed

any idea how much of a performance hit that would be? Because right now
we're accessing a cached variable, which is super fast. With this
implementation there's a bit more work that the server needs to do in the
middleware. The problem is that URL resolving takes place after the
middleware so even resolver_match is not yet available when we need it. Any
suggestions?

On Wed, 7 Aug 2019 at 09:51, Janez Kranjc  wrote:

> Another problem that is specific to APIs (which are not really the point
> here, just an example) is that using prefixed URLs that has the default
> language also prefixed - prefixing API urls during the lifetime of the
> application would break the API for specific users because the previous
> URLs would 302 to new URLs and all POST requests would break. But like I
> said - an API is just an example I'm using to illustrate my problem. Could
> be any part of an application.
>
> On Wed, 7 Aug 2019 at 09:20, Janez Kranjc  wrote:
>
>> Nothing prevents the change to the API endpoint except the fact that
>> users are actively using the API already and (it is my opinion) that a
>> change in another part of the application - like a sales page - shouldn't
>> affect the working of an unrelated part of the project. Also that would
>> mean refactoring the front-end code which uses API endpoint to use
>> different URLs instead of just adding a header.
>>
>> Imagine that I have a third party app and I include its URLs and they
>> have prefixed URLs (unlikely but could happen) - this would force me to
>> change the way my URLs work in order to have a multilingual API.
>>
>> On Wed, 7 Aug 2019 at 09:13, Aldian Fazrihady  wrote:
>>
>>> What prevents the change to the API endpoints so it will have language
>>> prefix as well?
>>>
>>> On Wed, Aug 7, 2019 at 1:56 PM Aymeric Augustin <
>>> aymeric.augus...@polytechnique.org> wrote:
>>>
 Hello,

 Yes, I think this change makes sense, assuming no unexpected
 difficulties arise in the implementation.

 Best regards,

 --
 Aymeric.



 On 6 Aug 2019, at 10:58, Janez Kranjc  wrote:

 Hi guys! I’m Janez Kranjc, I’ve been using Django for a bit now - since
 1.3 and I’ve recently come across and issue that’s been bothering me in
 multiple projects that I’m working on.

 Localization middleware ignores the accept language header if ANY url
 pattern exists that is i18n prefixed regardless of the current URL of the
 request.

 So the problem is the following: I have some URLs that are prefixed,
 and a lot that are not (such as all of the API endpoints). I sometimes need
 to return some translated strings in the API as well and for that I rely on
 the accept-language header. However in the middleware it is ignored because
 an unrelated part of the project has an i18n prefixed url pattern.

 Another way to look at the problem is this:

 Let’s say I have a SPA that uses i18n on its API endpoints and you rely
 on accept-language to serve the responses in the correct locale. I then
 decide to add a new app to your django project - a sales page. Instead of
 relying on accept-language I wish to have i18n prefixed URLs (maybe for SEO
 reasons or whatever). Suddenly the behaviour of the API changes even though
 I’ve made changes to an entirely different part of the project.

 Would it not make more sense for the middleware to check if the current
 URL pattern (the one that the request URL resolves to) is prefixed or not.

 The way I see it, this should be changed:

 i18n_patterns_used, prefixed_default_language =
 is_language_prefix_patterns_used(urlconf)

 Instead of checking the entire urlconf it should only check the current
 request URL and see if it resolves to a pattern that is i18n prefixed.

 To get around this I need to use a custom localization firmware in a
 lot of my projects. I would like to hear the devs’ opinion regarding this.

 --
 You received this message because you are subscribed to the Google
 Groups "Django developers (Contributions to Django itself)" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to django-developers+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/django-developers/1b315c0b-9200-417b-816a-dd3c3b90ec67%40googlegroups.com
 
 .


 --
 You received this message because you are subscribed to the Google
 Groups "Django developers (Contributions to Django itself)" gro

Re: Ignoring accept_language in localization middleware based on prefixed URL patterns

[Janez Kranjc]

Another problem that is specific to APIs (which are not really the point
here, just an example) is that using prefixed URLs that has the default
language also prefixed - prefixing API urls during the lifetime of the
application would break the API for specific users because the previous
URLs would 302 to new URLs and all POST requests would break. But like I
said - an API is just an example I'm using to illustrate my problem. Could
be any part of an application.

On Wed, 7 Aug 2019 at 09:20, Janez Kranjc  wrote:

> Nothing prevents the change to the API endpoint except the fact that users
> are actively using the API already and (it is my opinion) that a change in
> another part of the application - like a sales page - shouldn't affect the
> working of an unrelated part of the project. Also that would mean
> refactoring the front-end code which uses API endpoint to use different
> URLs instead of just adding a header.
>
> Imagine that I have a third party app and I include its URLs and they have
> prefixed URLs (unlikely but could happen) - this would force me to change
> the way my URLs work in order to have a multilingual API.
>
> On Wed, 7 Aug 2019 at 09:13, Aldian Fazrihady  wrote:
>
>> What prevents the change to the API endpoints so it will have language
>> prefix as well?
>>
>> On Wed, Aug 7, 2019 at 1:56 PM Aymeric Augustin <
>> aymeric.augus...@polytechnique.org> wrote:
>>
>>> Hello,
>>>
>>> Yes, I think this change makes sense, assuming no unexpected
>>> difficulties arise in the implementation.
>>>
>>> Best regards,
>>>
>>> --
>>> Aymeric.
>>>
>>>
>>>
>>> On 6 Aug 2019, at 10:58, Janez Kranjc  wrote:
>>>
>>> Hi guys! I’m Janez Kranjc, I’ve been using Django for a bit now - since
>>> 1.3 and I’ve recently come across and issue that’s been bothering me in
>>> multiple projects that I’m working on.
>>>
>>> Localization middleware ignores the accept language header if ANY url
>>> pattern exists that is i18n prefixed regardless of the current URL of the
>>> request.
>>>
>>> So the problem is the following: I have some URLs that are prefixed, and
>>> a lot that are not (such as all of the API endpoints). I sometimes need to
>>> return some translated strings in the API as well and for that I rely on
>>> the accept-language header. However in the middleware it is ignored because
>>> an unrelated part of the project has an i18n prefixed url pattern.
>>>
>>> Another way to look at the problem is this:
>>>
>>> Let’s say I have a SPA that uses i18n on its API endpoints and you rely
>>> on accept-language to serve the responses in the correct locale. I then
>>> decide to add a new app to your django project - a sales page. Instead of
>>> relying on accept-language I wish to have i18n prefixed URLs (maybe for SEO
>>> reasons or whatever). Suddenly the behaviour of the API changes even though
>>> I’ve made changes to an entirely different part of the project.
>>>
>>> Would it not make more sense for the middleware to check if the current
>>> URL pattern (the one that the request URL resolves to) is prefixed or not.
>>>
>>> The way I see it, this should be changed:
>>>
>>> i18n_patterns_used, prefixed_default_language =
>>> is_language_prefix_patterns_used(urlconf)
>>>
>>> Instead of checking the entire urlconf it should only check the current
>>> request URL and see if it resolves to a pattern that is i18n prefixed.
>>>
>>> To get around this I need to use a custom localization firmware in a lot
>>> of my projects. I would like to hear the devs’ opinion regarding this.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-developers+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/1b315c0b-9200-417b-816a-dd3c3b90ec67%40googlegroups.com
>>> 
>>> .
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-developers+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/09EBC24C-868E-4197-AEAE-87CB82787DDE%40polytechnique.org
>>> 
>>> .
>>>
>>
>>
>> --
>> Regards,
>>
>> Aldian Fazrihady
>> http://aldianfazrihady.com
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubsc

Re: Ignoring accept_language in localization middleware based on prefixed URL patterns

[Janez Kranjc]

Nothing prevents the change to the API endpoint except the fact that users
are actively using the API already and (it is my opinion) that a change in
another part of the application - like a sales page - shouldn't affect the
working of an unrelated part of the project. Also that would mean
refactoring the front-end code which uses API endpoint to use different
URLs instead of just adding a header.

Imagine that I have a third party app and I include its URLs and they have
prefixed URLs (unlikely but could happen) - this would force me to change
the way my URLs work in order to have a multilingual API.

On Wed, 7 Aug 2019 at 09:13, Aldian Fazrihady  wrote:

> What prevents the change to the API endpoints so it will have language
> prefix as well?
>
> On Wed, Aug 7, 2019 at 1:56 PM Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
>
>> Hello,
>>
>> Yes, I think this change makes sense, assuming no unexpected difficulties
>> arise in the implementation.
>>
>> Best regards,
>>
>> --
>> Aymeric.
>>
>>
>>
>> On 6 Aug 2019, at 10:58, Janez Kranjc  wrote:
>>
>> Hi guys! I’m Janez Kranjc, I’ve been using Django for a bit now - since
>> 1.3 and I’ve recently come across and issue that’s been bothering me in
>> multiple projects that I’m working on.
>>
>> Localization middleware ignores the accept language header if ANY url
>> pattern exists that is i18n prefixed regardless of the current URL of the
>> request.
>>
>> So the problem is the following: I have some URLs that are prefixed, and
>> a lot that are not (such as all of the API endpoints). I sometimes need to
>> return some translated strings in the API as well and for that I rely on
>> the accept-language header. However in the middleware it is ignored because
>> an unrelated part of the project has an i18n prefixed url pattern.
>>
>> Another way to look at the problem is this:
>>
>> Let’s say I have a SPA that uses i18n on its API endpoints and you rely
>> on accept-language to serve the responses in the correct locale. I then
>> decide to add a new app to your django project - a sales page. Instead of
>> relying on accept-language I wish to have i18n prefixed URLs (maybe for SEO
>> reasons or whatever). Suddenly the behaviour of the API changes even though
>> I’ve made changes to an entirely different part of the project.
>>
>> Would it not make more sense for the middleware to check if the current
>> URL pattern (the one that the request URL resolves to) is prefixed or not.
>>
>> The way I see it, this should be changed:
>>
>> i18n_patterns_used, prefixed_default_language =
>> is_language_prefix_patterns_used(urlconf)
>>
>> Instead of checking the entire urlconf it should only check the current
>> request URL and see if it resolves to a pattern that is i18n prefixed.
>>
>> To get around this I need to use a custom localization firmware in a lot
>> of my projects. I would like to hear the devs’ opinion regarding this.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/1b315c0b-9200-417b-816a-dd3c3b90ec67%40googlegroups.com
>> 
>> .
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/09EBC24C-868E-4197-AEAE-87CB82787DDE%40polytechnique.org
>> 
>> .
>>
>
>
> --
> Regards,
>
> Aldian Fazrihady
> http://aldianfazrihady.com
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/IxI-nTb1W7I/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAN7EoAa4tC-dPBFHj-_kMyAUv67sQRFPA-V98mRyTjaYcYvcMA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Googl

Re: Ignoring accept_language in localization middleware based on prefixed URL patterns

[Aldian Fazrihady]

What prevents the change to the API endpoints so it will have language
prefix as well?

On Wed, Aug 7, 2019 at 1:56 PM Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello,
>
> Yes, I think this change makes sense, assuming no unexpected difficulties
> arise in the implementation.
>
> Best regards,
>
> --
> Aymeric.
>
>
>
> On 6 Aug 2019, at 10:58, Janez Kranjc  wrote:
>
> Hi guys! I’m Janez Kranjc, I’ve been using Django for a bit now - since
> 1.3 and I’ve recently come across and issue that’s been bothering me in
> multiple projects that I’m working on.
>
> Localization middleware ignores the accept language header if ANY url
> pattern exists that is i18n prefixed regardless of the current URL of the
> request.
>
> So the problem is the following: I have some URLs that are prefixed, and a
> lot that are not (such as all of the API endpoints). I sometimes need to
> return some translated strings in the API as well and for that I rely on
> the accept-language header. However in the middleware it is ignored because
> an unrelated part of the project has an i18n prefixed url pattern.
>
> Another way to look at the problem is this:
>
> Let’s say I have a SPA that uses i18n on its API endpoints and you rely on
> accept-language to serve the responses in the correct locale. I then decide
> to add a new app to your django project - a sales page. Instead of relying
> on accept-language I wish to have i18n prefixed URLs (maybe for SEO reasons
> or whatever). Suddenly the behaviour of the API changes even though I’ve
> made changes to an entirely different part of the project.
>
> Would it not make more sense for the middleware to check if the current
> URL pattern (the one that the request URL resolves to) is prefixed or not.
>
> The way I see it, this should be changed:
>
> i18n_patterns_used, prefixed_default_language =
> is_language_prefix_patterns_used(urlconf)
>
> Instead of checking the entire urlconf it should only check the current
> request URL and see if it resolves to a pattern that is i18n prefixed.
>
> To get around this I need to use a custom localization firmware in a lot
> of my projects. I would like to hear the devs’ opinion regarding this.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/1b315c0b-9200-417b-816a-dd3c3b90ec67%40googlegroups.com
> 
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/09EBC24C-868E-4197-AEAE-87CB82787DDE%40polytechnique.org
> 
> .
>


-- 
Regards,

Aldian Fazrihady
http://aldianfazrihady.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAN7EoAa4tC-dPBFHj-_kMyAUv67sQRFPA-V98mRyTjaYcYvcMA%40mail.gmail.com.

Re: Ignoring accept_language in localization middleware based on prefixed URL patterns

[Aymeric Augustin]

Hello,

Yes, I think this change makes sense, assuming no unexpected difficulties arise 
in the implementation.

Best regards,

-- 
Aymeric.



> On 6 Aug 2019, at 10:58, Janez Kranjc  wrote:
> 
> Hi guys! I’m Janez Kranjc, I’ve been using Django for a bit now - since 1.3 
> and I’ve recently come across and issue that’s been bothering me in multiple 
> projects that I’m working on.
> 
> Localization middleware ignores the accept language header if ANY url pattern 
> exists that is i18n prefixed regardless of the current URL of the request.
> 
> So the problem is the following: I have some URLs that are prefixed, and a 
> lot that are not (such as all of the API endpoints). I sometimes need to 
> return some translated strings in the API as well and for that I rely on the 
> accept-language header. However in the middleware it is ignored because an 
> unrelated part of the project has an i18n prefixed url pattern.
> 
> Another way to look at the problem is this:
> 
> Let’s say I have a SPA that uses i18n on its API endpoints and you rely on 
> accept-language to serve the responses in the correct locale. I then decide 
> to add a new app to your django project - a sales page. Instead of relying on 
> accept-language I wish to have i18n prefixed URLs (maybe for SEO reasons or 
> whatever). Suddenly the behaviour of the API changes even though I’ve made 
> changes to an entirely different part of the project.
> 
> Would it not make more sense for the middleware to check if the current URL 
> pattern (the one that the request URL resolves to) is prefixed or not.
> 
> The way I see it, this should be changed:
> 
> i18n_patterns_used, prefixed_default_language = 
> is_language_prefix_patterns_used(urlconf)
> 
> Instead of checking the entire urlconf it should only check the current 
> request URL and see if it resolves to a pattern that is i18n prefixed.
> 
> To get around this I need to use a custom localization firmware in a lot of 
> my projects. I would like to hear the devs’ opinion regarding this.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/1b315c0b-9200-417b-816a-dd3c3b90ec67%40googlegroups.com
>  
> .

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/09EBC24C-868E-4197-AEAE-87CB82787DDE%40polytechnique.org.