Re: Making the admin more navigable

[Tom Carrick]

I've added a PR here https://github.com/django/django/pull/12159

I'd appreciate if someone can give it a look, it's been a while since I've 
done any front end dev so there are probably nicer ways to do it.

I'm also getting a test failure, and I don't quite understand how my code 
could have caused it, so would also appreciate some help debugging that if 
it's possible.

Cheers,
Tom

On Sunday, November 24, 2019 at 11:20:39 PM UTC+1, Tobias Kunze wrote:
>
> On 19-11-24 10:29:36, Tom Carrick wrote: 
> >1. Is this something people actually want, or is it just me? 
>
> +1, especially with a flag to disable it. Thank you for taking this up! 
>
> We live in the days of wide screens, where using the screen for something 
> meaningful is definitely a good idea. I find it tedious to always click 
> back 
> to the start of admin pages to then select another category/model. 
>
> >2. How is the navigation best done? Since some projects can be very 
> large, 
> >I'm partial to something vertical, rather than horizontal, so a sidebar 
> >seems good. What the best UX is on smaller screens would be I'm a little 
> >less sure. 
>
> For the beginning, you can just hide the sidebar on smaller screens. They 
> won't lose any functionality, and users on larger screens will still 
> profit. 
>
> Later on, you can consider having a navigation hidden behind some menu 
> button, 
> to be shown when tapped, but I don't think that's required. 
>
> >3. Should we provide an API for adding more links? I guess we could have 
> >some overridable structure, perhaps in the form of `{"category": 
> ["link1", 
> >"link2", ...], ...}` 
>
> I'd say for the beginning the sidebar should show the links the admin home 
> page shows, so adding a link to one would also add it to the other. 
>
> In a second step we can distinguish between the two (and also figure out 
> if a 
> link should be shown as "active" in the sidebar.) 
>
> >5. Would this make the admin home page redundant, and if so should we 
> >replace it with something, and what should that something be? 
>
> I don't think the main admin page would be redundant or should be 
> replaced. 
> It'd still be used for mobile pages/smaller screens, at the very least, 
> and 
> changing the main site is also a major/breaking modification. Adding a 
> sidebar, especially with an option to disable it, won't hurt in upgrades 
> generally, but losing/changing home page functionality would be painful. 
>
> Tobias 
>

-- 
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/076ce57b-2e8d-4144-981d-b6d7724796db%40googlegroups.com.

Re: new to open source contribution

[Himanshu Mohan]

Hi,
I tried sending in below email group and it’s coming as Undelivered  

Thanks and Regards
Himanshu

> On 02-Dec-2019, at 11:48 PM, Carlos Leite (cadu)  wrote:
> 
> Hi Satish, 
> 
> there is a list just for that :  django-core-mentors...@googlegroups.com
> 
> ask anything about start to contributing to django , people are there for it. 
> You will be welcome 
> 
> Em sexta-feira, 29 de novembro de 2019 09:41:13 UTC-3, Shruti Satish escreveu:
>> 
>> i am new to open source and would like to contribute.
>> 
>> how do i setup for Django development?
>> 
>> also can i be pointed towards easy and relativey easy bug fixes/issues and 
>> the corresponding repos?
> 
> -- 
> 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/02040b6a-2fcf-47c2-a55c-44f7f93f25c7%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/A89BDF58-87CC-471E-B6B7-805255DE8D01%40gmail.com.

Re: ngettext_lazy and ngettext

[Matemática A3K]

OK, I made some progress on the quest of solving this issue :)

While I was implementing the "not-merge-catalog-if-plural-form-differs"
policy, I realized that it would be cumbersome for the users to adapt to
the new situation if no additional tools are provided. I switch to a
Documentation Driven Development approach to have a better picture of all
the needs, and here is what I wrote:

.. _plural-forms:

Plural Forms


Django does not support custom plural forms in po files. As all translation
catalogs are merged, only the plural form in the main Django po file
(located in
``django/conf/locale//LC_MESSAGES/django.po``) is considered.

Plural forms in all other po files are ignored by the GNU gettext merging
process.

Therefore, you shouldn't use different plural forms in your project or
application
po files, as it may lead to unexpected results.

To prevent inconsistencies and undesired behaviors in translations, Django
will
not merge any catalog that contains a different plural form than the main
one
and will issue a warning about the conflicting catalog.

The warning will show both plural forms (the main and the conflicting one)
so
you can decide which one is to be used.

This conflict may arise mostly in two situations:

* when the main plural form for a language is updated
in Django and your po files were generated with a previous one, or
* when including third-party translations with a different plural form.

There are two aspects of the plural form to be considered: the number of
plural forms (``nplurals``) and the plural equation (``plural=``).

For the number of plurals, Django follows the standards provided by `Unicode
<
http://www.unicode.org/cldr/charts/latest/supplemental/language_plural_rules.html
>`_.

In the case of an increase in the number of plurals for a language, you will
have to provide with more translations in your po files to comply with the
updated language definition (it is considered an API change, noted in the
Release Notes and unusual).

For this, you may use
djadmin:`django-admin makemessages --comply-plurals` to fill
the missing plurals from your projects' catalogs with the previous ones so
you avoid having translation results in the fallback language or the
original
string - this will produce the same results as before though you
may want to update those later for a better expression of the language if it
corresponds.

If you do not want to comply with the new language definition, you can
create
a variant for the language with less plural forms, i.e. ``he_SP`` for
"Hebrew
(Simplified)" with 2 plural forms and ``he`` with 4 variants acting as a
fallback (see :ref:`how-django-discovers-translations`). Note that your
variant would need to be explicitly set by Django, or in the url, or by your
front-end, as browsers won't know about it.

For the plural equation (the way of determining which form will be used),
given a number of plurals, *one will be an improvement over the other* - as
it is assumed that there is one plural equation that can describe correctly
all the plurals' cases of a language.

Note that the order of the forms can vary depending on the equation, i.e.
the cases for the second plural form in one equation may refer to the third
one in another.

Once you decided which one is better, there are two aspects to consider for
resolving this conflict: updating the plural forms of your project's
catalogs
or update the ones in Django's base catalogs.

For aligning your project's catalogs' plural forms with the main one (most
common case after a Django upgrade), use
djadmin:`django-admin makemessages --update-plural-form`. This
will make your catalogs mergeable again with Django's.

After this, djadmin:`compile the messages as usual` and
you'll be ready to go.

If you choose to use the version different than Django's, edit the main
Django po file and then run:

* djadmin:`django-admin makemessages --update-plural-form --base
LC`
to propagate the change to all catalogs bundled with Django, and then
* djadmin:`django-admin compilemessages --base LC` to
compile
them.

This will align all the Django's catalogs with your plural equation. If so,
`consider submiting your plural equation as an improvement to Django in a
ticket
`_.

.. versionchanged:: 3.1

Handling plural forms as described above was added.

It's not to complicated, but not slick at all... not every user may
like to take the time to understand the plural form of the catalogs,
although I think for most cases, it will be issuing a "makemessages
--update-plural-form".

This led me evaluate again the Claude proposal of having a dict with the
plural form as keys and merge the catalogs there. This had the main problem
of no clear resolution if overlapping, but then I realized that if an
ordered dict is used, then the merging order can be somehow retained, and
for most cases, it will be sufficient to reproduce the precedence order
that Django has actually (pr

Re: ngettext_lazy and ngettext

[Claude Paroz]

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.

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.