Closed GoogleCodeExporter closed 9 years ago
Original comment by eschler
on 30 Jun 2010 at 8: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.
Original comment by eschler
on 8 Jul 2010 at 10:43
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
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
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
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
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:
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
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
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
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:
Original comment by eschler
on 18 Jul 2010 at 9:50
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:
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
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
This issue was closed by revision r88.
Original comment by eschler
on 5 Aug 2010 at 7:38
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
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
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
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
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:
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
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:
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
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
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:
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
Original issue reported on code.google.com by
adamsc@gmail.com
on 29 Jun 2010 at 6:27