Reversing translated urls in templates

[Florian Apolloner]

Hi,

I would like to get some feedback on https://code.djangoproject.com/ticket/16332
Jacob suggested that the standard url-tag should take a lang argument
so we don't need an extra tag (okay, his actual concern was the
dislike of the name i18n_url ;)). I would like that idea too, but I am
somewhat worried about the implications; eg it would break as soon as
someone already has "lang" as param in his urlconf and using a
parameter like __lang isn't that nice either…

Any thoughts on this?

Cheers,
Florian

[Florian Apolloner]

[Jannis Leidel]

As I said initially when we discussed this on IRC, I believe a "i18n_url" is good enough
and would fit well with the other i18n related template tags.

Besides the ambiguity of a potential keyword argument "lang", I'd like to mention that
we specifically chose to use "i18n_patterns" as the name for the function that returns
i18n-enabled URL patterns to be explicit about when a URL should be translated. I believe
this pattern should also be applied to the template tag which a user might use to point to
one of those translatable URLs.

Jannis

[maxk]

What do you think about something like below

{% url viewname k1=v1, k2=v2 with lang=lang %}

?

On Jun 25, 12:52 am, Florian Apolloner <f.apollo...@gmail.com> wrote:
> Hi,
>

> I would like to get some feedback onhttps://code.djangoproject.com/ticket/16332

[Florian Apolloner]

On Jun 25, 11:58 am, Jannis Leidel <lei...@gmail.com> wrote:
> As I said initially when we discussed this on IRC, I believe a "i18n_url" is good enough
> and would fit well with the other i18n related template tags.

Jupp, I just wanted to here if someone else had different feelings
about it.

> I believe
> this pattern should also be applied to the template tag which a user might use to point to
> one of those translatable URLs.

Agreed, I leave the patch like it's now. Though I am still open for
suggestions on cleaning up the code duplication.

Cheers,
Florian

[Ramiro Morales]

On Sat, Jun 25, 2011 at 6:58 AM, Jannis Leidel <lei...@gmail.com> wrote:
>
> As I said initially when we discussed this on IRC, I believe a "i18n_url" is good enough
> and would fit well with the other i18n related template tags.
>
> Besides the ambiguity of a potential keyword argument "lang", I'd like to mention that
> we specifically chose to use "i18n_patterns" as the name for the function that returns
> i18n-enabled URL patterns to be explicit about when a URL should be translated. I believe
> this pattern should also be applied to the template tag which a user might use to point to
> one of those translatable URLs.
>

On Sat, Jun 25, 2011 at 2:50 AM, maxk <klym...@gmail.com> wrote:
> What do you think about something like below
>
>  {% url viewname k1=v1, k2=v2 with lang=lang %}

Briefly discussed this via IRC th Jannis. I'm +1 on keeping the new tag
in the i18 ttag lib for the reasons exposed by Jannis. So a prefix like
'i18n_' would fit well IMHO. +1 on this.

Adding that functionality to the i18n tag can also work, I think.
Especially now that Jannis makes me see it wouldn't cause loading of the
i18n machinery for people with USE_i18N=False. But I'd like to
completely avoid the possibility of clashing with existing 'lang'
arguments and I'm not 100% convinced by the "with lang='xx'" part of the
proposed syntax. It is a hybrid between our 'old' "with var as alias"
and the new (from future) "var=alias" form. I'm -0 on this option

--
Ramiro Morales

[brocaar]

What about not implementing this as a url tag but as a translation-
override tag? Then it is not only possible to specify the language to
use for your URL translation, but as well for other translatable
content. Example:

{% transoverride language_code %}
{% trans "Register account" %}: {% url account:register %}
{% endtransoverride %}


Orne

[Juan Pablo Martínez]

I think {% transurl account:register %} would be more convenient to work with i18n_patterns

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

[Chris Beaven]

That does have the advantage of being more flexible even in just the context of urls. For example, referring to a url via {{ obj.get_absolute_url }}.

+1 for more flexibility.

That's one ugly tag name though :D

[Jannis Leidel]

On 04.07.2011, at 02:48, Chris Beaven wrote:

>
> On Monday, July 4, 2011 1:42:37 AM UTC+12, brocaar wrote:
> What about not implementing this as a url tag but as a translation-
> override tag? Then it is not only possible to specify the language to
> use for your URL translation, but as well for other translatable
> content. Example:
>
> {% transoverride language_code %}
> {% trans "Register account" %}: {% url account:register %}
> {% endtransoverride %}

Oh, I like that much better, too.

> That does have the advantage of being more flexible even in just the context of urls. For example, referring to a url via {{ obj.get_absolute_url }}.
> +1 for more flexibility.
>
> That's one ugly tag name though :D

Agreed, what about just "language", e.g.:

{% language lang_code %}

{% trans "Register account" %}: {% url account:register %}

{% endlanguage %}

Jannis

[brocaar]

On Monday, July 4, 2011 10:04:10 AM UTC+2, Jannis Leidel wrote:

Agreed, what about just "language", e.g.:

{% language lang_code %}
    {% trans "Register account" %}: {% url account:register %}
{% endlanguage %}

I agree too that the tag name in my example is quite ugly, it was only to clarify my idea ;) Just "language" sounds perfect!

Orne  

[Sam Bull]

I like this quite a bit. It's clean, and it allows for a common i18n pattern where the footer contains a translation link for each supported language, and the language names are localized to themselves (i.e. "Español | Français | Deutsch").

Sam

> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/huy6SEXMIBkJ.

[Jonathan Slenders]

I'm also +1 on {% language lang_code %}... {% endlanguage %}

We are using exactly this template tag for maybe about half a year
already. Not for i18n urls, but for formatting numbers. The decimal
separator in Dutch is a comma, but sometimes we want to be sure to
have a dot a some part of the template. (When rendering SVG, JSON or
other markup lanugages.)

So, this is certainly a very versatile approach.

[Jannis Leidel]

Great, thanks all for your opinions, I actually went ahead yesterday
and added it in https://code.djangoproject.com/changeset/16501

Jannis

[Stephen Kelly]

Jannis Leidel wrote:

Isn't this about more than language, but also locale?

In Grantlee I implemented this as a with_locale tag:

http://gitorious.org/grantlee/grantlee/blobs/master/examples/contacts/themes/linguist/sleepy/main.html

And then eg dates are also localized:

http://steveire.files.wordpress.com/2010/11/contacts_multi_lang_headers.png