Fair enough - just wanted to make sure something simpler hadn't been overlooked.
On Tue, May 27, 2014 at 12:30 AM, Mathias Ettinger < [email protected]> 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 <[email protected] >> > 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 [email protected]. >>> >>> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
