Re: [mezzanine-users] Re: modeltranslations - round 2
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 ``mezzanine.conf.settings`` manages it I such a way that if the setting is defined in settings.py it is considered non-editable whatever ``register_setting`` says, I guess it does not change anything when upgrading mezzanine/cartridge. If SHOP_CURRENCY_LOCALE was defined in settings.py, it will still keep its value, otherwise it won't have any value and will fallback for the systeme locale for any language. But the latter will enable the translatable admin. But I can be wrong. As for South, the issue is exactly the same than field injection: http://mezzanine.jupo.org/docs/model-customization.html#field-injection-caveats Either you use the same solution, or you use the management commands provided by django-modeltranslation (./manage.py sync-translation-fields and optionnaly ./manage.py update-translation-fields). Le jeudi 15 mai 2014 03:38:03 UTC+2, Eduardo Rivas a écrit : 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 translatable, since it is not editable, and non-editable settings don't have DB entries (I think). The other problem I see is that users will have to run python manage.py schemamigration conf --auto every time they add a new language. Also, these migrations seem to be stored in Mezzanine's source so they might be a problem for upgrades and deployment. At least that's what I had to do to get rid of a column does not exist error. Am I missing something? -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [mezzanine-users] Re: modeltranslations - round 2
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 mezzanine.form.models.Form.button_text field is the only one to define a default value that is a translation string. My question, though, is: “Should we keep this default value?” because, in the end, django-modeltranslation will populate all the fields with the active language translation of that string. It is however possible to keep the default value when mezzanine.conf.TRANSLATED is False. I have an other question about the use of ugettext_lazy in the first place. I’m wondering why it is required and if it wouldn’t be easier to just import ugettext as _ instead of ugettext_lazy. I might confess that I’m not well aware of their differences. Le jeudi 15 mai 2014 10:57:13 UTC+2, Mathias Ettinger a écrit : 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 ``mezzanine.conf.settings`` manages it I such a way that if the setting is defined in settings.py it is considered non-editable whatever ``register_setting`` says, I guess it does not change anything when upgrading mezzanine/cartridge. If SHOP_CURRENCY_LOCALE was defined in settings.py, it will still keep its value, otherwise it won't have any value and will fallback for the systeme locale for any language. But the latter will enable the translatable admin. But I can be wrong. As for South, the issue is exactly the same than field injection: http://mezzanine.jupo.org/docs/model-customization.html#field-injection-caveats Either you use the same solution, or you use the management commands provided by django-modeltranslation (./manage.py sync-translation-fields and optionnaly ./manage.py update-translation-fields). Le jeudi 15 mai 2014 03:38:03 UTC+2, Eduardo Rivas a écrit : 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 translatable, since it is not editable, and non-editable settings don't have DB entries (I think). The other problem I see is that users will have to run python manage.py schemamigration conf --auto every time they add a new language. Also, these migrations seem to be stored in Mezzanine's source so they might be a problem for upgrades and deployment. At least that's what I had to do to get rid of a column does not exist error. Am I missing something? -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [mezzanine-users] Mezzanine under url prefix
I have a question in regards to this topic as well. I need to move our website under a site prefix (long story) - I have defined the site prefix in settings.py and have made the necessary changes in urls.py as well. The pages of the site are all working under the prefix. However, is there a way to also move admin portion of mezzanine behind the prefix as well? Is it just a matter of moving things around in the template files? thanks, Scott On Thursday, February 14, 2013 5:53:33 PM UTC-8, Stephen McDonald wrote: Should generally work. On Fri, Feb 15, 2013 at 12:06 PM, Eduardo Rivas jeriva...@gmail.comjavascript: wrote: Hello, I'm in need of deploying a Mezzanine site under a URL prefix, let's say example.com/somepage. The domain connects to a server already running Wordpress, and Mezzanine most only live in this subpage. I think the question goes beyond the scope of this group, but I'm hoping someone else has already done something like this: - The domain is not owned by me, and I don't have control over it. Is it possible for the managers of the other server to redirect example.com/somepage to the Django instance in my server, preserving the url? They should be able to configure the web server to proxy to the django app - Is Mezzanine ready to run this way? Is it as simple as defining SITE_PREFIX? That's the intention. Thanks in advance! -- 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-use...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- Stephen McDonald http://jupo.org -- 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. For more options, visit https://groups.google.com/d/optout.
