On Wed, Feb 15, 2017 at 12:21 AM, Adam Johnson wrote:
> Sorry for the terrible pun here, but I'd like to suggest the
> meta-feature... allowing 3rd party apps to add their own options to Meta
> classes. If there was a sensible API for this (or if Django just copied all
> attributes defined in Met
Adam, here's a ticket about allowing custom Meta attributes:
https://code.djangoproject.com/ticket/5793. I guess it would be better to
have a separate thread for that discussion.
On Tuesday, February 14, 2017 at 6:22:08 PM UTC-5, Adam Johnson wrote:
>
> Sorry for the terrible pun here, but I'd l
Sorry for the terrible pun here, but I'd like to suggest the
meta-feature... allowing 3rd party apps to add their own options to Meta
classes. If there was a sensible API for this (or if Django just copied all
attributes defined in Meta onto _meta blindly), Django wouldn't have to add
the translata
W dniu wtorek, 14 lutego 2017 16:19:48 UTC+1 użytkownik jp...@yourlabs.org
napisał:
>
> However, there's a third alternative to changing Meta that may be worth
> suggesting: adding a new Field attribute ie. translatable=True, which could
> be default for CharField and TextField perhaps. It might
Le 14. 02. 17 à 16:31, Patryk Zawadzki a écrit :
I think the proposed fields are mostly useful for translation utilities
that modify your schema on the fly. I consider these to be the least
clean solutions as they mean none of the translated fields can be marked
as required. For other solutions (
Le 14. 02. 17 à 16:16, j...@yourlabs.org a écrit :
(...)
However, there's a third alternative to changing Meta that may be worth
suggesting: adding a new Field attribute ie. translatable=True, which
could be default for CharField and TextField perhaps. It might even turn
to be an advantage that n
I think the proposed fields are mostly useful for translation utilities
that modify your schema on the fly. I consider these to be the least clean
solutions as they mean none of the translated fields can be marked as
required. For other solutions (depending on separate tables and
registration)
Django itself includes excellent i18n features for everything, except for
model data: but this can be improved, even in a multi-milestone fashion
starting with Claude's feature idea which is why I support it and I will
restrain myself from talking about internal implementation details which
con
Hi Raphael,
Le 14. 02. 17 à 14:53, Raphael Michel a écrit :
Hi Claude,
I spent some time looking at the implementations out there and in one
of my projects I'm running a custom one, that uses yet another approach
(that I plan to release as a library some day).
It is not only that we are not ye
Hi Claude,
I spent some time looking at the implementations out there and in one
of my projects I'm running a custom one, that uses yet another approach
(that I plan to release as a library some day).
It is not only that we are not yet ready to bless one of them, I have a
feeling that we never wi
Dear developers,
I'd like to suggest an addition to the Django Model definitions to ease the
implementation of translatable model fields. There are currently several
third-party applications for model translation, and even if I think we are
not ready yet to bless one of them to be included in c
11 matches
Mail list logo
