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 [email protected]. For more options, visit https://groups.google.com/d/optout.
