If TMGMT export import file module is enabled it seems to mess up the default translator. When a node edited and set to translate using tmgmt then instead of doing a full translation and finished job it creates a job that the Translator is set as "missing translator"

this is what should come under the translation job list:

Pirate English Arabic Finished Microsoft translator (auto created) 2/0/0/0 3 08/02/2013 - 00:58

but you get this with export import enabled.

Pirate English Arabic Unprocessed Missing translator 0/0/0/2 3 08/02/2013 - 01:03

Comments

miro_dietiker’s picture

Can you please provide a step-by-step report to reproduce?

Fishboy1669’s picture

I'll try I thought I had though.

go to a node
choose either 'edit' then 'translate' or if you have it enabled just click on 'translate'
then you should get a screen
------
Translations of "chosen node"

Translations of a piece of content are managed with translation sets. Each translation set has one source post and any number of translations in any of the enabled languages. All translations are tracked to be up to date or outdated based on whether the source post was modified significantly.

LANGUAGE TITLE STATUS PENDING TRANSLATIONS OPERATIONS

English (source) Pirate Published Source edit

Arabic القراصنة Published None edit

Spanish Pirata Published None edit

(Request translation)
-----

choose the languages you want to translate to and then click the Request translation button
this should then create the job and process it if you have set the default translator to accept finished translations. I'm using bing so the process should be totally automated and as soon as I have pressed request translation it should create the translation by using bing and set it to checked and accepted. But when the export / inport module is enabled the bing translator some how gets stopped from being the default translator. ie using the weighting system. I presume that the more negative its weight the higher it is.

miro_dietiker’s picture

One thing is that the default selection does no more work once the file translator is enabled.

You didn't state what translator you explicitly chose from the dropdown that finally ended up in "Missing translator".
Does the microsoft translator still work when manually chosen?

BTW, i see at least two errors here then:
- default selection does not work
- "missing translator" text for file translator

Fishboy1669’s picture

Hi,
when i go to the translation page the one that has the jobs and sources tabs and select sources and then request a translation for the node there it comes up with the page:

Label

You can provide a label for this job in order to identify it easily later on. Or leave it empty to use default one.
Source language
English
Target language *

Total word count
3

and yes I can choose in the drop down there which translator I want to use and the bing one is top of the list presumably due to its weighting from the "Translation Management Translators" configuration page. This was all tested with the export and import module enabled.

cheers

Fishboy1669’s picture

when you select (request translation) from the translation of the node you don't get a drop down to choose which translator. I presume it just uses the default one there. Cant remember if earlier versions of tmgmt if you had the option there to choose. There is a vague possibility that you could choose there.

Fishboy1669’s picture

Hi,
you say one thing is that the default selection does no more work once the file translator is enabled, is this on purpose or is this an actual bug? If its supposed to work that way can you give an explanation why?

cheers

miro_dietiker’s picture

I said, if your description is right, i see TWO bug reports in this one.
That should be clear enough about your last question.
See: https://drupal.org/node/2056093#comment-7711243

Fishboy1669’s picture

Ah ok I understand.

could be the same bug though in the sense that if the export import module code is messing up the default / use this translator config. I am guessing that both issues will be fixed at the same place in the code. But yes its appearing as though its two bugs with the same code.

Any pointers as to where in the export / import module it tries to set up its configuration weighting. I might be able to have a go at getting a fix if pointed in the right direction.

cheers

berdir’s picture

From what you are describing, this seems to be mostly by design.

If only a single translator is available and that has no settings, then that is automatically selected and the job is submitted.

That functionality is disabled as soon as you have two or the translator has settings. That is correct and by design. What *should* happen then is that you get redirected to a checkout page where you can select the translator you want to use, configure it and submit the job.

From your description, I assume that's what's not happening.

Where exactly are you click on translate? Possibly the contextual link? There might be a bug that if you have a ?destination=some/path in the URL, than that overrides our own redirect.

I've fixed this for the i18n source where I noticed it, but it probably also happens for node and entity source.

Fishboy1669’s picture

Not sure why it would be by design. When its working I have three translators set up: microsoft, local, and google, although google is not configured and it works as expected its only when I add export / import that it then doesn't use the default one as per set up via weighting in the : "users/admin#overlay=admin/config/regional/tmgmt_translator" page

As to your second point I never get transferred to the checkout page it just attempts to do the translation. If I then go to the
"users/admin#overlay=admin/tmgmt" job page and I don't have the export / import then the microsoft is used and if export / import is enabled then it comes up with missing translator.

I am clicking on the link:
"/node/2057/translate?destination=node"
which is on my front page teases on the:
edit,
delete,
translate

drop down menu on the right hand side of the taser in bartik 7.22
this then takes me to this page:
"#overlay=node/2057/translate%3Fdestination%3Dnode"

which looks like this:

Operating in maintenance mode. Go online.
Translations of a piece of content are managed with translation sets. Each translation set has one source post and any number of translations in any of the enabled languages. All translations are tracked to be up to date or outdated based on whether the source post was modified significantly.

LANGUAGE TITLE STATUS PENDING TRANSLATIONS OPERATIONS

English (source) Pirate Published Source edit

Arabic القراصنة Published None edit

Spanish Pirata Published None edit

SELECT TRANSLATIONS FOR PIRATE
Alternatively, you can select existing nodes as translations of this one or remove nodes from this translation set. Only nodes that have the right language and don't belong to other translation set will be available here.
Arabic

Spanish

I then click on the check boxes on the right hand side choosing the languages I want to translate into and the click the request translation button.

hope this all makes some sort of sense. Happy to keep providing more info as needed.

berdir’s picture

Title: When TMGMT Export / Import file module is enabled then node translation creates a job that translator is "Missing translator" » Redirect to job checkout page does not work when ?destination argument is passed to the translate page.

"/node/2057/translate?destination=node"

Yes, and this is the only bug here.

Try to go to node/2057/translate and request a job. You get to a page where you can select the translator. That is by design. The only bug here is that you don't see this page when you have a destination query in the URL.

There is no default translator. That concept does not exist. The only thing that exists is a one-available-translator-only-without-settings quick-checkout. So far, you've been using that and didn't notice the actual problem here.

Re-titling this issue.

Fishboy1669’s picture

oh ok seems strange way of doing thing would have thought clicking on the translate would either use default one or give a drop down so can select which you want.

I have gone to the node and then clicked on the translate tab like you suggested and it comes back with this:

The requested page "/s:35:" could not be found.

not sure if this is a bug with the module or with my setup? :s

Is it likely that the destination query url will be fixed?

How could I be using the one available translator only without settings when I have three set up? Is the unconfigured google one and the local translator not part of this family?

cheers

berdir’s picture

Status: Active » Needs review
StatusFileSize
new4.21 KB
new2.44 KB

I have no idea what the problem with s:35 is, that looks very weird. Possibly a conflict with the modules you have installed, do you have other modules that are related to translating content? Are you using entity_translation.module or the core translation module?

Anyway, this patch should fix the destination issue, comes with automated tests.

miro_dietiker’s picture

Status: Needs review » Reviewed & tested by the community

Looks great.

+++ b/sources/node/ui/tmgmt_node_ui.pages.incundefined
@@ -103,7 +103,10 @@ function tmgmt_node_ui_translate_form_submit($form, &$form_state) {
-    tmgmt_ui_redirect_queue_set($redirects, current_path());
+    tmgmt_ui_redirect_queue_set($redirects, isset($_GET['destination']) ? $_GET['destination'] : current_path());
+    // Remove an eventually existing destination, as that will prevent us
+    // from being redirect to the job checkout page.
+    unset($_GET['destination']);

I guess i would prefer the code below with less ?: stuff as those are somehow two separate cases...

if (isset($_GET['destination'])) {
  tmgmt_ui_redirect_queue_set($redirects, $_GET['destination']);
  unset($_GET['destination']);
else {
  tmgmt_ui_redirect_queue_set($redirects, current_path());
}

What do you think?

berdir’s picture

Status: Reviewed & tested by the community » Needs review
StatusFileSize
new5.37 KB
new7.39 KB

Good point, looks better that way.

Also made the whole thing a helper function, it's not much but those lines are now identical across all three sources and no longer trivial.

miro_dietiker’s picture

Status: Needs review » Reviewed & tested by the community

iLike. Commit once passed.

berdir’s picture

Version: 7.x-1.0-beta1 » 7.x-1.x-dev
Status: Reviewed & tested by the community » Fixed

Committed and pushed.

@Fishboy1669: If you still have problems with this patch, please open a new issue.

Fishboy1669’s picture

Hi did some more testing and yes if i go to:

node/2057/translate

without the:

?destination=node bit then it works

then i get the new page for each of the jobs i have requested ie for each language and can then just click on "submit to translator" I have tried this with

so this does confirm what you say.

Fishboy1669’s picture

I get the s:35 if I click on the translate tab from the actual node

If i click on the translate from the menu of the teaser for this node from the front page then it does go into the translation page ok. Like I say could be my set up. I have the following installed:

MULTILINGUAL - ENTITY TRANSLATION
All enabled

MULTILINGUAL - INTERNATIONALIZATION
All but the following enabled:
Multilingual forum
Rules translation
User mail translation

TRANSLATION MANAGEMENT
All enabled

I did also have
Multilanguage
Translation overview
installed and enabled but found out this is old and has been replaced by the Translation Management. Its still installed but not enabled and I do wonder if this has messed somethings up somewhere. Might have to try another install with out putting this installing and enabling this module. If I understand this right then it might be worth mentioning on the module page that this is outdated now. I found out in the:

https://drupal.org/node/1698840

--------
Checkout the tmgmt module. It's our successor of this module and tries to introduce a lot more to manage multilingual workflows.
http://drupal.org/project/tmgmt
As one part, it offers a content translation status matrix with even more indicators.

No, please don't update version and status!
Patches are against dev and only if you know what you're reviewing, you should switch the status. In any other case, leave it unchanged since it needs further review of others.
---------------

The other thing it could be is clean url's they didn't used to work on my server but since 7.22 they seem to and enable without the test process so bit dubious on this as well.

Fishboy1669’s picture

the s:35 is really confusing me now.

if i go to the actual node the url has this:

www.domin.com/s%3A35%3A%222073211828003/pirate-bride-paperback%22%3B

now if i click on the translate tab on this node it goes to this page:

www.domain.com/s:35:

but if I hover over the tab and then right click and open in new window it works fine and goes to this page:

www.domain.com/node/3310/translate

as it should!

I'll keep working on this one like I say I don't think its to do with the tmgmt module and more my set up and maybe the clean urls.

berdir’s picture

Ok. What you have there is a serialized string, when you encode that, you get 'www.domin.com/s:35:"2073211828003/pirate-bride-paperback";'. That said, I have no clue how that could possibly end up there.

Either way, when you use the latest dev snapshot with this change or apply the patch manually then you can also go back to using the contextual translate link, that is fixed now.

Fishboy1669’s picture

I just done an inspect element on the tabs and this is whats there ( i have removed all the < so the code showed hopefully it still makes sense)

div class="tabs">
h2 class="element-invisible">Primary tabs /h2> ul class="tabs primary"> li class="active"> a href="/s%3A35%3A%2299219sia0pb0fe2070/lace-pirate-medium%22%3B" class="active">View span class="element-invisible">(active tab) /span> /a> /li>
li> a href="/node/3316/edit">Edit /a> /li>
li> a href="/node/3316/translate">Translate /a> /li>
/ul> /div>

where do the tabs get generated which module is it core or part of the internationalisation or tmgmt?

Fishboy1669’s picture

Ah think I have an idea whats causing it will keep you posted.

Cheers

Fishboy1669’s picture

sorted it was an issue with pathauto and some strange char that had got put there.

cheers

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.