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.
