Admin: use tabs to separate translations about django-modeltranslation HOT 25 CLOSED

From eschler on July 08, 2010 10:43:26
Tabs are a very nice feature and they should be added to modeltranslation in one way or another. I strongly feel that they have to be optional though (like any other change to the admin). Many people use customized admins already and will have a hard time to remove modifications by modeltranslation in case they don't want to use them.

The way issue 23 adds support for google suggest for instance is how it should be done in my opinion. If you want the support, include it in your custom admin.py. In r85 i've committed a patch to add modeltranslation specific css classes to a translation field. The JavaScript should be adopted to make use of it so that it doesn't depend on issue 38.

from django-modeltranslation.

From [email protected] on July 08, 2010 13:25:28
The CSS class on the fields is only of limited use because we still need some sort of grouping mechanism and hoisting the fields out of their containing fieldsets involves a fair number of assumptions about the template HTML structure.

I've changed the patch to instead - now nothing changes unless you set use_tabs = True in your TranslationOptions.

http://github.com/acdha/django-modeltranslation/commit/9e92777ea04d118fdaa05c4dce0f07102b41f533

from django-modeltranslation.

From eschler on July 08, 2010 21:10:25
This is better, but doesn't fully address the issue. The media files are still injected. It might sound like the right thing in first place, but if you think about it, it raises a few problems:

• If the media files are already included somewhere else in your admin (the cms we use at work includes the ui libs for instance), then they will be requested twice. And chances are good that these are different versions which can lead to additional side effects.
• The files are included from google (which isn't a bad thing in general!). You might however be building an intranet project which isn't even allowed to request external files.

So i would leave the whole decision what media files to include at which point to the user. Again, the example by jaap in issue 23 (comment 3) is the way i would handle it.

What you said about the field class is right of course. I've started working on my own jquery-ui-based tabs implementation some time ago. It adds an additional css class for each group of translation fields (build from the fieldname). The only assumption it makes is that the translation field is wrapped in a container with a form-row class. The rest is handled in a static js include, no modification to the template needed. With this solution it wouldn't be even necessary to have an option like use_tabs. If you want the tabs, just include the js (and the required libs in case you don't have them already) in your admin class.

The implementation isn't finished, it turned out to be somewhat tricky on the js side. So i have to see if my vision of tabs is really doable. :)

from django-modeltranslation.

From [email protected] on July 09, 2010 01:00:51
I was thinking that the CDN media files would be easiest for the users who just want to see something quickly. Looking at the code again, the media files should be in a separate block anyway for performance and if I wrapped them in something like a {% block modeltranslation_javascript %} it'd be easy for anyone with more advanced needs to use a template override. While making that change, it'd also be trivial to have the entire thing use jQuery in noConflict mode since we just need to load a single script.

What do you think of that approach?

from django-modeltranslation.

From [email protected] on July 09, 2010 14:43:48
http://github.com/acdha/django-modeltranslation/commit/24b46522c1c2d5ac895fd41f73fa23af2d7f8468 and http://github.com/acdha/django-modeltranslation/commit/da8ea006799f4f33a94419d11ce15824b940f69e have the change I described above and documentation for how to enable tabs and how to use a template override to change the location where jQuery & jQuery UI are loaded from.

from django-modeltranslation.

From [email protected] on July 14, 2010 19:50:35
Here's some JS that adds jQuery UI tabs without the need for template modifications.

To use it do something like this:

class ItemAdmin(TranslationAdmin):
class Media:
js = (
'/static/modeltranslation/js/force_jquery.js',
'http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.2/jquery-ui.min.js',
'/static/modeltranslation/js/tabbed_translation_fields.js',
)
css = {
'screen': ('http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.2/themes/base/jquery.ui.all.css',),
}

The force_jquery.js is necessary when using the built-in django.jQuery. The only thin it does is assign django.jQuery to jQuery when no jQuery variable exists. If you don't do this (and do not load jQuery another way) jQuery.ui will fail to load.

Note that it doesn't really look that great when you use the stock jQuery ui theme. It might be a good idea to add some CSS to make it at least look ok when using standard django-admin.

from django-modeltranslation.

From eschler on July 14, 2010 22:29:48
That's pretty slick. I was about to throw in my own implementation. The result is about the same but it depends on translation group css classes which are added through modeltranslation's admin.py. Your approach proves that it isn't necessary (i had a feeling ;)), so i'm going to ditch my version. I will just add a cosmetic change that removes the language code in brackets from the translation field name (they are in tab already). Doing it in javascript keeps the whole thing unobstrusive.

There was a problem, however, which holded me back from adding my code in first place. We use the tinymce widget provided by django-tinymce (http://code.google.com/p/django-tinymce/) in many of our apps. When the widget is used in conjuction with the tabs code it will crash firefox. Tinymce is huge (who came up with that name?) and it's not guaranteed to be loaded when the code runs, well in fact it never is. Firebug throws alot of tinymce related undefines and then dies. The problem is present in your and my approach, so at least i can now be sure that i'm not doing weird things with jquery.

I don't intend to hold back a commit because of this issue, but perhaps someone has an idea how to workaround the race condition. It found an ugly hack using setTimeout to check for tinymce's presense but that really can't be the solution. There's also a jquery build of tinymce which doesn't seem to have this problem, but it doesn't seem to work with django-tinymce out of the box.

from django-modeltranslation.

From jaap%[email protected] on July 15, 2010 11:11:06
I'm using django-tinymce as well... I've not seen a crashing bug with this tab implementation. The only issue I've seen is that the fields in inactive tabs don't get the correct size.

I'll look into this, there's probably a way to re-init a field or something. Another fix could be to not really hide the tabs (no display: none) but instead position them outside of the screen.

from django-modeltranslation.

From eschler on July 16, 2010 13:00:50
I've hacked together a TinyMCE widget based on the one provided by django-tinymce. It uses the jquery plugin to init the editor and doesn't crash the browser.

Oddly enough it only works with an older version of TinyMCE - the one we had in our CMS already. With the latest version from the TinyMCE website (v3.3.8, both normal and jquery build) no widgets are rendered and no error is raised. In any way, this particular problem is not related to the tabs code.

from django-modeltranslation.

From eschler on July 16, 2010 14:24:32
Attached a slightly modified version of your code that changes the following things:

• Removed field name from the tabs navigation (is in label already).
• Removed the language code and squared brackets from the field label (is in tabs navigation already).
• Removed the strong tag for required fields in favour of a css class "required" which is added to the list item.

from django-modeltranslation.

From jaap%[email protected] on August 03, 2010 14:07:38
OK, here's a new version of tabbed_translation_fields.js (based on the version found in comment 11)

This version adds a dropdown next to the change form header that lets you switch all tabs at the same time to the same language. Useful if you need to see how a model will look in one language.

Besides that I've created a basic CSS file that styles the tabs to fit into stock django admin styling. This CSS also fixes TinyMCE not working in the hidden tabs (for me at least).

Example admin class:

class ItemAdmin(TranslationAdmin):
class Media:
js = (
'/static/modeltranslation/js/force_jquery.js',
'http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.2/jquery-ui.min.js',
'/static/modeltranslation/js/tabbed_translation_fields.js',
)
css = {
'screen': ('/static/modeltranslation/js/tabbed_translation_fields.css',),
}

Could you please add this to SVN (after the stuff I've added in issue 23)?

from django-modeltranslation.

From eschler on August 03, 2010 20:29:59
Committed the patches from issue 23.

The language switch is a nice feature. Work fine for me, just noticed that firebug catches an uncaught expection:
uncaught exception: jQuery UI Tabs: Mismatching fragment identifier.

Doesn't seem to be a problem, just wondering what's causing it. I'm using django's internal jquery and latest jquery-ui.

from django-modeltranslation.

From jaap%[email protected] on August 05, 2010 09:45:30
I'm not getting an exception here. I also use Django's jQuery and UI 1.8.2 (don't know if that's the latest)

I can't reproduce this.

from django-modeltranslation.

From eschler on August 05, 2010 19:38:15
This issue was closed by revision r88.

from django-modeltranslation.

From [email protected] on August 27, 2010 14:44:44
One minor documentation glitch: http://code.google.com/p/django-modeltranslation/source/browse/trunk/docs/modeltranslation/modeltranslation.txt?spec=svn88&r=88#462 uses "js" in the path for the CSS file

Also: do you think it's better to leave that as a simple "/static/" or indicate that the user needs to do something? I'm inclined to say it should be something like settings.MEDIA_URL + '/modeltranslation/…' with instructions to copy/link the modeltranslation media into place.

from django-modeltranslation.

From [email protected] on November 11, 2010 12:20:07
Why not put the css and js in the admin template (e.g. templates/admin/base_site.html) instead? Then all models marked for translation would automatically get tabs.

Here's what my base_site.html looks like:
[...]
{% block extrastyle %}{{ block.super }}

{% endblock %}

from django-modeltranslation.

From eschler on November 11, 2010 12:53:10
You can do this of course. Including the files in all apps might be what you want, but others might have different needs in their setup. For this reason it's kept flexible.

from django-modeltranslation.

From [email protected] on November 11, 2010 12:57:18
Yeah, I mainly thought about whether it should be documented or not.

Btw would it be possible to support django-localeurl? I.e. the language dropdown is automatically changed to the current locale.

from django-modeltranslation.

From [email protected] on January 19, 2011 19:15:15
hi,

I am trying to make tabs work with one of my models but I can´t,

The problem is that all the fields (in all languages) appear in the screen and the language selector doesn´t switch between fields. You can see the screenshot.

I am using Django 1.2.4 and this css and js configuration:

class Media:
     js = (
         'static/js/force_jquery.js',
         'http://ajax.googleapis.com/ajax/libs/jqueryui/1.8.2/jquery-ui.min.js',
         'static/js/tabbed_translation_fields.js',


     )
     css = {
         'screen': ('static/css/tabbed_translation_fields.css',),
     }

Any idea?

from django-modeltranslation.

From eschler on January 19, 2011 19:34:09
Have you verified that tabbed_translation_fields.js is actually loaded by the browser? In case it is, i see that you use a rich text editor - do you get tabs when you disable it?

from django-modeltranslation.

From [email protected] on January 19, 2011 20:06:48
tabbed_translation_fields.js is loaded correctly in the browser,

The problem is not the rich editor becasue i have tried in another model (without rich editor) and it happens the same problem (i attatch screenshot).

I am using django-modeltranslation todays trunk.

from django-modeltranslation.

From eschler on January 20, 2011 13:36:58
In this case i can only propose to add some debug statements to tabbed_translation_fields.js to find out what's going wrong. I would start with a check if the translation fields are grouped correctly. Assuming you have Firebug installed, like this before the return statement in getGroupedTranslationFields():
console.log(grouped_translations);

BTW, i'm a little confused regarding the asterisks in front of the application and field names in your screenshot (*sector_de_aplication, *titulo). Do you add them through the template?

from django-modeltranslation.

From [email protected] on January 24, 2011 07:58:19
Hi, problem solved,

The problem was I hadn't set corretly the params in the settins.py file.

Thanks for the help.

from django-modeltranslation.

From [email protected] on July 26, 2011 19:32:03
It appears that the tabs are broken for language codes in the 5-digit format 'xx-xx'. For example, my languages settings looks like this:

gettext = lambda s: s
LANGUAGES = (
('en', gettext('English')),
('ar', gettext('Arabic')),
('zh-cn', gettext('Chinese')), # Simplified Chinese. Traditional Chinese is 'zh-tw'
)

And the tabs exclude the Chinese version by putting it in its own tab set (see attached).

from django-modeltranslation.

From [email protected] on July 26, 2011 21:29:50
i submitted that last issue as http://code.google.com/p/django-modeltranslation/issues/detail?id=63

from django-modeltranslation.