On Tue, Dec 28, 2010 at 11:59 PM, Yo-Yo Ma wrote:
> Sorry, I did not mean a form. I meant a model's clean method. Normally
> you could do something in a model by similar means as your example
> though, but in the admin the only context where the request is
> available is through admin actions. Pe
Sorry, I did not mean a form. I meant a model's clean method. Normally
you could do something in a model by similar means as your example
though, but in the admin the only context where the request is
available is through admin actions. Perhaps this is a non-problem, and
more of just a lack of one
You are correct that threadlocal approaches are generally discouraged
by the core team. A threadlocal is just a fancy word for a global
variable, and should be discouraged for exactly the same reasons that
globals are discouraged.
As for "do we intend to solve this issue" -- you haven't been exact
I understand that accessing ``request`` inside of a form's clean
method, or in a model's save method is a bit of a "leaky abstraction",
but it can be very useful in a number of cases. I've seen solutions
which use ``threading.local`` in middleware to accomplish this, but
the consensus seems to be,
One more thing I forgot:
>> - In the database backend, how would plural forms of strings work in
>> languages with multiple plurals?
The database backend will not be the best in all features. In the same
way that "localmem://" it's not better than "memcached://" but
sometimes it's necessary, dat
Hey :)
>> Are you happy translating very long "django.po" without can just split
>> it in many files or just database records stored in cache?
>
> It gets the job done, yeah. For complex translations I've used Pootle and
> Transifex, both of which can import/export PO files.
yes, it's what we do
On 28.12.2010, at 18:33, Marinho Brandao wrote:
> Are you happy translating very long "django.po" without can just split
> it in many files or just database records stored in cache?
It gets the job done, yeah. For complex translations I've used Pootle and
Transifex, both of which can import/expo
Hey :)
> Well, I actually didn't mean forms and widgets with "translation of UI
> elements", but the "UI" of your website/project compared to the "data" that
> is displayed on it (e.g. from models). The first is covered by Django fairly
> well by using the industry standard gettext. The latter
>> The big issue I see here (at least from what I understand) is that content
>> translation and translation of UI elements
>> are completely different stories due to the way those content types differ
>> in structure and storage. Adding a
>> backend system implies having a common API, but I don'
Jannis,
I tried to be more clear with a long comment in the ticket [1].
Please, I wrote that from my mind without revise anything. It's just a
trial of make the idea more clear.
[1] http://code.djangoproject.com/ticket/14974#comment:4
On Tue, Dec 28, 2010 at 2:38 PM, Marinho Brandao wrote:
> H
Hey Jannis,
> Repeating what I said on the ticket, I don't quite understand what you mean
> by backend system.
A "backend system" is almost the same of design pattern "Adapter" [2]
that is used in many of functions of Django:
- Cache backends
- Emails backends
- Messages backends
- Authenticati
On 28.12.2010, at 12:32, Marinho Brandao wrote:
> But I'd like to suggest that we could make a backend system, like we
> have for many other components of the framework. So the developers
> could choose between gettext and database or create their own
> backends, with their dynamic sollutions.
Re
Hey people :)
I did open the ticket #14974 with a suggestion to make a backend
system for Internationalization component, in a contrib app.
Gettext is a good tool but limited to static files, and it sucks when
you work with long texts, you know: it gets a little unstable when the
message IDs are
13 matches
Mail list logo
