modeltranslations - round 2

[Stephen McDonald]

Previously we tried to integrate django-modeltranslation with Mezzanine, but the integration was very lightweight and had a lot of edge cases, so without the manpower to get it working properly, it was removed at the time.

Now Mathias Ettinger has contributed a new attempt at this, and at a glance it looks much more complete. It will however need extremely thorough testing across all the difference features of Mezzanine before we can consider it. 

So this is just a general call to arms - if you can help out, please give it a try and see if you can break it (and if so, help fix it).

https://github.com/stephenmcd/mezzanine/pull/1019

Thanks

--
Stephen McDonald
http://jupo.org

[Eduardo Rivas]

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?

[Stephen McDonald]

Probably a good question for Mathias on the github thread.

On Wed, Apr 30, 2014 at 2:34 AM, Eduardo Rivas <jeriva...@gmail.com> wrote:

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-use...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mathias Ettinger]

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?

[Stephen McDonald]

+1 on postponing, only for the sake of keeping the iterations as small as possible.

--

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.

[Eduardo Rivas]

Mathias, if you've upgraded from pre 3.1.1 make sure you have USE_L10N = True in your settings module. I fell for that too after upgrading but Stephen cleared it up.

[Eduardo Rivas]

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 traceback.

[Eduardo Rivas]

Just before running createdb, one has to "cd mt_test", of course.

[Mathias Ettinger]

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 ?

[Eduardo Rivas]

Yep, that's it. Removing debug toolbar fixes it.

I'll continue testing and reporting back anything I find. Thanks a lot for this!

[Mathias Ettinger]

Latest commit should fix the error when debug_toolbar is installed/activated

[Eduardo Rivas]

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?

[Mathias Ettinger]

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 Wysł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.
   

[Eduardo Rivas]

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 view. I created a gist 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.

[Mathias Ettinger]

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.

[Mathias Ettinger]

commits for #2 and #4 have been pushed

[Mathias Ettinger]

Sorry for the third message in a row.

I implemented something for #5. It seems to work as expected but I’m not satisfied of the admin integration. For now, we can only change the value of translatable fields for the current language. So language switching has to be done and it is impossible to update every language for a field at once. I’ll try to mimic django-modeltranslation behavior to add several fields instead of one.

To have this working I added a new parameter to the register_setting function, called translatable. This value default to False and is set to True for SITE_TITLE, SITE_TAGLINE and SHOP_CURRENCY_LOCALE. Are there other settings that need this kind of behavior?

I’ll try to investigate possible causes for #1 in a couple of days. But I consider it a minor issue since adding a dot at the end of the button_text field makes it being translated (even though it might seem ugly).

[Eduardo Rivas]

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?

[Mathias Ettinger]

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).

[Mathias Ettinger]

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.

[Eduardo Rivas]

I've ran into similar situations with ugettext and ugettext_lazy. For example, when defining model methods to be called in the Django Admin, plain ugettext works better. The official docs recommend using the lazy option when dealing with most things model-related (https://docs.djangoproject.com/en/1.6/topics/i18n/translation/#lazy-translations).

My approach is to use ugettext_lazy by default in most of the backend, and use ugettext when problems like this arise. I don't think we should move everything to plain ugettext.

PS: Looking forward to reading what Steve has to say on all progress Mathias has made in this front.

[Mathias Ettinger]

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.

[Eduardo Rivas]

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.com>:

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.

[Eduardo Rivas]

Oops, I forgot to share the link to the task list: https://github.com/stephenmcd/mezzanine/issues/1012

[Mathias Ettinger]

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.

[Eduardo Rivas]

Great! Hopefully your commits will be merged soon and I'll work over that.

[Mathias Ettinger]

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?

[Eduardo Rivas]

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 :-)

[Eduardo Rivas]

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

[Mathias Ettinger]

Just ran into it too :)

I’ll set up some tests in the next couple days, then.

In the meantime, can you give me some feedback on my modeltranslationformissue branch (https://github.com/Kniyl/mezzanine/tree/modeltranslationformissue). It duplicates translatable settings in the admin for every language.

[Mathias Ettinger]

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?

[Stephen McDonald]

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.

--
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

[Mathias Ettinger]

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.

[Stephen McDonald]

Fair enough - just wanted to make sure something simpler hadn't been overlooked.

[Stephen McDonald]

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....@gmail.com> wrote:

[Eduardo Rivas]

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) 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.

[Stephen McDonald]

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.

--

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.

[Eduardo Rivas]

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?

[Stephen McDonald]

Real odd, works fine for me now and no matter what I try I can't reproduce the error I had.

--
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]

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.

[Mathias Ettinger]

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 ?

[Stephen McDonald]

On Sun, Jun 8, 2014 at 6:15 PM, Mathias Ettinger <mathias....@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).

[Mathias Ettinger]

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.

[Mathias Ettinger]

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.

[Paul Whipp]

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 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?

[Eduardo Rivas]

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, 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 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, 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.

[Paul Whipp]

Hi Eduardo,

Yes, it took me a while to find the source of the problem but it is sorted in the pull request.

You click on your own repo 'pull requests' to generate the pull request. I'm still fairly new to it myself but it is a very nice feature of github. Before generating the pull request you need to update your repo with the upstream branch to avoid complications.... and yes, you can only do the pull requests for your fork so steps further up are in the hands of those repo owners. You can probably 'short circuit' a non responsive upstream fork by forking Mathias's repo, merging our changes into it and generating a pull request from your new repo (I hope that makes sense - it sounds more complex than it actually is).

I've not had any problem with the front-end language selector - it is displaying fine on my pages because it is explicitly set up in the base template.

Cheers,

Paul

--
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.

[Eduardo Rivas]

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.

[Robin Wangsuyuan]

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.