Translation templatetag aliases

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Translation templatetag aliases

Mike Hansen
Hello all,

Recently I had a member of my team bring up that it was uncomfortable
for them to work in parts of our codebase where they regularly had to
see "blocktrans" in the template files.  To make our work environment
more inclusive, I wrote a Django package which adds "translate" and 
"blocktranslate" templatetag aliases so that we could update our own 
internal templates to use these.

We felt that this change would be in line with the Django community
so I made a ticket and pull request to Django at
https://code.djangoproject.com/ticket/30585 .  The ticket was closed as
"wontfix", and it was mentioned that I should bring it to django-developers
if I wanted to make further progress on the ticket.

Thanks,
--Mike

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a43ec0ab-f73a-4c11-8fc1-b05d081b24c3%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Translation templatetag aliases

Aymeric Augustin
Hello,

I'm in favor of adding support for {% translate %} and {% blocktranslate %} and switching the Django documentation to use these for two reasons:

- As stated by Mike, the mental associations that "block trans" creates for those who identify as trans are just bad — I can't believe it took us 12 years to notice :-/
- Even if we leave that aside, I'm not sure saving 4 characters (8 with the closing tag) is really worth the uncommon abbreviation of "translate".

Since this change brings mostly a social benefit rather than a technical benefit, we could keep the {% trans %} and {% blocktrans %} aliases forever. Also, this could minimize arguments between those who recognize the benefits of such changes and those who don't, as we've seen when we changed master / slave to primary / replica.

In my opinion, such debates mostly reflect the political rift that appeared in many Western countries in the recent years. It's completely predictable that they spill into our community. Since they aren't our main focus, we're trying to avoid spending too much time there. But we can't escape the fact that we're making Django first for people writing software, then for computers running that software.

As a community, we chose to state in our Code of Conduct that "we strive to be a community that welcomes and supports people of all backgrounds and identities [including] sexual orientation, gender identity and expression". I believe that the change proposed here is in line with this statement. I know that some community members will feel that we're doing too much here — and that others feel that we aren't doing enough in general — which is why I'm referencing something we already agreed upon.

Best regards,

-- 
Aymeric.



On 26 Jul 2019, at 13:17, 'Mike Hansen' via Django developers (Contributions to Django itself) <[hidden email]> wrote:

Hello all,

Recently I had a member of my team bring up that it was uncomfortable
for them to work in parts of our codebase where they regularly had to
see "blocktrans" in the template files.  To make our work environment
more inclusive, I wrote a Django package which adds "translate" and 
"blocktranslate" templatetag aliases so that we could update our own 
internal templates to use these.

We felt that this change would be in line with the Django community
so I made a ticket and pull request to Django at
https://code.djangoproject.com/ticket/30585 .  The ticket was closed as
"wontfix", and it was mentioned that I should bring it to django-developers
if I wanted to make further progress on the ticket.

Thanks,
--Mike


--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a43ec0ab-f73a-4c11-8fc1-b05d081b24c3%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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/EF4EE680-BBA1-40EB-979E-2671349186D6%40polytechnique.org.
Reply | Threaded
Open this post in threaded view
|

Re: Translation templatetag aliases

Adam Johnson-2
+1 from me too for the reasons that Aymeric states.

Another small pro: "translate" is a few more characters to type, but it should make it easier to understand the purpose of the tags to newcomers. "trans" is a prefix used for many words - Wiktionary lists 609: https://en.wiktionary.org/wiki/Category:English_words_prefixed_with_trans- . I guess quite a few Django apps out there have *some* domain term on this list, so using the full word "translate" can help differentiate the tags from those other concepts.

On Sat, 27 Jul 2019 at 09:51, Aymeric Augustin <[hidden email]> wrote:
Hello,

I'm in favor of adding support for {% translate %} and {% blocktranslate %} and switching the Django documentation to use these for two reasons:

- As stated by Mike, the mental associations that "block trans" creates for those who identify as trans are just bad — I can't believe it took us 12 years to notice :-/
- Even if we leave that aside, I'm not sure saving 4 characters (8 with the closing tag) is really worth the uncommon abbreviation of "translate".

Since this change brings mostly a social benefit rather than a technical benefit, we could keep the {% trans %} and {% blocktrans %} aliases forever. Also, this could minimize arguments between those who recognize the benefits of such changes and those who don't, as we've seen when we changed master / slave to primary / replica.

In my opinion, such debates mostly reflect the political rift that appeared in many Western countries in the recent years. It's completely predictable that they spill into our community. Since they aren't our main focus, we're trying to avoid spending too much time there. But we can't escape the fact that we're making Django first for people writing software, then for computers running that software.

As a community, we chose to state in our Code of Conduct that "we strive to be a community that welcomes and supports people of all backgrounds and identities [including] sexual orientation, gender identity and expression". I believe that the change proposed here is in line with this statement. I know that some community members will feel that we're doing too much here — and that others feel that we aren't doing enough in general — which is why I'm referencing something we already agreed upon.

Best regards,

-- 
Aymeric.



On 26 Jul 2019, at 13:17, 'Mike Hansen' via Django developers (Contributions to Django itself) <[hidden email]> wrote:

Hello all,

Recently I had a member of my team bring up that it was uncomfortable
for them to work in parts of our codebase where they regularly had to
see "blocktrans" in the template files.  To make our work environment
more inclusive, I wrote a Django package which adds "translate" and 
"blocktranslate" templatetag aliases so that we could update our own 
internal templates to use these.

We felt that this change would be in line with the Django community
so I made a ticket and pull request to Django at
https://code.djangoproject.com/ticket/30585 .  The ticket was closed as
"wontfix", and it was mentioned that I should bring it to django-developers
if I wanted to make further progress on the ticket.

Thanks,
--Mike


--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a43ec0ab-f73a-4c11-8fc1-b05d081b24c3%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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/EF4EE680-BBA1-40EB-979E-2671349186D6%40polytechnique.org.


--
Adam

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM2APGm53KYUQoTTPOBBKofUdASCbpWTri%2BeB_XWAszeHQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Translation templatetag aliases

Markus Holtermann
Easy: +1 from me as well for reasons state before.

/Markus

On Sat, Jul 27, 2019, at 6:15 PM, Adam Johnson wrote:

> +1 from me too for the reasons that Aymeric states.
>
> Another small pro: "translate" is a few more characters to type, but it
> should make it easier to understand the purpose of the tags to
> newcomers. "trans" is a prefix used for many words - Wiktionary lists
> 609:
> https://en.wiktionary.org/wiki/Category:English_words_prefixed_with_trans- . I guess quite a few Django apps out there have *some* domain term on this list, so using the full word "translate" can help differentiate the tags from those other concepts.
>
> On Sat, 27 Jul 2019 at 09:51, Aymeric Augustin
> <[hidden email]> wrote:
> > Hello,
> >
> > I'm in favor of adding support for {% translate %} and {% blocktranslate %} and switching the Django documentation to use these for two reasons:
> >
> > - As stated by Mike, the mental associations that "block trans" creates for those who identify as trans are just bad — I can't believe it took us 12 years to notice :-/
> > - Even if we leave that aside, I'm not sure saving 4 characters (8 with the closing tag) is really worth the uncommon abbreviation of "translate".
> >
> > Since this change brings mostly a social benefit rather than a technical benefit, we could keep the {% trans %} and {% blocktrans %} aliases forever. Also, this could minimize arguments between those who recognize the benefits of such changes and those who don't, as we've seen when we changed master / slave to primary / replica.
> >
> > In my opinion, such debates mostly reflect the political rift that appeared in many Western countries in the recent years. It's completely predictable that they spill into our community. Since they aren't our main focus, we're trying to avoid spending too much time there. But we can't escape the fact that we're making Django first for people writing software, then for computers running that software.
> >
> > As a community, we chose to state in our Code of Conduct that "we strive to be a community that welcomes and supports people of all backgrounds and identities [including] sexual orientation, gender identity and expression". I believe that the change proposed here is in line with this statement. I know that some community members will feel that we're doing too much here — and that others feel that we aren't doing enough in general — which is why I'm referencing something we already agreed upon.
> >
> > Best regards,
> >
> > --
> > Aymeric.
> >
> >
> >
> >> On 26 Jul 2019, at 13:17, 'Mike Hansen' via Django developers (Contributions to Django itself) <[hidden email]> wrote:
> >>
> >> Hello all,
> >>
> >> Recently I had a member of my team bring up that it was uncomfortable
> >> for them to work in parts of our codebase where they regularly had to
> >> see "blocktrans" in the template files. To make our work environment
> >> more inclusive, I wrote a Django package <https://pypi.org/project/django-translation-aliases/> which adds "translate" and
> >> "blocktranslate" templatetag aliases so that we could update our own
> >> internal templates to use these.
> >>
> >> We felt that this change would be in line with the Django community
> >> so I made a ticket and pull request to Django at
> >> https://code.djangoproject.com/ticket/30585 . The ticket was closed as
> >> "wontfix", and it was mentioned that I should bring it to django-developers
> >> if I wanted to make further progress on the ticket.
> >>
> >> Thanks,
> >> --Mike
> >>
> >>
> >>  --
> >>  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 [hidden email].
> >>  To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a43ec0ab-f73a-4c11-8fc1-b05d081b24c3%40googlegroups.com <https://groups.google.com/d/msgid/django-developers/a43ec0ab-f73a-4c11-8fc1-b05d081b24c3%40googlegroups.com?utm_medium=email&utm_source=footer>.
> >
>
> >  --
> >  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 [hidden email].
> >  To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/EF4EE680-BBA1-40EB-979E-2671349186D6%40polytechnique.org <https://groups.google.com/d/msgid/django-developers/EF4EE680-BBA1-40EB-979E-2671349186D6%40polytechnique.org?utm_medium=email&utm_source=footer>.
>
>
> --
> Adam
>
>  --
>  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 [hidden email].
>  To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM2APGm53KYUQoTTPOBBKofUdASCbpWTri%2BeB_XWAszeHQ%40mail.gmail.com <https://groups.google.com/d/msgid/django-developers/CAMyDDM2APGm53KYUQoTTPOBBKofUdASCbpWTri%2BeB_XWAszeHQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/be5794fd-8b40-4054-b4d4-37e0fc5fac01%40www.fastmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Translation templatetag aliases

Andrew Godwin-3
I agree too. Let's change it.

Andrew

On Sat, Jul 27, 2019 at 4:03 AM Markus Holtermann <[hidden email]> wrote:
Easy: +1 from me as well for reasons state before.

/Markus

On Sat, Jul 27, 2019, at 6:15 PM, Adam Johnson wrote:
> +1 from me too for the reasons that Aymeric states.
>
> Another small pro: "translate" is a few more characters to type, but it
> should make it easier to understand the purpose of the tags to
> newcomers. "trans" is a prefix used for many words - Wiktionary lists
> 609:
> https://en.wiktionary.org/wiki/Category:English_words_prefixed_with_trans- . I guess quite a few Django apps out there have *some* domain term on this list, so using the full word "translate" can help differentiate the tags from those other concepts.
>
> On Sat, 27 Jul 2019 at 09:51, Aymeric Augustin
> <[hidden email]> wrote:
> > Hello,
> >
> > I'm in favor of adding support for {% translate %} and {% blocktranslate %} and switching the Django documentation to use these for two reasons:
> >
> > - As stated by Mike, the mental associations that "block trans" creates for those who identify as trans are just bad — I can't believe it took us 12 years to notice :-/
> > - Even if we leave that aside, I'm not sure saving 4 characters (8 with the closing tag) is really worth the uncommon abbreviation of "translate".
> >
> > Since this change brings mostly a social benefit rather than a technical benefit, we could keep the {% trans %} and {% blocktrans %} aliases forever. Also, this could minimize arguments between those who recognize the benefits of such changes and those who don't, as we've seen when we changed master / slave to primary / replica.
> >
> > In my opinion, such debates mostly reflect the political rift that appeared in many Western countries in the recent years. It's completely predictable that they spill into our community. Since they aren't our main focus, we're trying to avoid spending too much time there. But we can't escape the fact that we're making Django first for people writing software, then for computers running that software.
> >
> > As a community, we chose to state in our Code of Conduct that "we strive to be a community that welcomes and supports people of all backgrounds and identities [including] sexual orientation, gender identity and expression". I believe that the change proposed here is in line with this statement. I know that some community members will feel that we're doing too much here — and that others feel that we aren't doing enough in general — which is why I'm referencing something we already agreed upon.
> >
> > Best regards,
> >
> > --
> > Aymeric.
> >
> >
> >
> >> On 26 Jul 2019, at 13:17, 'Mike Hansen' via Django developers (Contributions to Django itself) <[hidden email]> wrote:
> >>
> >> Hello all,
> >>
> >> Recently I had a member of my team bring up that it was uncomfortable
> >> for them to work in parts of our codebase where they regularly had to
> >> see "blocktrans" in the template files. To make our work environment
> >> more inclusive, I wrote a Django package <https://pypi.org/project/django-translation-aliases/> which adds "translate" and
> >> "blocktranslate" templatetag aliases so that we could update our own
> >> internal templates to use these.
> >>
> >> We felt that this change would be in line with the Django community
> >> so I made a ticket and pull request to Django at
> >> https://code.djangoproject.com/ticket/30585 . The ticket was closed as
> >> "wontfix", and it was mentioned that I should bring it to django-developers
> >> if I wanted to make further progress on the ticket.
> >>
> >> Thanks,
> >> --Mike
> >>
> >>
> >>  --
> >>  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 [hidden email].
> >>  To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/a43ec0ab-f73a-4c11-8fc1-b05d081b24c3%40googlegroups.com <https://groups.google.com/d/msgid/django-developers/a43ec0ab-f73a-4c11-8fc1-b05d081b24c3%40googlegroups.com?utm_medium=email&utm_source=footer>.
> >
>
> >  --
> >  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 [hidden email].
> >  To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/EF4EE680-BBA1-40EB-979E-2671349186D6%40polytechnique.org <https://groups.google.com/d/msgid/django-developers/EF4EE680-BBA1-40EB-979E-2671349186D6%40polytechnique.org?utm_medium=email&utm_source=footer>.
>
>
> --
> Adam
>
>  --
>  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 [hidden email].
>  To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM2APGm53KYUQoTTPOBBKofUdASCbpWTri%2BeB_XWAszeHQ%40mail.gmail.com <https://groups.google.com/d/msgid/django-developers/CAMyDDM2APGm53KYUQoTTPOBBKofUdASCbpWTri%2BeB_XWAszeHQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/be5794fd-8b40-4054-b4d4-37e0fc5fac01%40www.fastmail.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFwN1uo7ZuT8APmtJUS20VGRHOWNcm%3DrGKze54-KJf%3Dk8ikHKw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Translation templatetag aliases

Florian Apolloner
In reply to this post by Aymeric Augustin
Not opposed to changing it, but would make {% translateblock %} more sense than {% blocktranslate %}?

On Saturday, July 27, 2019 at 10:51:35 AM UTC+2, Aymeric Augustin wrote:
Hello,

I'm in favor of adding support for {% translate %} and {% blocktranslate %} and switching the Django documentation to use these for two reasons:

- As stated by Mike, the mental associations that "block trans" creates for those who identify as trans are just bad — I can't believe it took us 12 years to notice :-/
- Even if we leave that aside, I'm not sure saving 4 characters (8 with the closing tag) is really worth the uncommon abbreviation of "translate".

Since this change brings mostly a social benefit rather than a technical benefit, we could keep the {% trans %} and {% blocktrans %} aliases forever. Also, this could minimize arguments between those who recognize the benefits of such changes and those who don't, as we've seen when we changed master / slave to primary / replica.

In my opinion, such debates mostly reflect the political rift that appeared in many Western countries in the recent years. It's completely predictable that they spill into our community. Since they aren't our main focus, we're trying to avoid spending too much time there. But we can't escape the fact that we're making Django first for people writing software, then for computers running that software.

As a community, we chose to state in our Code of Conduct that "we strive to be a community that welcomes and supports people of all backgrounds and identities [including] sexual orientation, gender identity and expression". I believe that the change proposed here is in line with this statement. I know that some community members will feel that we're doing too much here — and that others feel that we aren't doing enough in general — which is why I'm referencing something we already agreed upon.

Best regards,

-- 
Aymeric.



On 26 Jul 2019, at 13:17, 'Mike Hansen' via Django developers (Contributions to Django itself) <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="7C_zy2dyDwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com> wrote:

Hello all,

Recently I had a member of my team bring up that it was uncomfortable
for them to work in parts of our codebase where they regularly had to
see "blocktrans" in the template files.  To make our work environment
more inclusive, I wrote a <a href="https://pypi.org/project/django-translation-aliases/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fpypi.org%2Fproject%2Fdjango-translation-aliases%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHk_wBoqEM6YWJ8NZxSlLHIYDiIsg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fpypi.org%2Fproject%2Fdjango-translation-aliases%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHk_wBoqEM6YWJ8NZxSlLHIYDiIsg&#39;;return true;">Django package which adds "translate" and 
"blocktranslate" templatetag aliases so that we could update our own 
internal templates to use these.

We felt that this change would be in line with the Django community
so I made a ticket and pull request to Django at
<a href="https://code.djangoproject.com/ticket/30585" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F30585\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHND_uiI5fYhN7DP4RNlalsAYX9uA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fcode.djangoproject.com%2Fticket%2F30585\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHND_uiI5fYhN7DP4RNlalsAYX9uA&#39;;return true;">https://code.djangoproject.com/ticket/30585 .  The ticket was closed as
"wontfix", and it was mentioned that I should bring it to django-developers
if I wanted to make further progress on the ticket.

Thanks,
--Mike


--
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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="7C_zy2dyDwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">django-d...@googlegroups.com.
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/django-developers/a43ec0ab-f73a-4c11-8fc1-b05d081b24c3%40googlegroups.com?utm_medium=email&amp;utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/msgid/django-developers/a43ec0ab-f73a-4c11-8fc1-b05d081b24c3%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/msgid/django-developers/a43ec0ab-f73a-4c11-8fc1-b05d081b24c3%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com/d/msgid/django-developers/a43ec0ab-f73a-4c11-8fc1-b05d081b24c3%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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/bd96c23a-8470-4852-834f-f4824c98964a%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

Re: Translation templatetag aliases

James Bennett
On Sat, Jul 27, 2019 at 11:01 AM Florian Apolloner <[hidden email]> wrote:
Not opposed to changing it, but would make {% translateblock %} more sense than {% blocktranslate %}?

I'm in favor of the change to using the full word "translate". I don't have a strong opinion on which variant to use for the block translate tag; if there's no other reason advanced for picking "translateblock" I'd point out that "blocktranslate" may make life slightly easier for people using autocomplete since it ensures you don't accidentally complete into "translate" when you wanted "translateblock" (or vice versa).

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAL13Cg9HXkXxYAJTi9wyhpstrgTu1aGjUfYpxk8%3D-B9PeUqRdQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: Translation templatetag aliases

1337 Shadow Hacker
If you use autocomplete then typing "{% tr" should propose both translate and translateblock which reduces the chances to pick the wrong one because the other choice did not show up

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/urSZ5VzF46WTsWkxJvj_F7oICyHiV7MWBiCs-amohot3xkiC_abHg0EbbGxrjVkSErJgy73c9TOQa4a7zmQyXEFnEkgqYYqEwZO456k9psU%3D%40protonmail.com.