Re: 1.2 Feature Suggestion

[Russell Keith-Magee]

On Mon, Oct 26, 2009 at 9:40 AM, James Bennett  wrote:
>
> On Sun, Oct 25, 2009 at 8:30 PM, Russell Keith-Magee
>  wrote:
>> A wiki page doesn't really solve the problem either. If you make it an
>> exclusive list, someone has to decide who is on the list and who
>> isn't. If you make it a comprehensive list, a wiki page will very
>> rapidly become unusable due to the volume of reusable apps out there -
>> wiki format doesn't provide a lot of creative options for
>> indexing/organizing content on multiple axes.
>
> It seems to me that there's already a site out there which indexes and
> organizes on multiple axes:
>
> http://pypi.python.org/pypi?:action=browse=523
>
> or just lists Django stuff:
>
> http://pypi.python.org/pypi?:action=browse=all=523
>
> (several of my comments on proposed contrib additions for 1.2 pointed
> this out -- we already have the infrastructure, now let's encourage
> people to use it)

I agree that PyPI solves *part* of the problem - in particular, the
automated installation aspects of the problem. However, IMHO PyPI
really blows as a resource discovery tool - because the axes it
provides and indexes aren't really useful axes for the problem that
needs solving.

A use-case driven example:

I am a new user to Django. I am building a website that will require a
member signup process. Is there a Django app that will help me with
this?

"django member signup" returns (as far as I can make out) every single
PyPI registration that mentions "django". This is not a good starting
point.

If you're willing to filter through hundred of results to find the
nuggets of goodness, you will discover (in this order)
django-invitation, django-social-registration, django-account,
django-invite, and django-registration. There may be other packages
that are appropriate, but the search results don't provide any easy
way to filter these out. The search results also include entries that
are Zope and Plone specific.

Which one of these projects should I look at first? Which ones do the
community consider to be good applications? I don't think it's too
controversial to say that there would be a reasonable consensus that
django-registration is a pretty good example of a Django reusable app,
but it's the last result in list. The other candidates may also be
good, but if a new user came to me and asked this question, I know I
would be pointing them at django-registration first.

So - PyPI provides an excellent machine-readable index for PIP to use,
but it is missing two important features for it to be useful as a
community tool:

 * No web application specific metadata in the trove classifiers
 * No social contribution to help filter the wheat from the chaff

As allegorical evidence in support of my claims - I can't remember the
last time I used PyPI as a search tool to find a Python package (I'm
not talking Django-specific, either - I mean Python packages in
general). It's great resource for pip to use, but awful for people
IMHO.

The trove classifiers are a particular problem, IMHO. They are a
static list that borders on comical in their scope. Trove provides a
classifier to say that your project is compatible with GNU Hurd, but
doesn't provide classifiers that are useful in a web context, like
"member signup", "voting", "tagging", or "caching". It provides a
classifier for "SCCS" and "RCS", but not for "Mercurial" or "git".
Trove lets you easily find a list of 306 Django packages, but provides
very little help to narrow the search any further based on the task
you want to perform - and as far as I can make out, you can't do a
search inside a trove classifier.

Related to this - there is no synonym suggestion around these trove
classifiers. Is it "member signup" or "member registration" or just
"registration"? To be sure - this isn't an easy problem to solve, but
as far as I can make out PyPI make no attempt to solve it at all.

One solution here might be to work with the Python core guys to
improve PyPI. The other solution is to build a Django-specific social
layer that leverages the machine-readable data in PyPI, but provides
the extra features that PyPI is missing.

I'm open to either option, but my gut feeling is that the latter will
be much easier to execute, if only because we won't have to deal with:
 1) Wrangling a community much larger than our own
 2) Fighting "No, can't let Django control the agenda" Python community angst
 3) Trying to satisfy use cases that are of no importance to Django,
but might be important to other communities.

I would also note that I'm also not entirely convinced that it is
right for PyPI to evolve beyond being a simple machine-readable index.
I strongly suspect the social needs of the Django community will be
quite different to those in the Pylons or Zope communities - or those
in NLP, bioinformatics, or any other domains where Python is used. A
caching tool that is a good match for Django may not be a good match
for 

Re: 1.2 Feature Suggestion

[James Bennett]

On Sun, Oct 25, 2009 at 8:30 PM, Russell Keith-Magee
 wrote:
> A wiki page doesn't really solve the problem either. If you make it an
> exclusive list, someone has to decide who is on the list and who
> isn't. If you make it a comprehensive list, a wiki page will very
> rapidly become unusable due to the volume of reusable apps out there -
> wiki format doesn't provide a lot of creative options for
> indexing/organizing content on multiple axes.

It seems to me that there's already a site out there which indexes and
organizes on multiple axes:

http://pypi.python.org/pypi?:action=browse=523

or just lists Django stuff:

http://pypi.python.org/pypi?:action=browse=all=523

(several of my comments on proposed contrib additions for 1.2 pointed
this out -- we already have the infrastructure, now let's encourage
people to use it)

-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 1.2 Feature Suggestion

[Joshua Russo]

On Mon, Oct 26, 2009 at 12:30 AM, Russell Keith-Magee <
freakboy3...@gmail.com> wrote:

>
> A wiki page doesn't really solve the problem either. If you make it an
> exclusive list, someone has to decide who is on the list and who
> isn't. If you make it a comprehensive list, a wiki page will very
> rapidly become unusable due to the volume of reusable apps out there -
> wiki format doesn't provide a lot of creative options for
> indexing/organizing content on multiple axes.


That's a good point. You really do need a better way to manage a list of
that size. A wiki page is better used for less dynamic lists and
information.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 1.2 Feature Suggestion

[Russell Keith-Magee]

On Mon, Oct 26, 2009 at 8:32 AM, Tobias McNulty  wrote:
> On Sun, Oct 25, 2009 at 7:39 PM, Dan  wrote:
>>
>> I didn't know about rosetta. What would you guys think of having a doc
>> section about popular third party apps?

Putting a list of applications really isn't the right solution - for
one thing, the list of available applications changes much faster than
Django does. Secondly, the core team doesn't want to get into the
business of officially blessing certain applications.

A wiki page doesn't really solve the problem either. If you make it an
exclusive list, someone has to decide who is on the list and who
isn't. If you make it a comprehensive list, a wiki page will very
rapidly become unusable due to the volume of reusable apps out there -
wiki format doesn't provide a lot of creative options for
indexing/organizing content on multiple axes.

> I think this is best done through a third party site.  Look at the success
> of DjangoGigs.  I don't know that there's a de facto place to look for apps
> yet, but I bet a winner will emerge in time.

I agree - and for those that aren't aware of the options out there,
I'm aware of at least 3 sites that already do this:

http://djangozen.com/
http://djangoworld.com/
http://django-apps.com/

Once upon a time http://djangopluggables.com/ would have been on this
list too. However, that site has been down for a couple of months now,
and nobody seems to know what happened to it.

One of the topics of discussion at DjangoCon was a discussion of what
(if anything) the DSF could do to assist with community resources such
as these. So - watch this space for developments, but in the meantime,
try out the options that already exist, and if you aren't happy with
any of them, try to make something better - or better yet, offer to
help make one of the existing candidates better.

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 1.2 Feature Suggestion

[Joshua Russo]

On Sun, Oct 25, 2009 at 11:48 PM, Dan  wrote:

> I think this is best done through a third party site.  Look at the success
>> of DjangoGigs.  I don't know that there's a de facto place to look for apps
>> yet, but I bet a winner will emerge in time.
>>
>> Tobias
>>
>>
> The problem I see with that is that we clearly *are* standardizing toward
> some third parties apps. Not strongly enough to commit them to contrib with
> all the duties it implies but still! I don't think the doc is doing enough
> to let newcomers have the best tools available for their Django development.
>
> Or maybe we can go the Wiki route and display on the front page "ORM,
> cache, elegant URLs, ..., plenty of third party apps [link to a wiki page]".
>
> That way, there would be very little burden for the core devs and page
> would evolve as the different tools emerge.


I think a Wiki page would be the best way to handle this. I agree that there
is a need to more actively advertise some of the more popular third party
apps for new comers but those apps don't follow our dev cycle, so having
them in our docs doesn't seem to make sense.

Josh

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 1.2 Feature Suggestion

[Dan]

>
> I think this is best done through a third party site.  Look at the success
> of DjangoGigs.  I don't know that there's a de facto place to look for apps
> yet, but I bet a winner will emerge in time.
>
> Tobias
>
>
The problem I see with that is that we clearly *are* standardizing toward
some third parties apps. Not strongly enough to commit them to contrib with
all the duties it implies but still! I don't think the doc is doing enough
to let newcomers have the best tools available for their Django development.

Or maybe we can go the Wiki route and display on the front page "ORM, cache,
elegant URLs, ..., plenty of third party apps [link to a wiki page]".

That way, there would be very little burden for the core devs and page would
evolve as the different tools emerge.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 1.2 Feature Suggestion

[Tobias McNulty]

On Sun, Oct 25, 2009 at 7:39 PM, Dan  wrote:
>
> I didn't know about rosetta. What would you guys think of having a doc
> section about popular third party apps?


I think this is best done through a third party site.  Look at the success
of DjangoGigs.  I don't know that there's a de facto place to look for apps
yet, but I bet a winner will emerge in time.

Tobias
-- 
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 1.2 Feature Suggestion

[Dan]

> A few things:
>
> a) The feature proposal phase has already passed, it went on for the
> last 3 months or so.
> b) There's already an external application that does this:
> http://code.google.com/p/django-rosetta/
>
> Alex
>
>
I didn't know about rosetta. What would you guys think of having a doc
section about popular third party apps? I found many must-have Django tools
like the debug toolbar, south and command extension because I follow blogs
and read the mailing list but I feel the Django documentation should help
newcomers find those things.

I don't mean Django should document third parties stuff but there should be
an easy to find section in the doc with links (and appropriate disclaimers
obviously).

Should I file a ticket for it?

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 1.2 Feature Suggestion

[Alex Gaynor]

On Sat, Oct 24, 2009 at 6:50 PM, veena  wrote:
>
> Does the commentators have experience with maintaining the i18n django
> project? I do and completely agree with Jonas.
> "Gettext like+Rosetta like" but database driven translation app in
> Django adminwithout translation-makemessages-compilemessages-restart
> apache would be helpful. Import from the gettext file (managed by your
> standard tool) to db could be also provided.
>
> Vaclav
>
>
>
> On Oct 23, 6:13 pm, Simon Willison  wrote:
>> On Oct 23, 3:30 pm, Jonas Obrist  wrote:
>>
>> > Oh... Well than consider this a 1.X suggestion. I've tried Rosetta
>> > however it just doesn't seem to work Also I don't really like to use
>> > 3rd Party apps for what I'd consider core functionality. I mean django
>> > boasts with having excellent i18n capabilities, but when it comes to
>> > actually translating stuff it just refers to a 3rd party app
>>
>> My understanding is that translation tools are actually quite a
>> controversial issue within the translation community. Most translators
>> work on more than just one piece of software - they might help out
>> translating Django, Firefox, Emacs and a bunch of other stuff. As
>> such, they generally have their own standard tool that they work
>> within for managing all of their translation activity. A Django-
>> specific tool wouldn't actually help them at all, since they wouldn't
>> be able to use it for the other translation work that they do.
>>
>> As such, I don't think a single translation management tool should
>> ever be shipped as part of Django. It's too sticky a problem, and
>> hence is definitely best addressed by third party modules such as
>> Rosetta.
> >
>

I can't comment on the other people's work with i18n, but I've been
doing updates the Hebrew translations for the past couple of releases.
 I'm not sure what perspective people have, but as a developer doing
translations, needing to load up the CLI to make/compile messages
doesn't bother me, I'm going to need my CLI for doing the final diff
anyway.

IMO if you need a full web translation system you should be looking at
something like Transifex[0], which is clearly out of scope for Django
itself.

Alex

0: http://www.transifex.net/

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 1.2 Feature Suggestion

[veena]

Does the commentators have experience with maintaining the i18n django
project? I do and completely agree with Jonas.
"Gettext like+Rosetta like" but database driven translation app in
Django adminwithout translation-makemessages-compilemessages-restart
apache would be helpful. Import from the gettext file (managed by your
standard tool) to db could be also provided.

Vaclav



On Oct 23, 6:13 pm, Simon Willison  wrote:
> On Oct 23, 3:30 pm, Jonas Obrist  wrote:
>
> > Oh... Well than consider this a 1.X suggestion. I've tried Rosetta
> > however it just doesn't seem to work Also I don't really like to use
> > 3rd Party apps for what I'd consider core functionality. I mean django
> > boasts with having excellent i18n capabilities, but when it comes to
> > actually translating stuff it just refers to a 3rd party app
>
> My understanding is that translation tools are actually quite a
> controversial issue within the translation community. Most translators
> work on more than just one piece of software - they might help out
> translating Django, Firefox, Emacs and a bunch of other stuff. As
> such, they generally have their own standard tool that they work
> within for managing all of their translation activity. A Django-
> specific tool wouldn't actually help them at all, since they wouldn't
> be able to use it for the other translation work that they do.
>
> As such, I don't think a single translation management tool should
> ever be shipped as part of Django. It's too sticky a problem, and
> hence is definitely best addressed by third party modules such as
> Rosetta.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 1.2 Feature Suggestion

[Tom Evans]

On Fri, 2009-10-23 at 16:30 +0200, Jonas Obrist wrote:
> Oh... Well than consider this a 1.X suggestion. I've tried Rosetta 
> however it just doesn't seem to work Also I don't really like to use 
> 3rd Party apps for what I'd consider core functionality. I mean django 
> boasts with having excellent i18n capabilities, but when it comes to 
> actually translating stuff it just refers to a 3rd party app
> 

Django's i18n use gettext, which is about as standard as you will ever
get. There are any number of real applications for maintaining and
updating po files, and django-rosetta is is also pretty good. 

IMO I wouldn't see this as anything like core.

Cheers

Tom


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 1.2 Feature Suggestion

[Jonas Obrist]

Oh... Well than consider this a 1.X suggestion. I've tried Rosetta 
however it just doesn't seem to work Also I don't really like to use 
3rd Party apps for what I'd consider core functionality. I mean django 
boasts with having excellent i18n capabilities, but when it comes to 
actually translating stuff it just refers to a 3rd party app

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 1.2 Feature Suggestion

[Alex Gaynor]

On Fri, Oct 23, 2009 at 10:21 AM, Jonas Obrist  wrote:
>
> How about making  i18n strings translatable from the django admin site?
> I like how the whole i18n thingy is built from a template perspective,
> however getting the stuff actually translated (all those django-admin.py
> commands ...)  is a pain and confusing. So why not integrate this into
> the amazing admin site and make it even better?
>
> >
>

A few things:

a) The feature proposal phase has already passed, it went on for the
last 3 months or so.
b) There's already an external application that does this:
http://code.google.com/p/django-rosetta/

Alex

-- 
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---