In issue #2362321: Check source length limits we've tackled the error of translations coming with length bigger than accepted by field definitions, in the review form.
But translators can have the definition to "Auto accept finished translations" activated. If so, when submitting a translation with a field having length above the allowed, we have an SQL error:
File import failed with the following message: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'field_teste_value'
Note: I got this error when testing with File translator.
Add a global field_length_overflow_policy setting controlling what happens on acceptance when a translation exceeds the field length:
- Keep the item for review (needs_review, default): acceptance is refused and a message links to the review form.
- Truncate (truncate): the translation is shortened at a word boundary to fit, with a warning.
?
New "Field length overflow policy" select on admin/tmgmt/settings.
None.
New config key tmgmt.settings:field_length_overflow_policy.
Existing sites get needs_review via tmgmt_update_8012(), which matches the previous outcome (the over-length translation is not saved and the item stays in review) but replaces the uncaught database exception with a clear message.
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes, plain diff MR !170changes, plain diff MR !168changes, plain diff MR !169
Comments
Comment #2
dxvargas commentedComment #3
dxvargas commentedComment #4
dxvargas commentedComment #5
claudiu.cristeaI had a chat on Slack with @Berdir on this. He said
Shortening should be made with truncation at word boundaries
Comment #10
herved commentedSince this is a bug, I wanted to keep the solution simple. However, I think there are at least two behaviors that projects might prefer:
a) Automatically truncate the value and move the job item to the Accepted state (2960458-truncate branch).
b) Block the job item and keep it in Review (2960458-block branch).
I also created a third option that makes this behavior configurable (2960458-configurable branch), with truncation as the default.
Any feedback is welcome.
Comment #11
claudiu.cristeaI've only reviewed the one that gives the site builder the power to decide. In my projects, with continuous jobs, I don't want to review such cases, I want to enforce truncation. But I have no idea how other projects think. Even is introducing a new config, it leaves the decision to the site builder. I would suggest we focus on this MR.
Comment #14
herved commentedComment #15
claudiu.cristeaPicked up for review
Comment #16
herved commentedComment #17
claudiu.cristeaIn https://git.drupalcode.org/issue/tmgmt-2960458/-/pipelines/860363, I've manually started:
Compared to HEAD's latest pipeline https://git.drupalcode.org/project/tmgmt/-/pipelines/708592 we have an additional "phpunit (next minor)" failure. We should not add additional failures, at least, in PHPUnit jobs.
Comment #18
claudiu.cristeaOk, so https://git.drupalcode.org/project/tmgmt/-/pipelines/708592 ran 5 months ago. The failures here are because Drupal core evolved. There's nothing to be done here.
Thank you for the work on this