Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.The fields at gengo are currently not submitted with sequence weight.
Gengo supports adding that weight. We should just add a weight from the field definitions.
This is a bug as the document structure (field sequence) gets lost and is relevant to understand the content.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | tmgmt_mygengo-remote_jobs_position-1963934-2.patch | 3.91 KB | blueminds |
| #10 | tmgmt_mygengo-remote_jobs_position-1963934-2-interdiff.txt | 3.05 KB | blueminds |
| #8 | tmgmt_mygengo-remote_jobs_position-1963934-1.patch | 877 bytes | blueminds |
Comments
Comment #1
berdirtmgmt_mygengo doesn't and can't know about field weights. We first need to introduce weights into our own data structure.
Comment #2
miro_dietikerI would expect that our structure knows the sequence (implicitly, if not explicitly).
Can we not just use that native sequence and convert it to explicit weights in case of gengo?
Comment #3
berdirI don't think it does. The order is based on the order that field_info_instances() or so returns, I doubt that is based on the widget weight (there's also the display weight, so which one should we actually use?) Add field groups to the mix and I'm certain that it's no longer correct at that point.
But yes, the job for tmgmt_mygengo is solved by adding an explicit weight to whatever getData() returns. But that's the trivial part of the problem.
Comment #4
miro_dietikerDiscussed this here.
The editor experience in adding content is based on the field weight from the manage fields display.
This seems to be the most appropriate sequence for content creation (and translation)
So this needs a core issue:
#1971646: Core and all Source plugins should consider field sequences
Comment #5
miro_dietikerThis issue is about field sequence. For that we need support from core and will add that later.
However, we have a truly urgent limitation in that the different entities (all grouped in a single job) needs to be separated.
This is gengo specific, thus separate issue:
#1963934: Add field sequence weight to gengo job
Comment #6
blueminds commentedFor this case we cannot use field weights. That will be possible when we split payloads based on entities (entity = payload). Currently all dataitems are submitted within one group and in case we use for submitted jobs field weights the result will be that it will get messed up even more. So two possibilities:
- do the payload splitting and then we can use field weights
- just do simple increment as the sequence in which we order jobs within a payload is correct
Comment #7
berdirIf we add a weight/order across the whole job that we sent, then it should be fine for 90% of the cases?
The order of the fields might not be the same as when you edit a node, but at least each entity should be in order and it should be the same order as in our own review forms.
Let's add this in #1974494: Separate entities by adding position parameter to gengo job and keep this open to track the field-level problem, but I don't expect this to be a big problem anymore after we add the weight to ensure the same order as the one we have in Drupal.
Comment #8
blueminds commentedI think this should work then for now... tested it somehow and it looks like the order is perserved in the jobs list. However hard to test as gengo sandbox does provide only plain list of jobs, and you cannot view jobs within a group. So I believe this is something for gengo guys to really test.
Comment #9
berdirLooks good to me. Can we add some test assertions to make sure that the sent data to the mock contains the position. I think we already send two items.
Comment #10
blueminds commentedAssertions provided, please see the patch.
Comment #11
berdirThis is about all we can do at the moment. Commited so that they can test this on monday.