Closed (fixed)
Project:
Translation Management Tool
Version:
7.x-1.x-dev
Component:
User interface
Priority:
Minor
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
5 Dec 2012 at 17:55 UTC
Updated:
6 Jan 2013 at 14:51 UTC
Jump to comment: Most recent file
Comments
Comment #1
ethanethan commentedProbably http://drupal.org/node/1691772
Comment #2
nigelw commentedUnfortunately that's not the issue :(
I am using the core seven admin theme, main content block is there. Here is a screenshot so you can see what I have.
Comment #3
miro_dietikerThis is a clash with a different module that alters the translate tab.. Possibly i18n with modified weight?
Note there are multiple modules that reimplement the translate tab instead of extend it.
If we try to modify the translate tab ... and it's getting replaced by a different module by its own implementation, that's the result.
Alternatively you didn't enable the node source at all.
We'll need a list of enabled modules to help you more.
Comment #4
ethanethan commentedYes you have the main content block, but is it configured properly?
Comment #5
nigelw commentedThanks for pointing me into the right direction. I finally tracked it down. The Context module was the culprit. I had a sitewide context that was overriding core block placement for the seven theme. It was placing the main content block correctly but it looks like tmgmt doesn't modify the Translation Screen if the block is placed by the context module. Not sure if this is then a bug, feature request or works as designed. Providing support for the context module would be great though.
Comment #6
nigelw commentedObviously I can add
~node/*/translateto remove sitewide context from that path (as I don't really have a need to use context for admin screens and node/edit, but it might be better to add something to support Context (Others may still wish to use context to place the block).Comment #7
berdirI'm not sure if there is a clean way to integrate with context. If you have an infos about hooks or so, please link to it.
Changing this to a minor feature request, we can keep it open and maybe someone will try to improve it, but don't expect too much :)
The problem is that there is no clean way to do what we'e doing. There is no real API, our only choices are altering the global $page array in hook_page_alter() (which is what we're doing right now and doesn't work in some cases) or overwriting the page callback of translation.module completely, which be complicated as i18n_translation is already doing that too.
Comment #8
bforchhammer commentedI have the same problem of the translation overview not being altered... for me the main content ended up being nested one level deeper under an extra 'content' key.
Attached patch supports this case. Alternatively, adding the following snippet to a custom module should also do the job:
Note: the snipped above and patch are only for the entity_translation overview; for node translation the keys look slightly different (
node_translation_overviewinstead ofentity_translation_overview, I think).Comment #10
berdirHm, not sure why that didn't apply, wrong version maybe?
Can you add the same snippet to tmgmt_node.module?
Comment #11
berdir#8: context-fix-1859340-8.patch queued for re-testing.
Comment #13
bforchhammer commentedHm, not sure why that failed. Here's a reroll.
I also noticed that the entity translation one does not have an access check
tmgmt_access('create', 'tmgmt_job'). Is that an oversight or on purpose?Comment #14
bforchhammer commentedPatch with access check.
Comment #16
berdirDoing an assignment and another check on the same line is tricky, because what happens is this: $node = (menu_get_object() && entity_access('create', 'tmgmt_job')) when you don't set the () yourself.
Comment #17
bforchhammer commentedLet's see what the bot says about this one. :)
Comment #18
berdirWorks for me. Pushed.