Re: Fellow Reports - November 2019
Ahh typo, my previous message is about week ending November 24, 2019. -- 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/d00ad5ab-1411-4e6c-9e7a-ff2ed3a1f767%40googlegroups.com.
Re: Fellow Reports - November 2019
Week ending December 1, 2019. *Triaged:* https://code.djangoproject.com/ticket/31029 - Link to more specific sections when using the :rfc: role. (accepted) https://code.djangoproject.com/ticket/31027 - Prefer DOM object properties over Element.getAttribute() and Element.setAttribute(). (accepted) https://code.djangoproject.com/ticket/31018 - Update FAQ about NoSQL databases. (accepted) https://code.djangoproject.com/ticket/31032 - Document the minimal supported version of browsers for the admin. (accepted) https://code.djangoproject.com/ticket/31007 - Make it possible to change the default AutoField to BigAutoField. (wontfix) https://code.djangoproject.com/ticket/31033 - djangoproject documentation search not returning results try searching for forms yields no results. (duplicate) https://code.djangoproject.com/ticket/31036 - Primary key has incorrect default on MySQL. (worksforme) https://code.djangoproject.com/ticket/31037 - Template truncatechars dots missing. (invalid) https://code.djangoproject.com/ticket/31024 - firstof template tag documentation incorrectly specifies value testing. (accepted) https://code.djangoproject.com/ticket/31038 - Prevent collectstatic from trying to access a database. (invalid) https://code.djangoproject.com/ticket/31039 - Support __contained_by lookup for AutoFields and BigAutoFields. (accepted) https://code.djangoproject.com/ticket/31040 - Python 3.9 compatibility (created) https://code.djangoproject.com/ticket/31041 - Custom validation in the clean method triggers before checking the fields exist or not. (invalid) https://code.djangoproject.com/ticket/31042 - Rewrite AdminSeleniumTestCase.get_css_value() without jQuery. (accepted) https://code.djangoproject.com/ticket/31021 - 0011_update_proxy_permissions crashes in multi database environment. (accepted) https://code.djangoproject.com/ticket/31043 - Form with ModelChoiceField and disabled failed when the initial is model instance. (duplicate) https://code.djangoproject.com/ticket/31044 - Prefetch() assumes that a given queryset has an _iterable_class. (accepted) https://code.djangoproject.com/ticket/31047 - Empty models.TextField being incorrectly saved as empty string (duplicate) *Reviewed/committed:* https://github.com/django/django/pull/12126 - Fixed #28469 -- Doc'd how to create a custom HttpResponse subclass. https://github.com/django/django/pull/12127 - Fixed #31025 -- Fixed highlightlinenothreshold deprecation warning on Sphinx 1.8+. https://github.com/django/django/pull/12125 - Fixed #27914 -- Fixed serialization of nested classes in migrations. https://github.com/django/django/pull/12136 - Fixed #31002 -- Fixed GIS lookups crash against a subquery annotation. https://github.com/django/django/pull/12118 - Fixed #31013 -- Removed jQuery usage in SelectBox.js. https://github.com/django/django/pull/12143 - Fixed #31031 -- Fixed data loss in admin changelist view when formset's prefix contains regex special chars. https://github.com/django/django/pull/12130 - Improved custom MultiWidget example in docs. https://github.com/django/django/pull/12138 - Fixed #31027 -- Replaced .getAttribute()/.setAttribute() usage with DOM properties. https://github.com/django/django/pull/12141 - Fixed #30803 -- Allowed comma separators for milliseconds in django.utils.dateparse functions. https://github.com/django/django/pull/12087 - Fixed #30425 -- Handled jinja2.TemplateSyntaxError when rendering a template. https://github.com/django/django/pull/12142 - Fixed #31029 -- Used more specific links to RFCs. https://github.com/django/django/pull/12155 - Fixed #30255 -- Fixed admindocs errors when rendering docstrings without leading newlines. *Reviewed:* https://github.com/django/django/pull/12152 - Fixed #29892 -- Added explicit Selenium wait in admin autocomplete test. *Authored:* https://github.com/django/django/pull/12144 - Fixed #31018 -- Removed django-nonrel in NoSQL databases FAQ. https://github.com/django/django/pull/12153 - Fixed #31021 -- Fixed proxy model permissions data migration crash with a multiple databases setup. https://github.com/django/django/pull/12154 - Fixed #30953 -- Made select_for_update() lock only queryset's model when using "self" with multi-table inheritance. Best regards, Mariusz > -- 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/b27257dc-ec60-4ebc-a3f2-1ae641e089d0%40googlegroups.com.
Getting new migrations if booleanfield is set blank=True in django 2.1+
As document says, https://docs.djangoproject.com/en/2.2/ref/models/fields/#booleanfield previously blank=True was implicit but in django 2.1+ , we have to add it externally. So i dont understand why new migrations are coming up for this? Does this mean that previously blank=True wasnt considered for the migrations? -- 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/0b5349ba-cff0-4c5b-95f7-2eed6f5a4cf1%40googlegroups.com.
Re: ngettext_lazy and ngettext
Hi,
I am wondering if Django shouldn't use Unicode Plural Rules as standard and
promote it for third-party apps. Even if sometimes number of forms are not
applicable to certain cases, there may be cases when all of forms will be
needed.
Especially if implementing having different plural rules for various apps
is not trivial.
For the record, here is a section of Transifex documentation that describes
their statement about plural rules and Unicode standard:
https://docs.transifex.com/localization-tips-workflows/plurals-and-genders#how-pluralized-strings-are-handled-by-transifex
.
Regards,
Maciej
czw., 5 gru 2019 o 08:00 Matemática A3K
napisał(a):
> While testing the "not-merging" policy, I got this:
> https://pastebin.com/ihyAiYtc
> Those warnings should get to the Translators teams if they are not looking
> here, i.e.
>
> https://github.com/django/django/blob/master/django/contrib/sessions/locale/he/LC_MESSAGES/django.po
> is still using a 2-plurals form in a 4 plural form - it doesn't matter in
> this case because there are no translations with plurals, but they trigger
> the warning because the pf hasn't been updated and they should if the
> Transifex front-end use the pf of a file for showing the options for
> translating and to be inline with the main form.
>
>
> On Thu, Dec 5, 2019 at 12:10 AM Matemática A3K
> wrote:
>
>>
>>
>> On Wed, Dec 4, 2019 at 2:25 AM Claude Paroz wrote:
>>
>>> Le mercredi 4 décembre 2019 03:41:51 UTC+1, Matemática A3K a écrit :
(...)
But, then I realized that there is major caveat on this approach, and
that is that updates on the plural equation won't reach users' catalogs,
because their catalogs will be kept separately one the plural form differs.
This would be the case that Shai pointed on Django 2.2 with the incorrect
plural equation for HE. People who have generated their catalogs with
makemessages on 2.2 will have a wrong plural equation, that once it is
fixed on a new release, it won't reach their catalogs because they will be
kept apart.
>>>
>>> Sorry, I'm not following you here. The catalog merge process is
>>> happening in realtime when Django starts, so any po file update is
>>> instantly reflected in the translation infrastructure. I don't see any
>>> caveat here.
>>>
>>
>> Yes, but only for the default language, the rest are lazily loaded on
>> demand - this is why I think it is better do the check at a system level,
>> if you have more than a language available, the others will be merged for
>> loading them once something triggers it (like an
>> "activate("LANGUAGE_CODE")) and only there you would start to see the
>> warnings.
>>
>> For the example of the caveat of the dict-merging, it would be like this:
>>
>> - Someone starts its translation with Django 2.2 for Hebrew via
>> makemessages, which copies the main plural form to the new file, and fills
>> the translations.
>> - The user upgrades to Django 2.2.x or up, which contains a fixed plural
>> form for Hebrew
>> - Under the "dict-merge" policy, the Django translation catalog would
>> have 2 entries, one for the main plural form (the new one) and other the
>> catalog generated in the past (the user's one).
>>
>> Strings in the user catalog would use a "worse" plural equation, while
>> strings in the Django catalog will use the better one. Updates won't reach
>> to users' catalogs, unless they explicitly update them, because once the
>> user's po is created, makemessages won't update the header, it will do a
>> msgmerge (
>> https://github.com/django/django/blob/master/django/core/management/commands/makemessages.py#L603
>> ).
>>
>> That's why something like "makemessages --update-plural-form" and a
>> warning about different plurals forms in the catalog would be needed, even
>> under "dict-merge".
>>
>> With the current "merge" policy, because only the main form used, the
>> users would get the update but they won't be able to have parts of the
>> catalog under a different pf.
>>
>> The way to have a different plural form than the main one with the
>> current code base would be by having a custom variant of the language
>> (which implements "the spirit of dict-merge": independent catalogs with an
>> order of precedence). It's not ideal, you will loose the ability of using
>> the browser's locale config to display the language out of the box unless
>> you add extra code to handle it, something like "if locale == 'he': use
>> 'he_SP'" (no other caveat comes to my mind). But it would be they way of
>> having it RN without loosing the updates.
>>
>>
>>>
>>> Claude
>>>
>>> --
>>> 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-developer
Re: ngettext_lazy and ngettext
On Thu, Dec 5, 2019 at 4:23 PM Maciek Olko wrote:
> Hi,
> I am wondering if Django shouldn't use Unicode Plural Rules as standard
> and promote it for third-party apps. Even if sometimes number of forms are
> not applicable to certain cases, there may be cases when all of forms will
> be needed.
>
I agree for Django, for third-party translations, for what I understood
(CIIW) this may be a differentiator
>
> Especially if implementing having different plural rules for various apps
> is not trivial.
>
> For the record, here is a section of Transifex documentation that
> describes their statement about plural rules and Unicode standard:
> https://docs.transifex.com/localization-tips-workflows/plurals-and-genders#how-pluralized-strings-are-handled-by-transifex
> .
>
> Regards,
> Maciej
>
> czw., 5 gru 2019 o 08:00 Matemática A3K
> napisał(a):
>
>> While testing the "not-merging" policy, I got this:
>> https://pastebin.com/ihyAiYtc
>> Those warnings should get to the Translators teams if they are not
>> looking here, i.e.
>>
>> https://github.com/django/django/blob/master/django/contrib/sessions/locale/he/LC_MESSAGES/django.po
>> is still using a 2-plurals form in a 4 plural form - it doesn't matter in
>> this case because there are no translations with plurals, but they trigger
>> the warning because the pf hasn't been updated and they should if the
>> Transifex front-end use the pf of a file for showing the options for
>> translating and to be inline with the main form.
>>
>>
>> On Thu, Dec 5, 2019 at 12:10 AM Matemática A3K
>> wrote:
>>
>>>
>>>
>>> On Wed, Dec 4, 2019 at 2:25 AM Claude Paroz wrote:
>>>
Le mercredi 4 décembre 2019 03:41:51 UTC+1, Matemática A3K a écrit :
>
> (...)
>
> But, then I realized that there is major caveat on this approach, and
> that is that updates on the plural equation won't reach users' catalogs,
> because their catalogs will be kept separately one the plural form
> differs.
> This would be the case that Shai pointed on Django 2.2 with the incorrect
> plural equation for HE. People who have generated their catalogs with
> makemessages on 2.2 will have a wrong plural equation, that once it is
> fixed on a new release, it won't reach their catalogs because they will be
> kept apart.
>
Sorry, I'm not following you here. The catalog merge process is
happening in realtime when Django starts, so any po file update is
instantly reflected in the translation infrastructure. I don't see any
caveat here.
>>>
>>> Yes, but only for the default language, the rest are lazily loaded on
>>> demand - this is why I think it is better do the check at a system level,
>>> if you have more than a language available, the others will be merged for
>>> loading them once something triggers it (like an
>>> "activate("LANGUAGE_CODE")) and only there you would start to see the
>>> warnings.
>>>
>>> For the example of the caveat of the dict-merging, it would be like this:
>>>
>>> - Someone starts its translation with Django 2.2 for Hebrew via
>>> makemessages, which copies the main plural form to the new file, and fills
>>> the translations.
>>> - The user upgrades to Django 2.2.x or up, which contains a fixed plural
>>> form for Hebrew
>>> - Under the "dict-merge" policy, the Django translation catalog would
>>> have 2 entries, one for the main plural form (the new one) and other the
>>> catalog generated in the past (the user's one).
>>>
>>> Strings in the user catalog would use a "worse" plural equation, while
>>> strings in the Django catalog will use the better one. Updates won't reach
>>> to users' catalogs, unless they explicitly update them, because once the
>>> user's po is created, makemessages won't update the header, it will do a
>>> msgmerge (
>>> https://github.com/django/django/blob/master/django/core/management/commands/makemessages.py#L603
>>> ).
>>>
>>> That's why something like "makemessages --update-plural-form" and a
>>> warning about different plurals forms in the catalog would be needed, even
>>> under "dict-merge".
>>>
>>> With the current "merge" policy, because only the main form used, the
>>> users would get the update but they won't be able to have parts of the
>>> catalog under a different pf.
>>>
>>> The way to have a different plural form than the main one with the
>>> current code base would be by having a custom variant of the language
>>> (which implements "the spirit of dict-merge": independent catalogs with an
>>> order of precedence). It's not ideal, you will loose the ability of using
>>> the browser's locale config to display the language out of the box unless
>>> you add extra code to handle it, something like "if locale == 'he': use
>>> 'he_SP'" (no other caveat comes to my mind). But it would be they way of
>>> having it RN without loosing the updates.
>>>
>>>
Claude
--
You received this message because you are subscribed to the Google
Groups "
