Re: Current I18n strategy seems awfully fragile

2017-11-02 Thread Steve Jorgensen 
Thanks very much for sharing this detail and those links. Very informative. 
:)

On Thursday, November 2, 2017 at 6:19:30 AM UTC-7, Jani Tiainen wrote:
>
> Hi,
>
> This is how things are done with gettext [1] in general and Django (and 
> pretty much it's whole ecosystem) just has adopted that convention.
>
> Having abstract keys instead of plain English isn't problem free either, 
> they just have a different problems. 
> Note that you can have Django gettext contextual markers to avoid 
> translation collisions in your translations. [2]
>
> 1. 
> https://www.gnu.org/software/gettext/manual/html_node/Preparing-Strings.html#Preparing-Strings
> 2. 
> https://docs.djangoproject.com/en/1.11/topics/i18n/translation/#contextual-markers
>
> On 2.11.2017 12.45, Steve Jorgensen wrote:
>
> Well, convention or not, can you see why that is a ridiculously fragile 
> convention? From what you're saying, this is how things are done in 
> Django-land though, so it would be awkward for DRF to do something 
> different. Poop. :(
>
> On Wednesday, November 1, 2017 at 11:16:26 PM UTC-7, Jani Tiainen wrote: 
>>
>> Hi, 
>>
>> Django and DRF both uses GNU gettext to handle translations. With gettext 
>> it's convention is to use plain English "message id" instead of what Ruby 
>> does. 
>>
>> Ruby seems to have it's own translation mechanisms which is tailored to 
>> be used with abstract message id's.
>>
>> 2.11.2017 2.23 "Steve Jorgensen"  kirjoitti:
>>
>>> Looking at 
>>> http://www.django-rest-framework.org/topics/internationalization/ and 
>>> https://raw.githubusercontent.com/encode/django-rest-framework/master/rest_framework/locale/en_US/LC_MESSAGES/django.po
>>>  
>>>
>>> I see that each msgid value is a full English language message. That 
>>> means that if an application has its own translation(s) for DRF's intrinsic 
>>> messages, they can break if the wording of the messages changes from one 
>>> DRF to the next.
>>> I come from the Rails world where the IDs are symbols that do not 
>>> change, and the actual text for the message in any language is determined 
>>> through I18n.
>>> Is there some way this could be improved in future versions of DRF?
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Django REST framework" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to django-rest-framework+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-rest-framework+unsubscr...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
> -- 
> Jani Tiainen
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Current I18n strategy seems awfully fragile

2017-11-02 Thread Jani Tiainen 

Hi,

This is how things are done with gettext [1] in general and Django (and 
pretty much it's whole ecosystem) just has adopted that convention.


Having abstract keys instead of plain English isn't problem free either, 
they just have a different problems.


Note that you can have Django gettext contextual markers to avoid 
translation collisions in your translations. [2]


1. 
https://www.gnu.org/software/gettext/manual/html_node/Preparing-Strings.html#Preparing-Strings
2. 
https://docs.djangoproject.com/en/1.11/topics/i18n/translation/#contextual-markers


On 2.11.2017 12.45, Steve Jorgensen wrote:
Well, convention or not, can you see why that is a ridiculously 
fragile convention? From what you're saying, this is how things are 
done in Django-land though, so it would be awkward for DRF to do 
something different. Poop. :(


On Wednesday, November 1, 2017 at 11:16:26 PM UTC-7, Jani Tiainen wrote:

Hi,

Django and DRF both uses GNU gettext to handle translations. With
gettext it's convention is to use plain English "message id"
instead of what Ruby does.

Ruby seems to have it's own translation mechanisms which is
tailored to be used with abstract message id's.

2.11.2017 2.23 "Steve Jorgensen" >
kirjoitti:

Looking at
http://www.django-rest-framework.org/topics/internationalization/

and

https://raw.githubusercontent.com/encode/django-rest-framework/master/rest_framework/locale/en_US/LC_MESSAGES/django.po




I see that each msgid value is a full English language
message. That means that if an application has its own
translation(s) for DRF's intrinsic messages, they can break if
the wording of the messages changes from one DRF to the next.
I come from the Rails world where the IDs are symbols that do
not change, and the actual text for the message in any
language is determined through I18n.
Is there some way this could be improved in future versions of
DRF?
-- 
You received this message because you are subscribed to the

Google Groups "Django REST framework" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to
django-rest-framework+unsubscr...@googlegroups.com .
For more options, visit https://groups.google.com/d/optout
.

--
You received this message because you are subscribed to the Google 
Groups "Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to django-rest-framework+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
Jani Tiainen

--
You received this message because you are subscribed to the Google Groups "Django 
REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Current I18n strategy seems awfully fragile

2017-11-02 Thread Steve Jorgensen 
Well, convention or not, can you see why that is a ridiculously fragile 
convention? From what you're saying, this is how things are done in 
Django-land though, so it would be awkward for DRF to do something 
different. Poop. :(

On Wednesday, November 1, 2017 at 11:16:26 PM UTC-7, Jani Tiainen wrote:
>
> Hi,
>
> Django and DRF both uses GNU gettext to handle translations. With gettext 
> it's convention is to use plain English "message id" instead of what Ruby 
> does. 
>
> Ruby seems to have it's own translation mechanisms which is tailored to be 
> used with abstract message id's.
>
> 2.11.2017 2.23 "Steve Jorgensen" > 
> kirjoitti:
>
>> Looking at 
>> http://www.django-rest-framework.org/topics/internationalization/ and 
>> https://raw.githubusercontent.com/encode/django-rest-framework/master/rest_framework/locale/en_US/LC_MESSAGES/django.po
>>
>> I see that each msgid value is a full English language message. That 
>> means that if an application has its own translation(s) for DRF's intrinsic 
>> messages, they can break if the wording of the messages changes from one 
>> DRF to the next.
>>
>> I come from the Rails world where the IDs are symbols that do not change, 
>> and the actual text for the message in any language is determined through 
>> I18n.
>>
>> Is there some way this could be improved in future versions of DRF?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django REST framework" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-rest-framework+unsubscr...@googlegroups.com 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Current I18n strategy seems awfully fragile

2017-11-01 Thread Jani Tiainen 
Hi,

Django and DRF both uses GNU gettext to handle translations. With gettext
it's convention is to use plain English "message id" instead of what Ruby
does.

Ruby seems to have it's own translation mechanisms which is tailored to be
used with abstract message id's.

2.11.2017 2.23 "Steve Jorgensen"  kirjoitti:

> Looking at http://www.django-rest-framework.org/topics/
> internationalization/ and https://raw.githubusercontent.com/encode/
> django-rest-framework/master/rest_framework/locale/en_US/
> LC_MESSAGES/django.po
>
> I see that each msgid value is a full English language message. That
> means that if an application has its own translation(s) for DRF's intrinsic
> messages, they can break if the wording of the messages changes from one
> DRF to the next.
>
> I come from the Rails world where the IDs are symbols that do not change,
> and the actual text for the message in any language is determined through
> I18n.
>
> Is there some way this could be improved in future versions of DRF?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django REST framework" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-rest-framework+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Current I18n strategy seems awfully fragile

2017-11-01 Thread Steve Jorgensen 
Looking 
at http://www.django-rest-framework.org/topics/internationalization/ 
and 
https://raw.githubusercontent.com/encode/django-rest-framework/master/rest_framework/locale/en_US/LC_MESSAGES/django.po

I see that each msgid value is a full English language message. That means 
that if an application has its own translation(s) for DRF's intrinsic 
messages, they can break if the wording of the messages changes from one 
DRF to the next.

I come from the Rails world where the IDs are symbols that do not change, 
and the actual text for the message in any language is determined through 
I18n.

Is there some way this could be improved in future versions of DRF?

-- 
You received this message because you are subscribed to the Google Groups 
"Django REST framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-rest-framework+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.