>In Changeset 841 you are stripping anything after a '-'. This would
>make a huge problem for translation based on language sub-tag. OTOH
>you can use _expand_lang from gettext to retrieve *list* of
>normalized language names for requested locale. You only must replace
>'-' with '_' before calling
It sounds reasonable. The only problem is how to expose this functionality
to developers. Right now database backends expose a connection, which can be
used to obtain cursors, which can be used to execute SQL. Model and view
code doesn't work with connections and cursors directly. It's in a dif
On 10/11/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Any one had a chance to look at this yet?
I just added it, and I've updated the docs. Thanks again for the idea and patch!
http://code.djangoproject.com/changeset/846
http://www.djangoproject.com/documentation/model_api/#field-types
Ad
Jonathan Daugherty wrote:
# We should be able to use transactions outside the scope of a Web
# request -- in, say, a Python script or the interactive
# interpreter. Transactions shouldn't be coupled with any other layers
# of the stack.
I agree. It seems to me that "transaction support" doesn
# We should be able to use transactions outside the scope of a Web
# request -- in, say, a Python script or the interactive
# interpreter. Transactions shouldn't be coupled with any other layers
# of the stack.
I agree. It seems to me that "transaction support" doesn't need to be
anything more c
On 10/11/05, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> >I haven't tested the patch to #9, but it requires (at least part of)
> >Zope, which is a big reason not to use it. Also, I don't know whether
> >coupling transactions to Web requests is a good idea.
> >
> >
> Think of it from the perspecti
I haven't tested the patch to #9, but it requires (at least part of)
Zope, which is a big reason not to use it. Also, I don't know whether
coupling transactions to Web requests is a good idea.
Think of it from the perspective of an inline form. If I have a single
form that is associated
to
On 10/11/05, Jonathan Daugherty <[EMAIL PROTECTED]> wrote:
> I'm interested to know about the status of transaction support in
> general, with particular regard to the admin interface and inline
> editing. I see that there was once a short thread started by Kapil,
> the submitter of a patch to im
So ...
Any one had a chance to look at this yet?
to hugo:
In Changeset 841 you are stripping anything after a '-'. This would
make a huge problem for translation based on language sub-tag. OTOH
you can use _expand_lang from gettext to retrieve *list* of
normalized language names for requested locale. You only must replace
'-' with '_'
Sune Kirkeby wrote:
On 10/11/05, hugo <[EMAIL PROTECTED]> wrote:
Actually I think a better way might just be to change django so that it
doesn't pull the DJANGO_SETTINGS_MODULE from the environment, but use a
django.settings_module from the WSGI environment - that can be handled
distinctly for
Hello folks,
I'm interested to know about the status of transaction support in
general, with particular regard to the admin interface and inline
editing. I see that there was once a short thread started by Kapil,
the submitter of a patch to implement transaction support in ticket
#9.
(Google gr
On 10/11/05, hugo <[EMAIL PROTECTED]> wrote:
> Actually I think a better way might just be to change django so that it
> doesn't pull the DJANGO_SETTINGS_MODULE from the environment, but use a
> django.settings_module from the WSGI environment - that can be handled
> distinctly for every applicati
>> Because of the magic Django does with settings, there can only ever
>> be one instance per Python process... Unless I'm missing something.
>That would be somewhat of a problem, because you couldn't install two
>Django apps in the same process without them being aware of each other,
>so in effe
Sune Kirkeby wrote:
On 10/11/05, Ian Bicking <[EMAIL PROTECTED]> wrote:
* easily installable. easy_install being a good way to do that. This
means each app goes in its own package with a setup.py file. This isn't
absolutely necessary, but packaging each app is generally good for
deployment.
Hi,
>Currently I have setup where I have two (almost) separate project
>which use same set of templates, so I'll be needing some way to
>manually set path to locale directory because my templates are
>outside of the booth projects.
I added an optional LOCALE_PATHS setting that you can use in you
On 10/10/05, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 10/10/05, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > I'd like to use doctest for testing my model classes, but the model
> > metaclass overwrites my classes docstrings. Is there any reason why it
> > MUST override __doc__? I thin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11-10-2005, at 16:05, hugo wrote:
Generally, discussions about the i18n stuff should take place
somewhere
where I can see them, if it's expected to be something I should take
into account in the branch :-)
Well, this is more Serbian only or
Hi,
just some heads-up on the i18n stuff: I am now mostly done with the
first part of implementing the base code. So I switched my gallery site
- http://viele-bunte-bilder.de/ - to use my branch and to run it. So
you can see the first app running with full i18n.
The source to that gallery stuff
>to Petar: We can continue this discussion on DPT or ICQ.
Generally, discussions about the i18n stuff should take place somewhere
where I can see them, if it's expected to be something I should take
into account in the branch :-)
Best way for online discussion would be the #django IRC channel on
That's a leftover - it is just there because the template stuff won't
translate well with xgettext (the multitude of quotes just make
xgettext woozy in it's head), so they are translated to some other
format. The current make-messages.py changes the references back to the
original .html, now - so
On 10/11/05, Nebojša Đorđević - nesh <[EMAIL PROTECTED]> wrote:
> to Petar: We can continue this discussion on DPT or ICQ.
Agreed.
--
Петар Марић
Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'. - Michael McClary
On 11-10-2005, at 13:24, Nebojša Đorđević - nesh wrote:
Hey C8E, maybe I'm missed but I just found out that you registered
django on roseta (https://launchpad.net/products/django) :). When we
can use this to make django translation repository?
---
Nebojša Đorđević - nesh
Studio Quattro - N
On 11-10-2005, at 13:08, Petar Marić wrote:
Offtopic: I think it's for the best to recode the current translation
file to cyrillic, because we can use automated tools to make latin
translation out of that. Saves quite a some time.
If it's allright with you nesh, I would get right on it :)
Gre
On 10/11/05, Nebojša Đorđević - nesh <[EMAIL PROTECTED]> wrote:
> This is little off-topic.
>
> I'm looking to make both Serbian translations (latin and cyrillic).
> But, I'm failed to found any reference to _standard_ codes for that.
> Only idea I have is to make two codes - sr_LAT and sr_CYR and
On 10/11/05, Nebojša Đorđević - nesh <[EMAIL PROTECTED]> wrote:
> Is it's really necessary to change extension of html files to
> html.py? xgettext will be treat all files as python source because "-
> L Python" anyway. Petar Marić <[EMAIL PROTECTED]> told me that
> poedit have some issues with fil
On 11-10-2005, at 12:06, Nebojša Đorđević - nesh wrote:
This is little off-topic.
I'm looking to make both Serbian translations (latin and cyrillic).
But, I'm failed to found any reference to _standard_ codes for that.
Only idea I have is to make two codes - sr_LAT and sr_CYR and to map
s
On 5-10-2005, at 15:28, hugo wrote:
So I'd opt to leave that stuff out of the i18n branch for now and to
concentrate on the "translations for string constants" part and some
other branch or patch can introduce the "multilinguality of models"
patterns later.
Well, creating new field types are
On 11-10-2005, at 11:33, Nebojša Đorđević - nesh wrote:
from make_messages.py:
if file.endswith('.html'):
src = open(os.path.join(dirpath, file), "rb").read()
open(os.path.join(dirpath, '%s.py' % file),
"wb").write(templateize(src))
On 5-10-2005, at 15:28, hugo wrote:
From docs:
- $PROJECTPATH/apps//locale//LC_MESSAGES/django.(po|mo)
- $PROJECTPATH/locale//LC_MESSAGES/django.(po|mo)
- $PYTHONPATH/django/conf/locale//LC_MESSAGES/django.(po|mo)
Currently I have setup where I have two (almost) separate project
which use
On 10/11/05, Ian Bicking <[EMAIL PROTECTED]> wrote:
> * easily installable. easy_install being a good way to do that. This
> means each app goes in its own package with a setup.py file. This isn't
> absolutely necessary, but packaging each app is generally good for
> deployment.
Definetly. And
31 matches
Mail list logo
