Re: Model translation

[JK Laiho]

> Actually there is a model translation app which uses a very similar
> approach to what you describe and already covers a good chunk of your
> 6 points.

Huh. That's interesting, I hadn't heard of that. Will take a look.
Thanks!

- JK Laiho

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Querysets with "only()" and "defer()" slower than without?

[OverKrik]

Thanks Jacob, I will continue testing and report if something new on
this issue comes out.

On Aug 6, 3:50 am, Jacob Kaplan-Moss  wrote:
> On Thu, Aug 5, 2010 at 6:14 PM, OverKrik  wrote:
> > Hi Jeremy, I will release all my code after finishing the test suite -
> > I think, in about 2 weeks.
>
> I'm looking forward to seeing it. I agree that the results are
> counter-intuitive; seems there's *something* going on here that
> shouldn't be happening. I'd expect, given your scenario, that the
> only/defer versions would be faster, so the fact that they're not
> means that the situation's more complicated than my mental model.
>
> I'm going to be trying to reproduce your results locally, both using a
> clone of your setup and also against some of the huge datasets I have
> access to. Let's keep on this: even if there's not a bug per se we
> still need to understand the implications of what only/defer are doing
> so we can accurately represent the pros/cons of using 'em.
>
> Thanks for bringing this up!
>
> Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Model translation

[JK Laiho]

On preview, django-datatrans looks really good, and the approach is
certainly better than any of the existing implementations, including
my abortive one. Still need to give it a run for its money properly to
see what issues remain. Whatever they are, they're probably solvable.
I'm not a betting man, but I'd be surprised if that didn't grow into
the de facto model translation approach in time.

I'm just glad I don't have to think about the model translation
problem anymore, I was exhausted just writing that monster post
yesterday :-)

- JK Laiho

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Model translation

[Beres Botond]

Your monster post was very useful, gave me a few ideas. Also it's a
good set of requirements to compare against for things that should be
fulfilled by a potential de facto model translation approach/app.
Combined with the excellent wiki article mentioned in this thread
(http://code.djangoproject.com/wiki/ModelInterNationalization) it's a
good basis for evaluating existing model translation apps, to see what
is missing or "wrong".
Regarding django-datatrans, I've been planning to take a more serious
look at it ever since I started using it. This thread might just be
the "kick in the butt" needed, we'll see :).

A few issues I'm aware of:
 -  _pre_save handler can cause problems on concurrent inserts
 -  integration with Django admin (or any other functionality that
presents the "translatable" fields in an editable context in the
frontend - for ex. in a form text input) - the editable widget will
get filled with the translated string and if you save it, the
*original* will get overwritten. On the "admin" of datatrans, there is
no problem, since it works directly with KeyValue-s. This is usually
not a problem on frontend because in most cases it makes no sense to
have translated content for values which are editable in frontend by
users. And admin is a controlled environment, so it's not a
"showstopper" (at least in my experience so far). But a transparent
solution is definitely needed.

In any case I don't think we'll see any model translation app in
django.contrib any time in the foreseeable future, taking for example
South as a reference on it's progress in this regard (considering it
is miles ahead in terms of maturity/stability/usage etc. than any
modeltrans app and it has pretty much achieved it's de facto status in
it's problem domain).
I'm not saying this is a bad thing, just an observation of facts. As
long as a 3rd party app is well known, easy to integrate with existing
projects, it's stable/mature, well maintained etc., I don't think it
makes very much difference if it is actually within django.contrib or
not.

Botond

On Aug 6, 12:01 pm, JK Laiho  wrote:
> On preview, django-datatrans looks really good, and the approach is
> certainly better than any of the existing implementations, including
> my abortive one. Still need to give it a run for its money properly to
> see what issues remain. Whatever they are, they're probably solvable.
> I'm not a betting man, but I'd be surprised if that didn't grow into
> the de facto model translation approach in time.
>
> I'm just glad I don't have to think about the model translation
> problem anymore, I was exhausted just writing that monster post
> yesterday :-)
>
> - JK Laiho

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

i18n form not working when in site root

[Florin]

Hi there,

I have put the form with a select box with languages in the template
header:



{% for lang in LANGUAGES %}
{{ lang.1 }}
{% endfor %}




When I change the language from any site's page it works like it
should, but when I go to the homepage (site's root) the
"django_language" cookie is reset and the language form doesn't work
anymore; it makes the POST request but it doesn't change the language.

Any help is welcome!
Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Model translation

[Jef Geskens]

Hi

I am the original developer of django-datatrans, and Gert Van Gool
(gvangool) also contributes some code.
Datatrans has been developed for MobileVikings.com, a cellphone
operator (MVNO) in Belgium that I work for.
Yes, our entire business depends on Python/Django, even the backend
calls to our network supplier,
customer support tools, ...

We needed a simple way to translate models without messing with
existing infrastructure.
I took concepts from different existing model translation apps like
django-multilingual, django-modeltranslation, etc.
Some of them looked very promising but none of them were really
usable. I like the registration approach of django-multilingual but
it changes the structure of your database. As a telco operator, we
cannot effort this risk of changing the database structure of
live, constantly changing data.
We needed some simple, easy-deployable and existing data friendly and
backwards compatible app. This is why I came up with a
system where we have a single dictionary containing all the
translations of our data.

Thanks for all the attention to this app, and yes it needs some kick
in the butt indeed.

Beres, to answer some of your concerns:

> Regarding django-datatrans, I've been planning to take a more serious
> look at it ever since I started using it. This thread might just be
> the "kick in the butt" needed, we'll see :).

That's why I put it on github, so others can have a look at it and
contribute to it.
We find it very useful at our company and, although it lacks some
serious tests (working on it...),
but we can safely ensure it is stable, as our business depends on it.

>
> A few issues I'm aware of:
>  -  _pre_save handler can cause problems on concurrent inserts

Yes, I'm looking for an alternative way to handle this. Maybe some
sort of locking mechanism will help...

>  -  integration with Django admin (or any other functionality that
> presents the "translatable" fields in an editable context in the
> frontend - for ex. in a form text input) - the editable widget will
> get filled with the translated string and if you save it, the
> *original* will get overwritten.

This has been, believe it or not, taken care of ;-)
It may sound confusing at first, but Datatrans is smart enough to see
that,
when you are not in the original language, it actually modifies the
_translation_, and not the original data.
So when your current language is Dutch, when you edit something that
has been datatransed, you edit the Dutch value.
When your current language is English, and it is the default, you edit
the original data, and it marks the translation as fuzzy
so translator can verify if the translation is still valid, in the
same fashion as poedit.


I will follow this discussion closely from now on.

-Jef Geskens
Software Engineer at MobileVikings.com


On Aug 6, 3:17 pm, Beres Botond  wrote:
> Your monster post was very useful, gave me a few ideas. Also it's a
> good set of requirements to compare against for things that should be
> fulfilled by a potential de facto model translation approach/app.
> Combined with the excellent wiki article mentioned in this thread
> (http://code.djangoproject.com/wiki/ModelInterNationalization) it's a
> good basis for evaluating existing model translation apps, to see what
> is missing or "wrong".
> Regarding django-datatrans, I've been planning to take a more serious
> look at it ever since I started using it. This thread might just be
> the "kick in the butt" needed, we'll see :).
>
> A few issues I'm aware of:
>  -  _pre_save handler can cause problems on concurrent inserts
>  -  integration with Django admin (or any other functionality that
> presents the "translatable" fields in an editable context in the
> frontend - for ex. in a form text input) - the editable widget will
> get filled with the translated string and if you save it, the
> *original* will get overwritten. On the "admin" of datatrans, there is
> no problem, since it works directly with KeyValue-s. This is usually
> not a problem on frontend because in most cases it makes no sense to
> have translated content for values which are editable in frontend by
> users. And admin is a controlled environment, so it's not a
> "showstopper" (at least in my experience so far). But a transparent
> solution is definitely needed.
>
> In any case I don't think we'll see any model translation app in
> django.contrib any time in the foreseeable future, taking for example
> South as a reference on it's progress in this regard (considering it
> is miles ahead in terms of maturity/stability/usage etc. than any
> modeltrans app and it has pretty much achieved it's de facto status in
> it's problem domain).
> I'm not saying this is a bad thing, just an observation of facts. As
> long as a 3rd party app is well known, easy to integrate with existing
> projects, it's stable/mature, well maintained etc., I don't think it
> makes very much difference if it is actually within 

Re: i18n form not working when in site root

[George Adams]

This forum is for the development of Django itself and not its use. If you
have a question regarding how to do something or make something work for a
project using Django, please direct those to the django-users mailing
list.
After asking there and you feel like there is a defect with Django or a
possible improvement that should be discussed, feel free to bring it up here
later with that intent. Thank you.

--
George Wright Adams IV

Undergraduate Student of Software Engineering
Rochester Institute of Technology

http://gada.ms/
(585) 704-8198
g.w.adams...@gmail.com


On Fri, Aug 6, 2010 at 09:44, Florin  wrote:

> Hi there,
>
> I have put the form with a select box with languages in the template
> header:
> 
> 
> 
> {% for lang in LANGUAGES %}
> {{ lang.1 }}
> {% endfor %}
> 
> 
> 
>
> When I change the language from any site's page it works like it
> should, but when I go to the homepage (site's root) the
> "django_language" cookie is reset and the language form doesn't work
> anymore; it makes the POST request but it doesn't change the language.
>
> Any help is welcome!
> Thanks
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: i18n form not working when in site root

[Florin]

Moved. Thanks

On Aug 6, 5:10 pm, George Adams  wrote:
> This forum is for the development of Django itself and not its use. If you
> have a question regarding how to do something or make something work for a
> project using Django, please direct those to the django-users mailing
> list.
> After asking there and you feel like there is a defect with Django or a
> possible improvement that should be discussed, feel free to bring it up here
> later with that intent. Thank you.
>
> --
> George Wright Adams IV
>
> Undergraduate Student of Software Engineering
> Rochester Institute of Technology
>
> http://gada.ms/
> (585) 704-8198
> g.w.adams...@gmail.com
>
> On Fri, Aug 6, 2010 at 09:44, Florin  wrote:
> > Hi there,
>
> > I have put the form with a select box with languages in the template
> > header:
> > 
> > 
> > 
> > {% for lang in LANGUAGES %}
> > {{ lang.1 }}
> > {% endfor %}
> > 
> > 
> > 
>
> > When I change the language from any site's page it works like it
> > should, but when I go to the homepage (site's root) the
> > "django_language" cookie is reset and the language form doesn't work
> > anymore; it makes the POST request but it doesn't change the language.
>
> > Any help is welcome!
> > Thanks
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > To post to this group, send email to django-develop...@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.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Querysets with "only()" and "defer()" slower than without?

[Anssi Kaariainen]

On Aug 6, 12:09 am, Jacob Kaplan-Moss  wrote:
> If you're benchmarking this against a small dataset and an in-memory
> database like SQLite I'd fully expect to see the defer/only benchmark
> to be slower. That's because every time a QS is chained it needs to be
> copied, which is a relatively expensive operation. In a setup with
> small data, the time spent in Python is going to outweigh the time
> spent running the query in the database and sending the data over the
> wire.

A retest with:
for pk in xrange(1,5):
   user = User.objects.only("power_level").get(pk = pk)
   d = user.power_level

replaced with:
qs = User.objects.only("power_level")
for pk in xrange(1, 5):
user = qs.get(pk=pk)
d = user.power_level

# repeat for all tests.

Should remove the effect of query building. (btw why not "inplace()
function for query set if you know you won't be using the middle steps
in  chained query building?)

I have been looking into object creation speed when loading many
objects simultaneously, for my particular case running the query as
values_list took something like 5ms (sorry, I don't remember the
values and I am not at work at the moment), 50ms when constructing
instances (1500 objects in my case). The problem seems to be that for
every object created we go and check which fields the model has, which
of them come from args, which are deferred and which have default
values. It would probably be much faster to check the field
classifications once, and the bulk create the objects using the
classifications.

I did a small test for building 1500 objects in this style (only
object building, not from query set), and the result was something
like 50% faster object building. And yes, signals were sent for every
object created + default() was called if it was callable for the
field. The iterator in query makes it hard to use bulk loading style
however...

The same problem is present in row iteration when constructing objects
from the rows returned from the DB. For each row we check which select
related things we have etc. This could be checked once before starting
to iterate through the rows and then use the calculated values each
time when building the object from the row.

- Anssi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Why this feature is still not accepted ?

[dharmesh.patel.eif...@gmail.com]

Hello,

http://code.djangoproject.com/ticket/11397

As I already implemented it for Django version1.1 but still there is
no action or feedback on 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-develop...@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: Why this feature is still not accepted ?

[Mikhail Korobov]

Hi all.  I'm not a django core developer but have some thoughts about
provided patch.

1. The patch is for django 1.1 and django 1.2 have jQuery available so
some parts may be simplified.
2. Some 'var' declarations are missing (check
'dismissChangeCurrentPopup' method and 'i' variable, 'href' and
'element' variables in 'showChangeCurrentPopup' function). This will
pollute global namespace and can cause weird bugs in future.
3. I don't understand some code: what is 'element =
document.getElementById(element_id);' declaration for in
'showChangeCurrentPopup' function (and 'elem =
document.getElementById(toId);' in 'dismissChangeCurrentPopup').
4. Permissions are not checked. It should be mentioned that Django 1.2
now has row permissions foundation.

Regards,
Mikhail.

On 7 авг, 00:46, "dharmesh.patel.eif...@gmail.com"
 wrote:
> Hello,
>
> http://code.djangoproject.com/ticket/11397
>
> As I already implemented it for Django version1.1 but still there is
> no action or feedback on 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-develop...@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: Why this feature is still not accepted ?

[Simon Meers]

Apart from permissions issues etc as Mikhail mentioned, there is also an
important design decision required about whether it is a good idea to
provide a dynamic link to the selected item rather than the last saved item.
If you allow the user to change their selection and then click the link to
view that item, you're encouraging them to follow a link which will lose
their unsaved changes. I think it is wiser to provide a clear (named) link
to the saved item.

Interesting that this ticket did not come up as a duplicate when #13165 [1]
was opened. I suggest the earlier ticket should be closed as a duplicate,
since #13165 has a more mature/up-to-date patch. It is just awaiting
resolution of permission issues and the input of a UX expert, together with
#13163 [2]

Simon

[1] http://code.djangoproject.com/ticket/13165
[1] http://code.djangoproject.com/ticket/13163


On 7 August 2010 04:46, dharmesh.patel.eif...@gmail.com <
dharmesh.patel.eif...@gmail.com> wrote:

> Hello,
>
> http://code.djangoproject.com/ticket/11397
>
> As I already implemented it for Django version1.1 but still there is
> no action or feedback on 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-develop...@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.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Why this feature is still not accepted ?

[dharmesh.patel.eif...@gmail.com]

Hello Simon

Its already providing dynamic link according to selected items in the
combo box not just for last saved item and if this ticket is accepted
for 1.1 version then it was up to date for it and this feature could
included in 1.1 version and for 1.2 version or for any future versions
we just need to rework on it.

Now situation is like http://code.djangoproject.com/ticket/13165 is
duplicated work with my http://code.djangoproject.com/ticket/11397
ticket which was already implemented for older version.

On Aug 7, 3:13 am, Simon Meers  wrote:
> Apart from permissions issues etc as Mikhail mentioned, there is also an
> important design decision required about whether it is a good idea to
> provide a dynamic link to the selected item rather than the last saved item.
> If you allow the user to change their selection and then click the link to
> view that item, you're encouraging them to follow a link which will lose
> their unsaved changes. I think it is wiser to provide a clear (named) link
> to the saved item.
>
> Interesting that this ticket did not come up as a duplicate when #13165 [1]
> was opened. I suggest the earlier ticket should be closed as a duplicate,
> since #13165 has a more mature/up-to-date patch. It is just awaiting
> resolution of permission issues and the input of a UX expert, together with
> #13163 [2]
>
> Simon
>
> [1]http://code.djangoproject.com/ticket/13165
> [1]http://code.djangoproject.com/ticket/13163
>
> On 7 August 2010 04:46, dharmesh.patel.eif...@gmail.com <
>
> dharmesh.patel.eif...@gmail.com> wrote:
> > Hello,
>
> >http://code.djangoproject.com/ticket/11397
>
> > As I already implemented it for Django version1.1 but still there is
> > no action or feedback on 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-develop...@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.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.