Is Django documentation translations to land in main repository ?

[Amirouche B.]

Héllo,

Everything is in the title. Does Django core dev's want to have localized 
documentation in main repository or should it be managed by local DUG ?

Thanks to Pilot Systems, I improved a bit the french documentation 
[1] basically what I've done is converted it to use the Sphinx support of 
.po files and translated the how-tos.

Now what main repo needs:
- fix the Makefile [2] like it's done in [1] or something smarter maybe 
convert the Makefile to a Python script so that we have a better handling 
of locales please see [2]
- the source documentation needs some fixes to be fully possible to do L10N 
but it's not a priority (problems might be solved in Sphinx)

Mind the fact that getting .po support and the facility to do documentation 
L18N in the main repo is needed to avoid any future effort to do what is 
IMO a mistake to translate the documentation in the rst files.

What do you think ?


Thanks.


[1] https://bitbucket.org/amirouche/django-fr-translation
[2] 
https://bitbucket.org/birkenfeld/sphinx/issue/1026/makefile-for-building-mo-and-merging-po

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/r5vbKm3wovEJ.
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: Is Django documentation translations to land in main repository ?

[Amirouche B.]

On Saturday, December 15, 2012 5:05:36 AM UTC+1, Russell Keith-Magee wrote:
>
>
> On Sat, Dec 15, 2012 at 11:53 AM, Amirouche B. 
> 
> > wrote:
>
>> Héllo,
>>
>> Everything is in the title. Does Django core dev's want to have localized 
>> documentation in main repository or should it be managed by local DUG ?
>>
>
> Yes :-)
>
> In a perfect world, you'd be able to get documentation in other languages 
> on docs.djangoproject.com. If you look at the URL space, you'll see that 
> we've already prepared for translations -- you hit /en/dev to get the 
> development docs; in theory, we could serve /fr/dev for french 
> documentation.
>

Cool, didn't noticed 
 

>
> However, what we're missing is the process for managing these translations.
>
> The core team speak a few languages (we've got German, French and Spanish 
> covered, and possibly a couple of others), but aren't in a position to 
> review and commit revisions for lots of other significant languages. 
>
> Taking i18n and l10n as an example; we've moved to using Transifex 
> specifically because it allows us to give control of translations to local 
> language communities; then, once per release, we push a single commit of 
> translation updates to the main repository. Ideally, we'd take a similar 
> approach for translated docs, but Transifex isn't really well suited to 
> translation of large bodies of text.
>
> So - your translation efforts are definitely welcome. What we need to work 
> out is the process by which we can practically use these translation 
> efforts -- and, more importantly, make sure that they're kept up to date 
> (e.g., once a base translation is done, ensuring that translation teams 
> have a 'todo' list, and we can indicate to readers which translations are 
> current, and which are stale). Any suggestions on how we could manage this 
> are also welcome.
>

I never used Transifex, I don't know why this can not be used for large 
projects. Maybe it can work ? 

Here is what I propose:

- A manager is choosed among every LUG to manage a Transifex project for 
its langage
- Once every release or every 6 months POs are pushed to main repo
- If the L10N effort lakes behind the releases, users are notified that the 
documentation is not available in their language and propose a) to go to 
old doc b) to go to english doc (I don't think this is handled by 
readthedocs so this is another issue)

The manager (or the managing team) will have in charge to update PO files 
on Transifex in a regular fashion.

Maybe someone with Transifex experience can tell more about that.

Another option I think of, is to break documentation directory and maybe 
even each locale directory into a git submodule so that LUGs can work on 
translation without polluting the main git history with L10N stuff while 
still being able to use git to manage the translation which will also allow 
to avoid having to use Transifex.

Looking forward having other insights about this issue.

Regards,

Amirouche

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/mcEoC29xAmIJ.
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: Proposal: Django URL Admin (django-urls)

[Amirouche B.]

On Friday, December 7, 2012 9:07:32 PM UTC+1, Zach Borboa wrote:
>
> Does something like this exist already? If not, it should.


How this can be useful ? You still need to write the view in Python then 
why not write the urls in Python too, like it's currently the way to go.

If something in this spirit might be useful is something where the view 
could be generated which would be something like databrowser or admin.

Could you elaborate ?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/WUkyoQyQa7YJ.
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: Django Admin Revamp - Any updates?

[Amirouche B.]

On Friday, April 27, 2012 1:06:06 AM UTC+2, Victor Hooi wrote:

> Hi,
>
> Is there any news on the Django Admin rewrite front?
>

I'm very interested in this topic and have some time to kill so I started 
the wiki page don't hesitate to comment, correct, review and add you own 
ideas.

https://code.djangoproject.com/wiki/HydroAdmin

Regards,

Amirouche

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/Ji8aLKXnVd4J.
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: Django Admin Revamp - Any updates?

[Amirouche B.]

>
> Is there any news on the Django Admin rewrite front?
>>
>
> I'm very interested in this topic and have some time to kill so I started 
> the wiki page don't hesitate to comment, correct, review and add you own 
> ideas.
>

I made POC of django-hydro the widget composition framework using 
bootstrap, it's available at https://github.com/amirouche/django-hydro

Could you provide more insights about the issues you encounter while using 
and trying to extend the admin or better update the wiki page 
https://code.djangoproject.com/wiki/HydroAdmin or I'll add them myself.

Thanks in advance,

Amirouche

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/pKyVzy2RB5IJ.
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: Django 2.0 - a case for a customizable pony

[Amirouche B.]

Héllo,

Sorry, I also think you are vague -- or I'm not enough versed into Django 
developpers ecosystem and Python in general to understand.

Admin - lacks abstraction, and therefore has some great tools that 
> can't really be used elsewhere (e.g., filter specs, sorting, etc.), lacks 
> usage of CBV, in favor of an ad hoc solution
>

I'm working on an admin myself, I would be glad If you could review it or 
provide more insights about the issues you encounter while using and 
extending the admin 
https://groups.google.com/forum/?fromgroups=#!topic/django-developers/Vozu6U3gz84

Thanks,

Amirouche

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/I_LyIpKqOVMJ.
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: DJango and OrientDB

[Amirouche B.]

Héllo,

Sorry to shim in a probably a bit off and old topic discussion, I think we 
need to have this discussion, even if this is similar to any other nosql 
discussion, there is nothing really specific to OrientDB or any graphdb 
(Neo4J, Rexster server, ...).

I have no particular experience with OrientDB dev, as I'm more interested 
in Rexster server, but I hope I can be of some help.

There is another old topic in django-users so you might want to check it 
too:

- https://groups.google.com/d/topic/django-users/WHEmlrTVgWc/discussion

I am planning to use orientDb with Django application (i am yet in design 
> stage).
>

Join the fun :)
 

> I am not sure if i should just use simiple pyorient like library to access 
> orientDB or should i write new db driver etc
>

I don't think Django ORM can address the GraphDB issues just like it 
couldn't address mongodb things and that was the purpose of specific 
software Django-nonrel (which 
looks unmaintened). Django-nonrel won't probably address it too, 
that said I never used django-nonrel, so I'm no best to give a definitive 
answer about the subject.
 

> Basically my question is should i worry about not using django db 
> functionality if i write custom classes to represent model classes.
>

The question is vague. Are you aiming at using both a relationnal database 
and a graphdb or just a graphdb ?

- Both: Since you can't use django orm with orientdb, you need to make the 
graphdb orm or deal in your code with the connection, querying to the 
graphdb
- GraphDB only: the above solve this case.

For other probable questions:

- Can I create a graphdb (Neo4j, OrientDB, Rexster) driver for Django ORM, 
yes and no. It might be possible to get some of the functionnality of 
Django ORM working (crud, related object querying, filtering) but the ORM 
won't address features specific to the graphdbs which might make such a 
project useless. That's why I think people started their own ORM and there 
is no drivers for graphdb in relational orms I know of.

- GraphDB + Django Admin ? No, there is yet no admin that can explore/edit 
a graphdb in Django even if such a thing might be possible to do. Django 
admin is bound to Django ORM, so this is not gonna happen in the forseable 
future unless there is a new admin that is decoupled from the Django ORM. 
Since I'm working on a new admin, I dig this issue but it's not a priority.

- Is it possible to use a graphdb with Django ? Yes see the topic on 
django-users.

Graph databases are a wonderful thing, I think more people should use them 
for the web and not only to solve specific problems related to graphs but 
also for generic web development. There is no or little done in this regard 
in the Python framework space because graphdbs are still, even if lately 
buzzing, in its infantility, but it can be of great help to rapidly 
prototype apps. 

What Django can do ? Nothing or little, like I said earlier even if 
graphdbs share some common patterns with relationnal databases I don't see 
the ORM evolve to support both kind of databases without putting dangerous 
tools in the hand of non-vigilant developpers.

Cheers,


Amirouche

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/kqSmKNCTTlQJ.
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.

[AdminNext] Updates (was: Django Admin Revamp - Any updates?)

[Amirouche B.]

Héllo,


Since my initial introduction, I tempered my excitement and tried to have a 
better understanding of the issues faced by the admin following the Django's 
guide to 
contribute, 
which resulted in me writing
a post  which I 
wish to contribute in a form or another in the AdminNext wiki 
page. 
I also did this because I couldn't get feedback the lazy 
way,
 
I'll bump the thread later in the month answering the questions myself and 
I invite you to do the same so that more people get interested in the 
discussion or start another topic with more relevant questions.

First, there is already work done regarding a new version of the admin that 
can be BC:

   - Dogfood class-based views in contrib.admin 
#17208 
   - Making it easier to customize Django Admin 
#18665 
   - View collections #16213  
   - API for simpler (permission or any) checks for generic view classes 
   #15215  

those have all code, are abandonned or not claimed anymore, all accepted 
except the last which needs a design decision.

In the analyze I did, I tried do separate the problem into two different 
topics:

- *code features* are all things put in place by the admin to make it 
possible to build upon it and implement user features
- *user features* is what is expressed as needs by the user, the 
general ergonomic, the things they need to be able to do

For instance «an application overview» is an user feature, the related code 
feature that will allow to do that are «dashboard API», «template 
overriding» and «hook another view in the admin site». What I think is that 
the admin is too much focused on code features notably on models. I think 
the admin is model centric, to my mind it would be better if it was 
groups-centric, groups of users and groups of process or permissions which 
in Django is simply referred as group. 

To my mind this reflexion doesn't change the fact that the admin should be 
more extensible and pluggable. So what I envision right now about AdminNext 
is the following:

- Pluggable and extensible admin components
- Groups centric API to build application backends
- Use the above to implement a similar admin as current admin

I still think django-composite can be relevant, but I need to tweak it a 
bit and also fully implement the ChangeList to have more things to back it. 
If composite is not accepted then I think it's still possible to achieve 
something similar with template tags. Spoiler: django-composite is meant to 
be able to replace template tags in certain scenario.

I think it's possible to do this BC and follow Django deprecation policy, 
but it won't be the quickest. I have no experience regarding this subject, 
but the worst scenario would be to do it outside without community feedback 
and then port all the things to Django which would result in the same path 
as the one that had followed the BC way.


Amirouche

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/OZK3tKIuo-4J.
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: About Understanding of source code

[Amirouche B.]

On Tuesday, January 8, 2013 6:54:41 PM UTC+1, ptone wrote:
>
> You might want to attempt to write a patch for an open issue - reading the 
> source code is one thing and you may learn a bit. But dissecting the source 
> code when you have the purpose to fix a problem, gives you a much better 
> understanding of how things are working - as you NEED to understand them in 
> order to properly fix/extend them. Just reading through it allows you to 
> too easily skip over things you don't really understand.


Also you can read the discussions that lead to the code, here is those that 
I know of:

- https://code.djangoproject.com/wiki/NewformsAdminBranch
- https://code.djangoproject.com/wiki/ClassBasedViews

To find easy bugs, check easy picking in trac custom 
query,
 you 
can also precise a component for instance if you are interested in the 
ORM
.

Also one way to learn little by little while still keeping an eye on what 
is coming is to watch django on github  (or 
subscribe using a feed 
reader
). Also there is mailling list for the 
tickets
 (prefered)

Regards,

Amirouche

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/142VK7-i_hkJ.
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: [Future feature?] Viewsets

[Amirouche B.]

Héllo Bertrand,

Yesterday I read a Ruby on Rails tutorial and this gave me an idea of what 
> could IMO be a nice feature: viewsets.
> I therefore started a tiny project, 
> django-viewsets 
> (djangonauts 
> have weird reflexes… ^^).  *Everything is explained there.*
>
> What do you think?  Could this be an interesting feature?  “The next level 
> of class-based views”?  A *contrib* application?
>

It's very interesting and it might be why a similar thing exists in the 
admin but not pluggable yet.

There is a ticket for this issue: 
https://code.djangoproject.com/ticket/16213

I made another implementation of this 
https://github.com/django-composite/django-composite/blob/master/composite/urls.py

- It's named UrlCollection since it's a collection of urls...
- Support callable, views function and CBVs
- It's possible to provide a default application_namespace (see 
https://code.djangoproject.com/ticket/11642) but overridable at include time
- It's also possible to nest UrlCollections (equivalent your ViewSets class)
- It's possible to inherit AdminSite and ModelAdmin from UrlCollection and 
implement the missing methods/properties...

But there is no particular support of GCBV (ListView, CreateView...), it's 
a good idea I will add it.

Please have a look at it, I'll do the same with multiviews and viewsets and 
to try to advance the discussion further maybe merge the three of them ?

-- 
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.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Future feature?] Viewsets

[Amirouche B.]

>
> What's in common between multiviews, composite, and viewsets:
>
>- Views are grouped in a class.
>- Each view is tied to an URL pattern.
>- All URL patterns of a group of views are accessible using nearly the 
>same syntax: GroupOfViews.urls() for multiviews, url('', 
>include(GroupOfViews().urls())) for composite and url('', 
>include(GroupOfViews().urls)) for viewsets.
>
> I am in favor of using the include('path', GroupOfUrls.url()) syntax
 

>
>
> Multiviews
> Pros:
>
>- Simple.
>
> Cons:
>
>- Uses inspect to find views.  Too "magic" IMO.
>- Requires to define a form, specify the namespace and template names 
>(example: 
>https://github.com/akaariai/multiviews/blob/master/views.py#L96).
>
> Those are what UrlCollection are meant for.

 

>
>- The views defined are very simple reimplementations of GCBV; and of 
>course, not extensible.
>- No GCBV support. 
>
>
>
> Composite
> Pros:
>
>- Powerful; a complete framework to the glory of Python (write less 
>HTML/CSS/JS, more Python!) and DRY. 
>
>
>- Views directly have name and path attributes to avoid writing them 
>inside urls.py.
>
> The part was dropped because a) it can be implemented in user code b) It's 
not «relevant» in the composite framework c) path makes view bound to urls 
which makes it impossible to add a view in different places (loose 
coupling...) and it is not relevant to UrlCollection, UrlCollection is only 
the urls.py file.

Cons:
>
>- Complex.
>
>  Only the urls.py file is takes part in the UrlCollection feature

>
>- Highly misleading names (especially Widget…).
>
>  this is not related to UrlCollection

>
>- No application namespace detection.
>
>
>- Can't be easily merged in Django (I know, composite was not designed 
>for this purpose).
>
> Actually it is, but not this way.
 

>
> Viewsets
> Pros:
>
>- Simple.
>- Designed to be extensible (even though it could be better).
>- Automatic application namespace based on model app_labels.
>- PEP8 compliance and Python3 support ;o)
>
> Cons:
>
>- No function-based views support (could be fixed in two lines).
>- Uses an awkward dict to define views, url names and patterns.
>
> I think ViewSets is the nearest thing to what could be merged, thus we 
should use it. Also the model app_labels detection is only relevant for 
model based UrlCollections and I think we should provide one feature at a 
time.

Also what do you think about nested UrlCollection (or nested GroupOfViews) 
basically make it possible to include other GroupOfView in a GroupView
 

>
>
> By the way, I really liked in *composite* the idea of setting url names 
> and patterns as class-based view attributes.
>

No, it's not a good idea, see above.
 

> Maybe the best idea of all this discussion; could this become a core 
> feature, as well as "template_name" and "get_template_name"?
>

In composite what I do, is bound the *View classes to the GroupOfViews 
class then instantiate the bound class so that user code can override which 
view is instantiated this way it's possible to change templates easily. 
Adding a hook in GroupOfViews to override templates for several Views is 
prone to error. 

It lakes tests and documentation of course. I'll try to do a push to 
Viewsets something if you did not already do it. I think getting an 
external app up and running is the best thing to do.

Regards

-- 
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.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.