Internationalise GET parameters?

[Jorge C. Leitão]

Hi,

I'm came across to the situation where, for URL cleanness,

See Cool URIs don’t change, by World Wide Web creator Tim Berners-Lee, for excellent arguments on why URLs should be clean and usable.

I wanted to internationalise its parameters. E.g. this 

www.example.com/persons?search=...

be shown as 

www.example.com/personas?busca=...

I search on the documentation, and this does not seemed to be documented. I.e. the API allows to change how the field name is presented as HTML, but it does not allow internationalising it on the URL.

IMO, this lies on the assumption that the Form's field names are never shown to the user. When the form is POST, this assumption is valid. However, in a GET, the field names are presented in the URL, and the assumption breaks. This even exposes serve-side implementation details (the field name of the Form) to the user.

I thus filled a ticket [1] proposing to decouple the two things: the field_name on the server side and how it is represented on the client side. There is also a Stackoverflow question [2] on this with a different implementation than I'm presenting in [1].

Tim suggested to bring this here because of the following issues he pointed out:

1. how common is this?

2. wouldn't it add a lot of complexity to JavaScript and CSS, specifically on name selectors?

3. do any other web framework support this?

The answers I can give so far:

1., I tried to do it because I didn't wanted english on a portuguese website's URL neither portuguese on my code. It seemed a reasonable request for a web framework, but yes, it may not be so common.

2., I may be; I don't know enough to answer it.

3., I'm not familiar with other frameworks; I've searched Ruby on Rails documentation and I didn't found it.

Could we have some feedback to decide wether it justifies or not to have this in Django?

Thank you for your time,

Jorge

[1] https://code.djangoproject.com/ticket/23927

[2] http://stackoverflow.com/questions/24051937/how-to-translate-get-keys-in-django-forms

[Florian Apolloner]

On Friday, November 28, 2014 11:17:15 AM UTC+1, Jorge C. Leitão wrote:

IMO, this lies on the assumption that the Form's field names are never shown to the user. When the form is POST, this assumption is valid. However, in a GET, the field names are presented in the URL, and the assumption breaks. This even exposes serve-side implementation details (the field name of the Form) to the user.

You always expose some server information, even with POST -- you just don't see the parameters in the URL
 

1. how common is this?

No idea on that, but field names are programmatic identifiers (as you said, they are an implementation detail), translating those will break loads of things.
 

2. wouldn't it add a lot of complexity to JavaScript and CSS, specifically on name selectors?

They wouldn't work anymore unless you send a mapping to the client, again exposing server implementation details.
 

3. do any other web framework support this?

Not that I am aware.

Could we have some feedback to decide wether it justifies or not to have this in Django?

Personally, I am against it, I don't think that the gains justify the effort.

Cheers,
Florian

[Marc Tamlyn]

I'm afraid I have to agree the gain does not merit the effort.

To the average user, I think the query string already looks like it's weird code stuff (with &=?) so I don't think it being in a different language would improve things that much.

Marc

--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c3258005-6bac-483f-b425-2681b8898b34%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jorge C. Leitão]

Hi,

Thanks both for the feedback; I was not seeing the whole issue with JS, and I now share your concerns. 

To me, the ticket can be closed as won't fix (https://code.djangoproject.com/ticket/23927).

Thanks Tim for raising the issues that brought us here.

Cheers,

Jorge