1.2 Feature Suggestion
Jonas Obrist
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?
Alex Gaynor
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
Jonas Obrist
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....
Tom Evans
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
Simon Willison
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.
veena
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
Alex Gaynor
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/
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 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?
Tobias McNulty
I didn't know about rosetta. What would you guys think of having a doc section about popular third party apps?
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com
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
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.
Joshua Russo
Russell Keith-Magee
> On Sun, Oct 25, 2009 at 7:39 PM, Dan <redal...@gmail.com> 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 %-)
Joshua Russo
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.
James Bennett
<freakb...@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.
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&c=523
or just lists Django stuff:
http://pypi.python.org/pypi?:action=browse&show=all&c=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."
Russell Keith-Magee
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 Pylons, for instance; any sort of community voting scheme will
just get confused by this sort of overlap. There is something to be
said for us providing a Django-specific social community layered on
top of PyPI, rather than us trying to enforce a community on the
entire of Python.
Yours,
Russ Magee %-)