Do we have plan to release new version with the model translation ?
I am wondering whether I should wait for the new version or change my
project according to the codes we have now.
On Wednesday, July 23, 2014 10:33:30 PM UTC-4, Eduardo Rivas wrote:
Yeah, I've got the pull request ready,
Hi Paul. It seems like you sorted out the issue you were linking too. Are
there any others?
I finally found some time to come back to this, and noticed the front-end
language selector is gone. The problem is in the condition for rendering the
template
Yeah, I've got the pull request ready, but the dropdown on which you select
the repo you want to compare your changes with won't list Mathias' fork of
Mezzanine.
--
You received this message because you are subscribed to the Google Groups
Mezzanine Users group.
To unsubscribe from this group
Hi there,
I am giving Mathias's fork a go to see if we can use it to deploy a
multilingual site solution. I forked it here
https://github.com/cccs-web/mezzanine and set up a branch of our
mezzanine site to use it and define the modeltranslation stuff.
I am starting to raise issues against our
Just corrected a few things for the front-end language selector and pushed
an updated version of cartridge as well.
I tried the TabbedExternalJqueryTranslationAdmin class instead of
TranslationAdmin and couldn’t get the meta tag area to show. Does it happen
for you too? Or is there something
Ok, changes are done.
I tried something for inlines admin classes (mezzanine.core.admin), but I’m
not sure wether it sounds right or not, let me know.
Le lundi 9 juin 2014 02:37:44 UTC+2, Stephen McDonald a écrit :
On Sun, Jun 8, 2014 at 6:15 PM, Mathias Ettinger mathias@gmail.com
You’re pretty right, some design choices sound really bad when put like
this. I’ll move the admin classes, the code_list and the frontend language
selector somewhere else.
As for the TRANSLATED setting, I don’t recall exactly why I tied it with
USE_I18N. If I’m correct, it is because
On Sun, Jun 8, 2014 at 6:15 PM, Mathias Ettinger mathias.ettin...@gmail.com
wrote:
You’re pretty right, some design choices sound really bad when put like
this. I’ll move the admin classes, the code_list and the frontend language
selector somewhere else.
Not bad per se, it's common for
Ok I spent a bit of time going over the pull request and testing it, it's
really good.
I think we can tighten things up a little, for example we have `class
SomeAdmin(TRANSLATED and TranslationAdmin or admin.ModelAdmin)` all through
each of the admin modules. I think we could have a single
Hey everybody. I've been trying out Mathias master branch and everything is
working smoothly. As I said, I'm also exploring ways to enable toggling
translation fields in the Admin. Turns out Model Translation (MT) provides
two admin classes (docs
I tried Mathias branch so I could give feedback but couldn't create a
project:
http://hastebin.com/acasezifok.vhdl
At a glance I tried re-ordering INSTALLED_APPS but that didn't resolve it.
On Sat, Jun 7, 2014 at 10:26 AM, Eduardo Rivas jerivasmel...@gmail.com
wrote:
Hey everybody. I've
Odd, I just created a project without issue. This is my venv:
Django==1.6.5
Mezzanine==3.1.3 #From Mathias' branch
Pillow==2.4.0
South==0.8.4
argparse==1.2.1
bleach==1.4
django-debug-toolbar==1.2.1
django-modeltranslation==0.7.3
filebrowser-safe==0.3.3
future==0.9.0
grappelli-safe==0.3.10
Real odd, works fine for me now and no matter what I try I can't reproduce
the error I had.
On Sat, Jun 7, 2014 at 2:09 PM, Eduardo Rivas jerivasmel...@gmail.com
wrote:
Odd, I just created a project without issue. This is my venv:
Django==1.6.5
Mezzanine==3.1.3 #From Mathias' branch
Fair enough - just wanted to make sure something simpler hadn't been
overlooked.
On Tue, May 27, 2014 at 12:30 AM, Mathias Ettinger
mathias.ettin...@gmail.com wrote:
Well, I started from something similar in the first place. I think it is
good enough for an external app, but not so good if
BTW to answer your earlier question - any slug creation logic definitely
belongs on the model (Slugged I believe) rather than an admin class.
On Tue, May 27, 2014 at 12:30 AM, Mathias Ettinger
mathias.ettin...@gmail.com wrote:
Well, I started from something similar in the first place. I think
I had some thoughts about what tests to add and how to write them. But
everything lead to the same question: how is it possible to configure
several languages for the tests without hardcoding them into settings.py?
--
You received this message because you are subscribed to the Google Groups
I should have read the whole Stack Overflow thread! It looks like Django
has built in ways of doing it.
https://docs.djangoproject.com/en/1.6/topics/testing/tools/#overriding-settings
--
You received this message because you are subscribed to the Google Groups
Mezzanine Users group.
To
I think you can access the settings module like every other place in the code
base. This example recommends the setup and teardown methods for modifying
settings in unit tests: http://stackoverflow.com/a/913596. Hope that helps :-)
--
You received this message because you are subscribed to
Great! Hopefully your commits will be merged soon and I'll work over that.
--
You received this message because you are subscribed to the Google Groups Mezzanine
Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
I’m not sure what you’re implying about toggling the translation fields. If
it is about shrinking every translation field into a single one with tabs
for each language, go ahead. I know that django-modeltranslation is
supposed to allow that but I never had it working. If it is about adding
Well, since it is now possible to mark settings for translation I thought
it would be a good idea to use it on SHOP_CURRENCY_LOCALE too. Obviously
non-editable settings don’t have a ``Setting`` instance and are thus
non-translatable. So I made SHOP_CURRENCY_LOCALE editable too. Since
Before I push a fix for #1 in my master, I have a question. But first, the
patch:
https://github.com/Kniyl/mezzanine/commit/4fdd125046a402054e6c9e12418f7997df5b146a
As you can see, the fix is simply to use ugettext instead of ugettext_lazy
for the default value. And (fortunately?) the
I learned something from #5. I’ll try to play with conf.models and see what
happens.
For #1, I was simply suggesting to change the text of the button. At least
for my setup, when the text is “Submit” for the english language or
“Wyślij” for polish, it display the french (default) button_text
commits for #2 and #4 have been pushed
Le mercredi 14 mai 2014 13:28:06 UTC+2, Mathias Ettinger a écrit :
I learned something from #5. I’ll try to play with conf.models and see
what happens.
For #1, I was simply suggesting to change the text of the button. At least
for my setup, when the
Aaaahh, I get what you mean for #1, and yes, changing the value in
non-default languages to something other than the direct translation of
Submit fixes it.
#2 and #4 look like they've been fixed, thanks a lot.
#5 is looking pretty great. However, I don't thinks SHOP_CURRENCY_LOCALE
should be
1. Well… In fact they are. But for some reason if the text is the active
translation for submit, then the default language field is displayed (i.e:
if my default language is french and I have Envoyer [fr]/Submit [en]/Wyślij
[pl] then Envoyer will be displayed for each
Sorry, I didn't understand your explanation on point 1. Could you
elaborate a little bit more? The issue I was describing is that the
Submit button is not showing the active language text in the form, but
rather the default language value.
About number 2, I actually had this working a while
Ok, I finally got some time to try this out. I've never used Model
Transaltion, so maybe I'm making some noob mistake. This is what I've done:
mkvirtualenv modeltranslation
git clone https://github.com/Kniyl/mezzanine.git mt-mezzanine
cd mt-mezzanine
pip install -e .
pip install south
Just before running createdb, one has to cd mt_test, of course.
--
You received this message because you are subscribed to the Google Groups
Mezzanine Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to mezzanine-users+unsubscr...@googlegroups.com.
I couldn't reproduce until I installed django-debug-toolbar.
I’ll try to dig into it latter but can you confirm that uninstalling (or
removing it from the settings) django-debug-toolbar solves the problem ?
Le lundi 12 mai 2014 18:54:14 UTC+2, Eduardo Rivas a écrit :
Ok, I finally got some
Yep, that's it. Removing debug toolbar fixes it.
I'll continue testing and reporting back anything I find. Thanks a lot for
this!
--
You received this message because you are subscribed to the Google Groups
Mezzanine Users group.
To unsubscribe from this group and stop receiving emails from
I've really been looking forward to this one. Hopefully I will have time to
try it out with the development version of some sites that currently use
alternative translation approaches.
Are we going to translate urls at all? Django gives two possible choices:
mark the url patterns for
Probably a good question for Mathias on the github thread.
On Wed, Apr 30, 2014 at 2:34 AM, Eduardo Rivas jerivasmel...@gmail.comwrote:
I've really been looking forward to this one. Hopefully I will have time
to try it out with the development version of some sites that currently use
+1 on postponing, only for the sake of keeping the iterations as small as
possible.
On Wed, Apr 30, 2014 at 8:18 AM, Mathias Ettinger
mathias.ettin...@gmail.com wrote:
Le mardi 29 avril 2014 18:34:58 UTC+2, Eduardo Rivas a écrit :
Django gives two possible choices: mark the url patterns for
34 matches
Mail list logo
