google-code-export / django-modeltranslation

Automatically exported from code.google.com/p/django-modeltranslation
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

Admin: use tabs to separate translations #39

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
http://github.com/acdha/django-modeltranslation/commit/0fabf5dbe56845fb8d58fc4fd
6429638a49a2d2f uses jQuery UI and the fieldset logic from #38 to convert the 
translated fields into tabs to reduce the space needed for many different 
languages (I have to support 7).

Original issue reported on code.google.com by adamsc@gmail.com on 29 Jun 2010 at 6:27

GoogleCodeExporter commented 9 years ago

Original comment by eschler on 30 Jun 2010 at 8:26

GoogleCodeExporter commented 9 years ago
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.

Original comment by eschler on 8 Jul 2010 at 10:43

GoogleCodeExporter commented 9 years ago
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/9e92777ea04d118fdaa05c4dc
e0f07102b41f533

Original comment by adamsc@gmail.com on 8 Jul 2010 at 1:25

GoogleCodeExporter commented 9 years ago
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. :)

Original comment by eschler on 8 Jul 2010 at 9:10

GoogleCodeExporter commented 9 years ago
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?

Original comment by adamsc@gmail.com on 9 Jul 2010 at 1:00

GoogleCodeExporter commented 9 years ago
http://github.com/acdha/django-modeltranslation/commit/24b46522c1c2d5ac895fd41f7
3fa23af2d7f8468 and 
http://github.com/acdha/django-modeltranslation/commit/da8ea006799f4f33a94419d11
ce15824b940f69e 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.

Original comment by adamsc@gmail.com on 9 Jul 2010 at 2:43

GoogleCodeExporter commented 9 years ago
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.

Original comment by jaap.roes@gmail.com on 14 Jul 2010 at 7:50

Attachments:

GoogleCodeExporter commented 9 years ago
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.

Original comment by eschler on 14 Jul 2010 at 10:29

GoogleCodeExporter commented 9 years ago
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.

Original comment by jaap%eig...@gtempaccount.com on 15 Jul 2010 at 11:11

GoogleCodeExporter commented 9 years ago
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.

Original comment by eschler on 16 Jul 2010 at 1:00

GoogleCodeExporter commented 9 years ago
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.

Original comment by eschler on 16 Jul 2010 at 2:24

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by eschler on 18 Jul 2010 at 9:50

GoogleCodeExporter commented 9 years ago
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)?

Original comment by jaap%eig...@gtempaccount.com on 3 Aug 2010 at 2:07

Attachments:

GoogleCodeExporter commented 9 years ago
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.

Original comment by eschler on 3 Aug 2010 at 8:29

GoogleCodeExporter commented 9 years ago
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.

Original comment by jaap%eig...@gtempaccount.com on 5 Aug 2010 at 9:45

GoogleCodeExporter commented 9 years ago
This issue was closed by revision r88.

Original comment by eschler on 5 Aug 2010 at 7:38

GoogleCodeExporter commented 9 years ago
One minor documentation glitch: 
http://code.google.com/p/django-modeltranslation/source/browse/trunk/docs/modelt
ranslation/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.

Original comment by adamsc@gmail.com on 27 Aug 2010 at 2:44

GoogleCodeExporter commented 9 years ago
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 }}
<link rel="stylesheet" type="text/css" href="{{ MEDIA_URL 
}}css/modeltranslation/tabbed_translation_fields.css" />
[...]
{% endblock %}
[...]
{% block footer %}{{ block.super }}
<script type="text/javascript" src="{{ MEDIA_URL 
}}js/modeltranslation/force_jquery.js"></script>
<script type="text/javascript" src="{{ MEDIA_URL 
}}js/jquery-ui.min.js"></script>
<script type="text/javascript" src="{{ MEDIA_URL 
}}js/modeltranslation/tabbed_translation_fields.js"></script>
{% endblock %}

Original comment by jaco...@gmail.com on 11 Nov 2010 at 12:20

GoogleCodeExporter commented 9 years ago
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.

Original comment by eschler on 11 Nov 2010 at 12:53

GoogleCodeExporter commented 9 years ago
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.

Original comment by jaco...@gmail.com on 11 Nov 2010 at 12:57

GoogleCodeExporter commented 9 years ago
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?

Original comment by cue...@gmail.com on 19 Jan 2011 at 7:15

Attachments:

GoogleCodeExporter commented 9 years ago
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?

Original comment by eschler on 19 Jan 2011 at 7:34

GoogleCodeExporter commented 9 years ago
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.

Original comment by cue...@gmail.com on 19 Jan 2011 at 8:06

Attachments:

GoogleCodeExporter commented 9 years ago
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?

Original comment by eschler on 20 Jan 2011 at 1:36

GoogleCodeExporter commented 9 years ago
Hi, problem solved,

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

Thanks for the help.

Original comment by cue...@gmail.com on 24 Jan 2011 at 7:58

GoogleCodeExporter commented 9 years ago
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).

Original comment by smc...@gmail.com on 26 Jul 2011 at 7:32

Attachments:

GoogleCodeExporter commented 9 years ago
i submitted that last issue as 
http://code.google.com/p/django-modeltranslation/issues/detail?id=63

Original comment by smc...@gmail.com on 26 Jul 2011 at 9:29