Re: Improving MSSQL and Azure SQL support on Django

[Tim Allen]

Hi Sean, just an update from what I know.

We are still waiting for a reply from Microsoft. They're a large company, 
so understandably, it takes a little while.


For now, if people need to get onto Django 2.2 for long term support (which 
will last until April, 2022), you can use this package:

https://github.com/ESSolutions/django-mssql-backend I've been running it in 
production for months without incident. Of course, YMMV.


If Microsoft and/or the DSF end up wanting to bring support under the 
Django umbrella, the django-mssql-backend repository is a possible starting 
point, IMHO.

The django-mssql-backend is currently being developed and support for 
Django 3.0 is being worked on: ESSolutions/django-mssql-backend#18 



Regards,


Tim

On Monday, December 2, 2019 at 11:03:56 AM UTC-5, Sean Martz wrote:
>
> Hello,
>
> It seems like this issue has lost momentum. Is this still something that's 
> on anyones radar? It looks like django-pyodbc-azure is not actively 
> maintained anymore (it looks like Michaya has taken a hiatus from GitHub). 
> It also looks like there's a small community potentially popping up that's 
> interested in first class MSSQL Server support for Django. (
> https://github.com/FlipperPA/django-mssql-backend). Is Microsoft still 
> interested in committing resources to this goal? In my situation, it would 
> be a lot easier to sell stakeholders and decision makers on Django if it 
> had first class support for MSSQL Server.
>
> For what it's worth, Django-pyodbc-azure is still working well.
>
> Cheers,
> Sean
>
>

-- 
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/3683f606-ad18-4935-85c8-8ca3ea18fecc%40googlegroups.com.

Re: Let Django users customize FORMAT_SETTINGS (a feature request)

[Carlton Gibson]

Hi Uri. 

On Tuesday, 3 December 2019 04:27:03 UTC+1, Uri wrote:
>
> I want to use YEAR_FORMAT in the template the same why I'm 
> using DATE_FORMAT and MONTH_DAY_FORMAT:
>

> And to be able to customize YEAR_FORMAT for specific locales if it needs 
> to be customized. But not to define it if it's equal to the default value 
> which I defined
>

Right, with you. (Sorry, it takes a while to get clear sometimes.) 

Does Custom Format Files do it?
>

Yes — all except the default right? — IIUC You can define whatever formats 
you want in format.py files, and that'll all work how you want 
*BUT* (unless all your languages were in the same family, en-us, en-gb say, 
which are both en) it doesn't "fallback" the default locale, 
so you can't set a default. 

With two locales I guess it'd be OK, but with 40... 

*So here's my question then (all)*: With translations we fallback to the 
default locale. Should it be the case that 
django.utils.formats.iter_format_modules()
also fallbacks to the default locale? (As it doesn't look like it does 
currently.) (By appending that to the list of modules to search.)

i.e. is this a bug (or new feature) in format localization that we could 
patch, within the existing machinery, rather than adding a setting, or 
needing to go via the global settings file?

(A test case for that new behaviour and a patch, assuming nothing breaks, 
might swing that, pending lack of responses...)

I'm going to try to implement the patch on Speedy Net right now without 
> having to update 14 files. There is a suggestion on Stack Overflow.
>

Yes, in the meantime your patch applied in an AppConfig looks my cleaner. 
:+1: 

Kind Regards,

Carlton

-- 
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/c503f8e4-66bd-49d0-92f9-c8f2d5e5f6f6%40googlegroups.com.

Re: ngettext_lazy and ngettext

[Matemática A3K]

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-developers/5f2bf52a-997c-467d-b927-f2959507d32e%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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CA%2BFDnhJ74X_D-1A9bMGaOdNLxEndn-ZVeu-LT3nbarxgbTT9Wg%40mail.gmail.com.

Re: ngettext_lazy and ngettext

[Matemática A3K]

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-developers/5f2bf52a-997c-467d-b927-f2959507d32e%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 django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CA%2BFDnhKtEB4sgUFwmyaExGLSnMU5yLkj0QZ1ubpF2gaRjBd1EQ%40mail.gmail.com.