Expected Results:

I have the page in the wiki using the "cargo_store" statement (via a template). I try to mark the page for translation by either adding <translate></translate> tag or using "Special:PagePreparation" on the page. I would expect the following:

1. The top of the page has a "Mark this page for translation" link
2. The page appears in the "Pages proposed for translation" list on "Special:PageTranslation"

Actual Results:

Neither of the two expected results happen. Despite asking to be able to translate the page, there is no way to start the process.

Further Information:
As a work around for the the problem and believing the name "code" was the source of the problem, I changed the name of the bad column from "code" to "sophont_code". This did not work around the issue. If the cargo_store tag on the page now uses "sophont_code", the failure occurs.

Note that 1.33.0 is an old, insecure, unsupported version. Proposing to decline this ticket as long as this is not reproduced with recent, supported versions.
For future reference, please also see https://www.mediawiki.org/wiki/How_to_report_a_bug - thanks.

@Aklapper - Cargo is still meant to support MW 1.33, so that part is fine.

@Tjoneslow - so does this problem happen with any name for the parameter, or does the name have to contain "code"?

Translate code related to this was refactored in MLEB 2020.10, but that version dropped support for MediaWiki 1.33.

There aren't many reasons why the links wouldn't show up:

• PageContentSaveComplete hook is not executed
• Page is not of type wikitext
• Page does not contain translate tags
• Exception is thrown when parsing translate tags
• Revtag table is broken

Without more info I can't know what it is.

The only two reasons this may be happening would be "PageContentSaveComplete hook is not executed" or "Exception is thrown when parsing translate tags". But I can't find any errors in the logs or otherwise.

Do you have suggestions about which of the many debugging flags in the LocalSettings I could enable to determine if there are problems to be found?

@Yaron_Koren I changed the name of the column to "sophont_key" but that does not resolve the problem. So the name "code" is not the problem. As above I suspect there is a failure that is not generally visible and not interfering with the display of the page. But is stopping either the Cargo processing, the Translate processing, or both.

A little more information. I found the order of failures which cause this to happen.
If there is failure in the Cargo storage the Translate header will not show up in the page when saved.

I have upgraded my test wiki to the latest version of Cargo (2.7) and the Translate package to the latest version (2020-07) still supported by my Media wiki 1.33.

Example; as short as possible, create this as a template called "test", and create the underlying table.

<noinclude>{{#cargo_declare:
 _table=Sophonts
 |name=Page
 |sophont_key=String (size=4)
}}</noinclude>
: {{{name}}} ; {{{code}}}
<includeonly>{{#cargo_store:
 _table=Sophonts
 |name={{{name}}}
 |sophont_key={{{code}}}
}}</includeonly>

Then put the following into a test page:

{{{test|name=My Creature}}}
<translate>
This is text to be translate
</translate>

The Test template tries to insert into the cargo table, and fails (silently) with a SQL Error (the sophont_code of "{{{code}}}" is too long to insert). The problem here is you need to have the debug log enabled to see the error message. It quietly fails without any warning or error message anywhere else.

And the "translate this page" fails to appear at the top of the page.

Second if you put this on the test page:

<translate>
{{{test|name=My Creature|code=AABB}}}
This is text to be translate
</translate>

This also fails: the cargo insert fails with no message, even in the debug log and no "translate this page" appears at the top of the page once saved.

I think I know what's causing the specific errors you're seeing with #cargo_store. MediaWiki's templates have the somewhat unexpected behavior that, if a template parameter is not set, they will display the full syntax for that parameter - so what will be displayed (or put into #cargo_store) is not blank, but "{{{FieldName}}}". The solution to this is to add a pipe - so you should change {{{code}}} to {{{code|}}}, etc. As for your second test, the parameter needs to be "sophont_key", not "code". (Unless you change the parameter name back to "code", which you could also do.)

That, I think, will solve these specific issues. It doesn't fix the general problem that a failing #cargo_store call will, apparently, mess up other extensions' behavior. I just renamed the bug, given that.

I'm aware of the fix for the template parameters. In the template in the wiki there are two dozen parameters so finding these can be a problem. And with no feedback its not always apparent where these problems are.

The second problem is correct. The template parameter is {{{code}}}, which is inserted into the cargo table field of sophont_key. Yes, it is more understandable if the template parameters and the cargo fields names are the same, but isn't a requirement. If I can figure out the core problem and it's a different than the this one, I'll write a new problem report.