[mezzanine-users] Re: modeltranslations - round 2
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, 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 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.
[mezzanine-users] Re: modeltranslations - round 2
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 https://github.com/Kniyl/mezzanine/blob/master/mezzanine/core/templates/includes/language_selector.html#L3, as settings.USE_MODELTRANSLATION won't be available in the template context unless explicitly added to TEMPLATE_ACCESSIBLE_SETTINGS, thus, it always returns False and the template is never rendered. Relevant page http://mezzanine.jupo.org/docs/configuration.html#template-accessible-settings in the official docs. While we are at this, I'm unsure how contributions to forks work. It seems I cannot make pull requests to Mathias' fork. Maybe because it has never been merged into Steve's repo (the upstream repo)? Anyways, I've made the necessary edits here https://github.com/jerivas/mezzanine/commit/5a4fa67dbba7a4aed493535c28fc991b0f1a3d61, guess you'll have to manually copy it to your repo, Mathias. I'm not sure if core.defaults is the best place to put this, let me know what you guys think. -- 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.
[mezzanine-users] Re: modeltranslations - round 2
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 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.
[mezzanine-users] Re: modeltranslations - round 2
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 fork which I'm attempting to
address as I go. For example https://github.com/cccs-web/mezzanine/issues/1
My question is; Is this a good approach, given that I need a pragmatic
solution but also want to be maximally helpful to getting any fixes into
the mezzanine code base?
On Tuesday, 10 June 2014 22:42:41 UTC+10, Mathias Ettinger wrote:
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 else to do in order to get it working?
If it is not possible to show extra area like this that are hidden by
default, we definitely need to write our own custom class on top of
TranslationAdmin (meaning: core.BaseTranslationModelAdmin). I’m also unsure
if Translation{Tabular,Stacked}Inline also need to integrates some
tabbing-awareness code (wether it is a global switch or a per field one).
But I modified a little bit their admin classes to help integrate it if
needed.
Le samedi 7 juin 2014 02:26:50 UTC+2, Eduardo Rivas a écrit :
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
https://django-modeltranslation.readthedocs.org/en/latest/admin.html#tabbed-translation-fields-admin-classes)
to include the required static resources for this purpose:
TabbedTranslationAdmin
and TabbedExternalJqueryTranslationAdmin. The first one seems to fail as
it uses Django's jQuery, but the second one works as expected (though it
looks kinda ugly in Grappelli) by using external jQuery resources.
I have a couple of questions at this point:
1. Should we use these classes or create our own (considering
Mezzanine already includes jQuery and jQuery UI)?
2. Should we create a toggle for each field (as MT does), or just a
global toggle to hide/show all fields of a specified language? I favor
the second option, as giving each field it's own toggle seems overly
messy
and confusing for the end user.
Hope to hear from you soon. BTW, if you want to try out MT's default
implementation, simply replace all occurrences of TranslationAdmin with
TabbedExternalJqueryTranslationAdmin
in mezzanine.core.admin.
--
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.
[mezzanine-users] Re: modeltranslations - round 2
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 else to do in order to get it working?
If it is not possible to show extra area like this that are hidden by
default, we definitely need to write our own custom class on top of
TranslationAdmin (meaning: core.BaseTranslationModelAdmin). I’m also unsure
if Translation{Tabular,Stacked}Inline also need to integrates some
tabbing-awareness code (wether it is a global switch or a per field one).
But I modified a little bit their admin classes to help integrate it if
needed.
Le samedi 7 juin 2014 02:26:50 UTC+2, Eduardo Rivas a écrit :
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
https://django-modeltranslation.readthedocs.org/en/latest/admin.html#tabbed-translation-fields-admin-classes)
to include the required static resources for this purpose:
TabbedTranslationAdmin
and TabbedExternalJqueryTranslationAdmin. The first one seems to fail as
it uses Django's jQuery, but the second one works as expected (though it
looks kinda ugly in Grappelli) by using external jQuery resources.
I have a couple of questions at this point:
1. Should we use these classes or create our own (considering
Mezzanine already includes jQuery and jQuery UI)?
2. Should we create a toggle for each field (as MT does), or just a
global toggle to hide/show all fields of a specified language? I favor
the second option, as giving each field it's own toggle seems overly messy
and confusing for the end user.
Hope to hear from you soon. BTW, if you want to try out MT's default
implementation, simply replace all occurrences of TranslationAdmin with
TabbedExternalJqueryTranslationAdmin
in mezzanine.core.admin.
--
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
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 javascript: 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 these things to involve some iterations :-) As for the TRANSLATED setting, I don’t recall exactly why I tied it with USE_I18N. If I’m correct, it is because django-modeltranslation deactivates itself when USE_I18N is False. So we can’t relly solely on USE_MODELTRANSLATION to know when translations are activated. I’ll check that by tomorow and let you know. But if it is the case, what is your suggested approach ? Force the USE_I18N to True if USE_MODELTRANSLATION is True ? Tighten TRANSLATED into settings instead of a global var ? So if modeltranslations needs USE_I18N then that's fine - let's just comment that in the code where we deal with it. I guess what I was getting at was that we should try and have this configurable via a single point, namely USE_MODELTRANSLATION - we can handle all the rest in set_dynamic_settings. There we can check if USE_MODELTRANSLATION is True and if so, also check that we can import modeltranslations, and then with that in place we can do the rest - set USE_I18N to True, and add modeltranslations to INSTALLED_APPS if missing. After that we can reliably use mezzanine.conf.settings.USE_MODELTRANSLATION *everywhere* to control integration (such as which admin class to use, what appears on the front-end, etc). Le samedi 7 juin 2014 12:09:02 UTC+2, Stephen McDonald a écrit : 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 BaseAdmin class with this logic that everything subclasses, rather than having conditions all throughout the code base. With that in place I figure it'd be pretty easy for us to modify that base class to include a snippet of jQuery with a single toggle (eg per screen, not per field, as Ed suggested) that shows/hides all the language fields. Also confused about the end of mezzanine/conf/__init__: TRANSLATED = settings.USE_MODELTRANSLATION and settings.USE_I18N CODE_LIST = [lang[0] for lang in settings.LANGUAGES] This isn't where settings should simply be dumped. CODE_LIST could possibly be a function in mezzanine.utils.translation. Does Django not have this already? More importantly I don't understand the relationship between USE_MODELTRANSLATION and USE_I18N, and why these get combined into another setting (which isn't consistently used throughout the PR, in same cases this combo of settings get checked separately again). Can't everything just check the USE_MODELTRANSLATION settings? If USE_I18N is needed for this to work, then that's what's set_dynamic_settings is for - fixing up missing things that the developer has intended to have working by providing a single point of configuration that hides away all the various bits that need configuring. In set_dynamic_settings we should simply check for USE_MODELTRANSLATION and if True, add modeltranslation app if missing, and if USE_I18N actually needs to be True for modeltranslation to work, set it to True as well. modeltranslation shouldn't be in INSTALLED_APPS by default either. Lastly we probably don't want the language chooser for the front-end site in the top nav, there's really no room there. Perhaps it could sit on the right-hand panel at the top somewhere along with the login bits, conditionally, if USE_MODELTRANSLATION is True. All of this stuff should be turned off by default which means USE_MODELTRANSLATION defaults to False and *everything* else stems from that. If I've stupidly overlooked anything please let me know. This looks real promising and I'm hoping this along with django-rest-framework integration will make a compelling offering for the next major release 3.2. I'm going to push 3.1.5 shortly with some bug fixes, and hopefully that'll be the last 3.1.x release. Thanks Mathias and Ed for working this all out, it looks really really good. On Sat, Jun 7, 2014 at 2:31 PM, Stephen McDonald st...@jupo.org wrote: 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 jeriva...@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
Re: [mezzanine-users] Re: modeltranslations - round 2
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 django-modeltranslation deactivates itself when USE_I18N is False. So we can’t relly solely on USE_MODELTRANSLATION to know when translations are activated. I’ll check that by tomorow and let you know. But if it is the case, what is your suggested approach ? Force the USE_I18N to True if USE_MODELTRANSLATION is True ? Tighten TRANSLATED into settings instead of a global var ? Le samedi 7 juin 2014 12:09:02 UTC+2, Stephen McDonald a écrit : 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 BaseAdmin class with this logic that everything subclasses, rather than having conditions all throughout the code base. With that in place I figure it'd be pretty easy for us to modify that base class to include a snippet of jQuery with a single toggle (eg per screen, not per field, as Ed suggested) that shows/hides all the language fields. Also confused about the end of mezzanine/conf/__init__: TRANSLATED = settings.USE_MODELTRANSLATION and settings.USE_I18N CODE_LIST = [lang[0] for lang in settings.LANGUAGES] This isn't where settings should simply be dumped. CODE_LIST could possibly be a function in mezzanine.utils.translation. Does Django not have this already? More importantly I don't understand the relationship between USE_MODELTRANSLATION and USE_I18N, and why these get combined into another setting (which isn't consistently used throughout the PR, in same cases this combo of settings get checked separately again). Can't everything just check the USE_MODELTRANSLATION settings? If USE_I18N is needed for this to work, then that's what's set_dynamic_settings is for - fixing up missing things that the developer has intended to have working by providing a single point of configuration that hides away all the various bits that need configuring. In set_dynamic_settings we should simply check for USE_MODELTRANSLATION and if True, add modeltranslation app if missing, and if USE_I18N actually needs to be True for modeltranslation to work, set it to True as well. modeltranslation shouldn't be in INSTALLED_APPS by default either. Lastly we probably don't want the language chooser for the front-end site in the top nav, there's really no room there. Perhaps it could sit on the right-hand panel at the top somewhere along with the login bits, conditionally, if USE_MODELTRANSLATION is True. All of this stuff should be turned off by default which means USE_MODELTRANSLATION defaults to False and *everything* else stems from that. If I've stupidly overlooked anything please let me know. This looks real promising and I'm hoping this along with django-rest-framework integration will make a compelling offering for the next major release 3.2. I'm going to push 3.1.5 shortly with some bug fixes, and hopefully that'll be the last 3.1.x release. Thanks Mathias and Ed for working this all out, it looks really really good. On Sat, Jun 7, 2014 at 2:31 PM, Stephen McDonald st...@jupo.org javascript: wrote: 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 jeriva...@gmail.com javascript: wrote: 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 html5lib==0.999 oauthlib==0.6.1 psycopg2==2.5.3 pytz==2014.4 requests==2.3.0 requests-oauthlib==0.4.0 six==1.6.1 sqlparse==0.1.11 tzlocal==1.0 wsgiref==0.1.2 I ran mezzanine-project and createdb --noinput. Have you done any other changes to settings? -- 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/d/optout. -- Stephen McDonald http://jupo.org -- 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.
Re: [mezzanine-users] Re: modeltranslations - round 2
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 these things to involve some iterations :-) As for the TRANSLATED setting, I don’t recall exactly why I tied it with USE_I18N. If I’m correct, it is because django-modeltranslation deactivates itself when USE_I18N is False. So we can’t relly solely on USE_MODELTRANSLATION to know when translations are activated. I’ll check that by tomorow and let you know. But if it is the case, what is your suggested approach ? Force the USE_I18N to True if USE_MODELTRANSLATION is True ? Tighten TRANSLATED into settings instead of a global var ? So if modeltranslations needs USE_I18N then that's fine - let's just comment that in the code where we deal with it. I guess what I was getting at was that we should try and have this configurable via a single point, namely USE_MODELTRANSLATION - we can handle all the rest in set_dynamic_settings. There we can check if USE_MODELTRANSLATION is True and if so, also check that we can import modeltranslations, and then with that in place we can do the rest - set USE_I18N to True, and add modeltranslations to INSTALLED_APPS if missing. After that we can reliably use mezzanine.conf.settings.USE_MODELTRANSLATION *everywhere* to control integration (such as which admin class to use, what appears on the front-end, etc). Le samedi 7 juin 2014 12:09:02 UTC+2, Stephen McDonald a écrit : 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 BaseAdmin class with this logic that everything subclasses, rather than having conditions all throughout the code base. With that in place I figure it'd be pretty easy for us to modify that base class to include a snippet of jQuery with a single toggle (eg per screen, not per field, as Ed suggested) that shows/hides all the language fields. Also confused about the end of mezzanine/conf/__init__: TRANSLATED = settings.USE_MODELTRANSLATION and settings.USE_I18N CODE_LIST = [lang[0] for lang in settings.LANGUAGES] This isn't where settings should simply be dumped. CODE_LIST could possibly be a function in mezzanine.utils.translation. Does Django not have this already? More importantly I don't understand the relationship between USE_MODELTRANSLATION and USE_I18N, and why these get combined into another setting (which isn't consistently used throughout the PR, in same cases this combo of settings get checked separately again). Can't everything just check the USE_MODELTRANSLATION settings? If USE_I18N is needed for this to work, then that's what's set_dynamic_settings is for - fixing up missing things that the developer has intended to have working by providing a single point of configuration that hides away all the various bits that need configuring. In set_dynamic_settings we should simply check for USE_MODELTRANSLATION and if True, add modeltranslation app if missing, and if USE_I18N actually needs to be True for modeltranslation to work, set it to True as well. modeltranslation shouldn't be in INSTALLED_APPS by default either. Lastly we probably don't want the language chooser for the front-end site in the top nav, there's really no room there. Perhaps it could sit on the right-hand panel at the top somewhere along with the login bits, conditionally, if USE_MODELTRANSLATION is True. All of this stuff should be turned off by default which means USE_MODELTRANSLATION defaults to False and *everything* else stems from that. If I've stupidly overlooked anything please let me know. This looks real promising and I'm hoping this along with django-rest-framework integration will make a compelling offering for the next major release 3.2. I'm going to push 3.1.5 shortly with some bug fixes, and hopefully that'll be the last 3.1.x release. Thanks Mathias and Ed for working this all out, it looks really really good. On Sat, Jun 7, 2014 at 2:31 PM, Stephen McDonald st...@jupo.org wrote: 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 jeriva...@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 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 html5lib==0.999 oauthlib==0.6.1 psycopg2==2.5.3 pytz==2014.4 requests==2.3.0 requests-oauthlib==0.4.0 six==1.6.1
Re: [mezzanine-users] Re: modeltranslations - round 2
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 BaseAdmin class with this logic that everything subclasses, rather than having conditions all throughout the code base. With that in place I figure it'd be pretty easy for us to modify that base class to include a snippet of jQuery with a single toggle (eg per screen, not per field, as Ed suggested) that shows/hides all the language fields. Also confused about the end of mezzanine/conf/__init__: TRANSLATED = settings.USE_MODELTRANSLATION and settings.USE_I18N CODE_LIST = [lang[0] for lang in settings.LANGUAGES] This isn't where settings should simply be dumped. CODE_LIST could possibly be a function in mezzanine.utils.translation. Does Django not have this already? More importantly I don't understand the relationship between USE_MODELTRANSLATION and USE_I18N, and why these get combined into another setting (which isn't consistently used throughout the PR, in same cases this combo of settings get checked separately again). Can't everything just check the USE_MODELTRANSLATION settings? If USE_I18N is needed for this to work, then that's what's set_dynamic_settings is for - fixing up missing things that the developer has intended to have working by providing a single point of configuration that hides away all the various bits that need configuring. In set_dynamic_settings we should simply check for USE_MODELTRANSLATION and if True, add modeltranslation app if missing, and if USE_I18N actually needs to be True for modeltranslation to work, set it to True as well. modeltranslation shouldn't be in INSTALLED_APPS by default either. Lastly we probably don't want the language chooser for the front-end site in the top nav, there's really no room there. Perhaps it could sit on the right-hand panel at the top somewhere along with the login bits, conditionally, if USE_MODELTRANSLATION is True. All of this stuff should be turned off by default which means USE_MODELTRANSLATION defaults to False and *everything* else stems from that. If I've stupidly overlooked anything please let me know. This looks real promising and I'm hoping this along with django-rest-framework integration will make a compelling offering for the next major release 3.2. I'm going to push 3.1.5 shortly with some bug fixes, and hopefully that'll be the last 3.1.x release. Thanks Mathias and Ed for working this all out, it looks really really good. On Sat, Jun 7, 2014 at 2:31 PM, Stephen McDonald st...@jupo.org wrote: 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 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 html5lib==0.999 oauthlib==0.6.1 psycopg2==2.5.3 pytz==2014.4 requests==2.3.0 requests-oauthlib==0.4.0 six==1.6.1 sqlparse==0.1.11 tzlocal==1.0 wsgiref==0.1.2 I ran mezzanine-project and createdb --noinput. Have you done any other changes to settings? -- 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. -- Stephen McDonald http://jupo.org -- 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.
[mezzanine-users] Re: modeltranslations - round 2
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 https://django-modeltranslation.readthedocs.org/en/latest/admin.html#tabbed-translation-fields-admin-classes) to include the required static resources for this purpose: TabbedTranslationAdmin and TabbedExternalJqueryTranslationAdmin. The first one seems to fail as it uses Django's jQuery, but the second one works as expected (though it looks kinda ugly in Grappelli) by using external jQuery resources. I have a couple of questions at this point: 1. Should we use these classes or create our own (considering Mezzanine already includes jQuery and jQuery UI)? 2. Should we create a toggle for each field (as MT does), or just a global toggle to hide/show all fields of a specified language? I favor the second option, as giving each field it's own toggle seems overly messy and confusing for the end user. Hope to hear from you soon. BTW, if you want to try out MT's default implementation, simply replace all occurrences of TranslationAdmin with TabbedExternalJqueryTranslationAdmin in mezzanine.core.admin. -- 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
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 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 https://django-modeltranslation.readthedocs.org/en/latest/admin.html#tabbed-translation-fields-admin-classes) to include the required static resources for this purpose: TabbedTranslationAdmin and TabbedExternalJqueryTranslationAdmin. The first one seems to fail as it uses Django's jQuery, but the second one works as expected (though it looks kinda ugly in Grappelli) by using external jQuery resources. I have a couple of questions at this point: 1. Should we use these classes or create our own (considering Mezzanine already includes jQuery and jQuery UI)? 2. Should we create a toggle for each field (as MT does), or just a global toggle to hide/show all fields of a specified language? I favor the second option, as giving each field it's own toggle seems overly messy and confusing for the end user. Hope to hear from you soon. BTW, if you want to try out MT's default implementation, simply replace all occurrences of TranslationAdmin with TabbedExternalJqueryTranslationAdmin in mezzanine.core.admin. -- 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. -- 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.
[mezzanine-users] Re: modeltranslations - round 2
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 html5lib==0.999 oauthlib==0.6.1 psycopg2==2.5.3 pytz==2014.4 requests==2.3.0 requests-oauthlib==0.4.0 six==1.6.1 sqlparse==0.1.11 tzlocal==1.0 wsgiref==0.1.2 I ran mezzanine-project and createdb --noinput. Have you done any other changes to settings? -- 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
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 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 html5lib==0.999 oauthlib==0.6.1 psycopg2==2.5.3 pytz==2014.4 requests==2.3.0 requests-oauthlib==0.4.0 six==1.6.1 sqlparse==0.1.11 tzlocal==1.0 wsgiref==0.1.2 I ran mezzanine-project and createdb --noinput. Have you done any other changes to settings? -- 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. -- 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.
Re: [mezzanine-users] Re: modeltranslations - round 2
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 we want a tight integration. First off all, the field duplication issue mentionned in the project is directly handled when modifying mezzanine and using the right base classes for the admin. As opposed to either patch django-modeltranslation or add redundant information in the translation.py file. Then, the form submit button issue requires a (minor) modification to mezzanine to works properly. Both the slugs being generated for the active language issue and the language selection on the frontend site need mezzanine to be aware of modeltranslation to work. Or at least mezzanine should consider the USE_I18N setting for these tasks. Translatable settings such as SITE_TITLE or SITE_TAGLINE would be a pain in the ass to handle from an external app. Needless to say it would be even harder to make it support custom translatable settings (those defined in an external app default.py). With this implementation it comes out of the box. I understand your reasoning in the sense that: the less file we modify, the less error-prone it will be and the less cumbersome it will be to maintain. But I have the feeling that a tighter integration will both make issues easier to spot and fix and ease the development of future features with translation needs. As an example, the pull request I made for cartridge compared to the two-files approach I proposed in the bug tracker ( https://gist.github.com/Kniyl/11249940). Defining model methods outside of their class is anything but a good idea. That is why I spend my time trying to provide the best approach within mezzanine: I’d like to get rid off the ugly external app that I’m using. I’m also confident that this work is very close to completion. Missing features are: translation field for keywords (that I don’t know how to handle, yet), translation field for slug (that need further discussion) and a nice tab-based grouping of fields in the admin (that Eduardo plan on doing). The only concern for now is about where to put the translation validation logic. In my opinion, the admin is a good place rather than in the model, because it lets people who knows what they are doing achieve their goals more easily. But I might be wrong. Le lundi 26 mai 2014 15:24:50 UTC+2, Stephen McDonald a écrit : Any thoughts on this implementation? https://github.com/Romamo/mezzanine-modeltranslation/blob/master/ mezzaninemodeltranslation/translation.py It was mentioned in the discussion against the pull request but no comments were made. I really like how this approach doesn't require any change to Mezzanine itself, as opposed to the proposal here which is a real concern. On Mon, May 26, 2014 at 10:52 PM, Mathias Ettinger mathias@gmail.com wrote: I need to take a decision, so I’ll ask here instead. I was trying to write some tests for modeltranslation integration and I stumbled upon an issue. Basically I was trying to test that slugs are always generated based on the default language using the model logic (Page.save()) whereas the slug issue was fixed using the admin logic (ModelAdmin.save_model()). Obviously my test fails. But I’m wondering wether it should be fixed by testing the admin behavior or by implementing the slug logic into the Page model. As a more general question, there are some fields that are auto-populated based on other one and both are marked for translation. They are handled by the admin which saves the model several times (one for each language). Is it acceptable or should this logic be moved to the Displayable model? -- 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. For more options, visit https://groups.google.com/d/optout. -- 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. -- 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.
Re: [mezzanine-users] Re: modeltranslations - round 2
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 it is good enough for an external app, but not so good if we want a tight integration. First off all, the field duplication issue mentionned in the project is directly handled when modifying mezzanine and using the right base classes for the admin. As opposed to either patch django-modeltranslation or add redundant information in the translation.py file. Then, the form submit button issue requires a (minor) modification to mezzanine to works properly. Both the slugs being generated for the active language issue and the language selection on the frontend site need mezzanine to be aware of modeltranslation to work. Or at least mezzanine should consider the USE_I18N setting for these tasks. Translatable settings such as SITE_TITLE or SITE_TAGLINE would be a pain in the ass to handle from an external app. Needless to say it would be even harder to make it support custom translatable settings (those defined in an external app default.py). With this implementation it comes out of the box. I understand your reasoning in the sense that: the less file we modify, the less error-prone it will be and the less cumbersome it will be to maintain. But I have the feeling that a tighter integration will both make issues easier to spot and fix and ease the development of future features with translation needs. As an example, the pull request I made for cartridge compared to the two-files approach I proposed in the bug tracker ( https://gist.github.com/Kniyl/11249940). Defining model methods outside of their class is anything but a good idea. That is why I spend my time trying to provide the best approach within mezzanine: I’d like to get rid off the ugly external app that I’m using. I’m also confident that this work is very close to completion. Missing features are: translation field for keywords (that I don’t know how to handle, yet), translation field for slug (that need further discussion) and a nice tab-based grouping of fields in the admin (that Eduardo plan on doing). The only concern for now is about where to put the translation validation logic. In my opinion, the admin is a good place rather than in the model, because it lets people who knows what they are doing achieve their goals more easily. But I might be wrong. Le lundi 26 mai 2014 15:24:50 UTC+2, Stephen McDonald a écrit : Any thoughts on this implementation? https://github.com/Romamo/mezzanine-modeltranslation/blob/master/ mezzaninemodeltranslation/translation.py It was mentioned in the discussion against the pull request but no comments were made. I really like how this approach doesn't require any change to Mezzanine itself, as opposed to the proposal here which is a real concern. On Mon, May 26, 2014 at 10:52 PM, Mathias Ettinger mathias@gmail.com wrote: I need to take a decision, so I’ll ask here instead. I was trying to write some tests for modeltranslation integration and I stumbled upon an issue. Basically I was trying to test that slugs are always generated based on the default language using the model logic (Page.save()) whereas the slug issue was fixed using the admin logic (ModelAdmin.save_model()). Obviously my test fails. But I’m wondering wether it should be fixed by testing the admin behavior or by implementing the slug logic into the Page model. As a more general question, there are some fields that are auto-populated based on other one and both are marked for translation. They are handled by the admin which saves the model several times (one for each language). Is it acceptable or should this logic be moved to the Displayable model? -- 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. For more options, visit https://groups.google.com/d/optout. -- 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. -- 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.
Re: [mezzanine-users] Re: modeltranslations - round 2
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 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
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 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
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 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
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 mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [mezzanine-users] Re: modeltranslations - round 2
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 translation fields for conf.Setting that need them (instead of the patchy note that I added lately), I plan to do it this weekend. As regard to the tests, at first I thought that it wasn’t necessary since django-modeltranslation has its own test coverage. But adding a test for each of the 4 items that were corrected plus another one to check if the TRANSLATED flag is correctly set is a good start. Le mardi 20 mai 2014 03:10:07 UTC+2, Eduardo Rivas a écrit : Hey Mathias, a couple of points here. First, do you plan on working on the admin controls for toggling the different translations fields? I'm asking because I'll have some free time in the coming weeks, but I don't want to jump into it if you're planning on doing it yourself. Secondly, I wanted to share with you that recently an effort has started to improve Mezzanine's test coverage. It'd be great if you could write some tests for the features you've contributed; but if you're short on time, just coming up with a list of pending tests for model translation will be of great help. You can share it with me or Steve and they'll be added to the task list. Thanks a lot! 2014-05-19 10:04 GMT-06:00 Mathias Ettinger mathias@gmail.comjavascript: : I read a bit on ugettext and ugettext_lazy and I agree that we should not move everything to plain ugettext. Using ugettext for the default value seems perfectly acceptable though. Since pregenerated content into the database is populated using the default language translation, it is exactly the same behavior. And django-modeltranslation will copy value based on that translation anyway. (./manage.py update_translation_fields) I found the time to make a last change to the settings admin page. It’s far from perfect, I have an idea on how to make it more like pages with every fields exposed but not much time for that. And at least it’s better than nothing. -- You received this message because you are subscribed to a topic in the Google Groups Mezzanine Users group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/mezzanine-users/VXVfCU8OFGk/unsubscribe . To unsubscribe from this group and all its topics, send an email to mezzanine-use...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- 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
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] Re: modeltranslations - round 2
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 field whatever the active language is. But if I change the text to something else, it gets displayed properly. Le mardi 13 mai 2014 22:49:28 UTC+2, Eduardo Rivas a écrit : 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 back using Django's set_languagehttps://docs.djangoproject.com/en/dev/topics/i18n/translation/#set-language-redirect-viewview. I created a gist https://gist.github.com/jerivas/8f9873c36cd8a895cd4a with some code that can go directly into base.html or (even better) in a small template in includes/. Please note that settings.USE_I18N must be included in TEMPLATE_ACCESSIBLE_SETTINGS. Finally, the reason I brought up #5 was because some Settings are indeed model instances stored in the database. See: https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/conf/models.py. However, they are a special case, as we wouldn't want to translate all Settings instances. It would be good to include it in the ToDo just to keep it in mind. -- 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
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 text is “Submit” for the english language or “Wyślij” for polish, it display the french (default) button_text field whatever the active language is. But if I change the text to something else, it gets displayed properly. Le mardi 13 mai 2014 22:49:28 UTC+2, Eduardo Rivas a écrit : 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 back using Django's set_languagehttps://docs.djangoproject.com/en/dev/topics/i18n/translation/#set-language-redirect-viewview. I created a gist https://gist.github.com/jerivas/8f9873c36cd8a895cd4a with some code that can go directly into base.html or (even better) in a small template in includes/. Please note that settings.USE_I18N must be included in TEMPLATE_ACCESSIBLE_SETTINGS. Finally, the reason I brought up #5 was because some Settings are indeed model instances stored in the database. See: https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/conf/models.py. However, they are a special case, as we wouldn't want to translate all Settings instances. It would be good to include it in the ToDo just to keep it in mind. -- 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
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.
[mezzanine-users] Re: modeltranslations - round 2
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 languages. But Submission and W ysłać will be displayed properly for english and polish). Be creative and change this one, it will display well. I haven’t found why it behave this way, though. 2. Good one, I’ll add one in core/templates/base.html 3. I tried but it is more complicated than the others since field name and database column name does not match. I have no idea if it is possible to achieve and I won’t have enought time to try it soon. Maybe something to keep in a ToDoList. 4. Oh! Never ran into this one but you’re completely right. I’ll see what I can do. 5. They are not model fields so django-modeltranslation can’t handle them. Le mardi 13 mai 2014 17:06:43 UTC+2, Eduardo Rivas a écrit : Thanks Mathias, it is working now. I've used the site a little bit more and my first impressions are that translation is working like a charm! I've only found some minor issues/implementation details: 1. Form submit button is not being translated. 2. How do frontend users change the language? Perhaps we need a dropdown similar to the one in the admin for the public site. 3. Are keywords going to be translated? Not sure if this is just a matter of registering the Keywords field for translation. 4. Slugs are generated from the active language, not the default language. This only applies to new items which have their Title set in more than one language. For example, let's say we are logged into the admin in Spanish (default is English), and we have a new Page, and fill the Title with Hello world! (English) and ¡Hola mundo! (Spanish). The Page will get the Slug hola-mundo instead of hello-world. 5. Site tagline and site title; should they be made translatable? -- 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
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 back using Django's set_language https://docs.djangoproject.com/en/dev/topics/i18n/translation/#set-language-redirect-view view. I created a gist https://gist.github.com/jerivas/8f9873c36cd8a895cd4a with some code that can go directly into base.html or (even better) in a small template in includes/. Please note that settings.USE_I18N must be included in TEMPLATE_ACCESSIBLE_SETTINGS. Finally, the reason I brought up #5 was because some Settings are indeed model instances stored in the database. See: https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/conf/models.py. However, they are a special case, as we wouldn't want to translate all Settings instances. It would be good to include it in the ToDo just to keep it in mind. -- 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.
[mezzanine-users] Re: modeltranslations - round 2
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 django-modeltranslation django-debug-toolbar # cd to other folder mezzanine-project mt_test # Edit settings.py. Add USE_I18N = True, USE_L10N = True, add entries to LANGUAGES python manage.py createdb --noinput At this point, createdb fails with the following error: modeltranslation.translator.NotRegistered: The model RichTextPage is not registered for translation. See full tracebackhttp://pastebin.com/qqKEQZw1 . -- 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.
[mezzanine-users] Re: modeltranslations - round 2
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. For more options, visit https://groups.google.com/d/optout.
[mezzanine-users] Re: modeltranslations - round 2
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 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 django-modeltranslation django-debug-toolbar # cd to other folder mezzanine-project mt_test # Edit settings.py. Add USE_I18N = True, USE_L10N = True, add entries to LANGUAGES python manage.py createdb --noinput At this point, createdb fails with the following error: modeltranslation.translator.NotRegistered: The model RichTextPage is not registered for translation. See full tracebackhttp://pastebin.com/qqKEQZw1 . -- 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.
[mezzanine-users] Re: modeltranslations - round 2
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 it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[mezzanine-users] Re: modeltranslations - round 2
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 translation, or use i18n patterns to prefix the whole site's urls with a lang code (what the Admin currently does). Is Mezzanine going to favor any particular approach? -- 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
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 alternative translation approaches. Are we going to translate urls at all? Django gives two possible choices: mark the url patterns for translation, or use i18n patterns to prefix the whole site's urls with a lang code (what the Admin currently does). Is Mezzanine going to favor any particular approach? -- 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. -- 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.
Re: [mezzanine-users] Re: modeltranslations - round 2
+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 translation, or use i18n patterns to prefix the whole site's urls with a lang code (what the Admin currently does). Is Mezzanine going to favor any particular approach? I tend to prefer solutions that avoid marking slugs for translations since it will require extra tweakings to get every slug auto-populated from the title. I personnally use neither of theses approaches and rely on django sessions to change active language (with a setup very similar to https://docs.djangoproject.com/en/dev/topics/i18n/translation/#the-set-language-redirect-view). It is also possible to use both (translated slug with a lang code prefix) and will only require the same amount of work as translated slugs. Btw, I agree that we need to take a decision: with or without i18n_patterns? and with or without translated slugs? All four choices are valid. It is also possible to postpone this question and integrate translated slug (through a boolean setting?) into an other patch. As a side note, the language selector in the admin is gone in lattest version of mezzanine. Did I miss it somewhere or is the template not rendering it? -- 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. -- 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.
