The merge request implements the life cycle for translated documents
I'll look into the phpstan findings when 📌 Fix code quality issues Active is fixed
Based on the issue summary, comments and related issues the immediate problem is limited to single select elements and client side validation. If I missed something, let me know and I can update the issue accordingly
Refactoring the _none value itself is being worked on in
📌
Convert '_none' option to a constant and deprecate form_select_options()
Needs work
idebr → changed the visibility of the branch 1585930-options-module-uses to hidden.
To minimize the BC break, I suggest we map the _none option to the Select #empty_option and set #empty_value to an empty string in a process callback.
This implementation allows existing options to remain unchanged; only client side logic is impacted (eg. JavaScript)
DeeplTranslatorBatch:: getTranslationOptions() is a bit messy right now since the settings priority is currently not implemented (Job settings > Translator settings -> Translator plugin defaults). I filed a follow-up issue to start smoothing this out, see 📌 Provide sensible default settings Active
The merge request adds default settings by implementing \Drupal\tmgmt\TranslatorPluginInterface::defaultSettings
In the merge request additional values in the 'Translate content' form are saved in the Job entity.
TMGMT supports translation of files on a conceptual level, see https://www.drupal.org/node/3392215 →
The mimetypes that should be translated can be selected at /admin/tmgmt/settings under 'File translation'
Assuming you have a working setup with nodes, you can add a 'File upload' field to the content type and check the option 'Users may translate this field' in the field settings.
Also available in tmgmt_deepl, see ✨ Support translation of documents Active
- Translatable files are now added as a separate batch operation per file, see \Drupal\tmgmt_deepl\DeeplTranslatorBatchInterface::translateDocumentOperation
- A document is translated by Deepl through \Drupal\tmgmt_deepl\DeeplTranslatorApiInterface::translateDocument
MR works as expected.
Not sure what problem is indicated in #12 because of the double negative, but messages are still shown in the user interface. I'll leave at 'Needs review'
TMGMT enables additional settings when a translator plugin includes "files = TRUE" in its annotation
- \Drupal\tmgmt_deepl\DeeplTranslatorApiInterface::translate is renamed to \Drupal\tmgmt_deepl\DeeplTranslatorApiInterface::translateText to match the deepl client method
- Introduced \Drupal\tmgmt_deepl\DeeplTranslatorApiInterface::translateDocument
I will continue to iterate on this issue next week.
Preferably auto create is removed entirely, see 🐛 Allow disabling of auto-creation of translation plugins Active
The current hook tmgmt_modules_installed implementation is fundamentally flawed: there is no way to actually set the "auto create" to false as the annotation does not support spaces in the key as I discovered in 📌 Opt out deprecated Translator plugins from auto create Active
tmgmt_modules_installed was added as part of the initial 8.x port. I suggest this hook is removed in favor of config/install files as is customary nowadays
The merge request fixes test failures on phpunit: next minor (11.x-dev)
The merge request implements constructor property promotion to reduce boilerplate
The failure reported in phpunit: next minor is unrelated. A separate issue is available at 📌 Fix test failures on phpunit: next minor (11.x-dev) Active
Is this not what the 'visible' key is for?
visible: (optional) The default visibility of the element. Defaults to TRUE.
https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21...
Needs work to fix test failures on 11.1.x
The merge request fixes spelling of authentification, occured, interpunction, tmgt
The merge request adds config schema for key.type.deepl_api_key
Changes look good. However, there is still an open thread in the merge request that is possibly outdated?
Ran into this issue as well after updating to beta3. The issue was fixed in the -dev version, but the change to does apply cleanly as a patch
#3538150-18: 502 Bad Gateway on Frontend After Update to beta 3 (from 2) → mentions
And if everything is ok, I'll publish a 2.0.0-beta4 release.
A new beta version should prevent other sites from running into this issue, so a new release tag would be very welcome
📌 Convert to OOP Hooks Active was committed.
📌 Convert to OOP Hooks Active was committed.
The unit tests is renamed so it is detected on Drupal.org infrastructure, see https://git.drupalcode.org/issue/search_api_attachments-3510970/-/pipeli...
Berdir mentions in [3396165-25]:
I realized that we forgot about another generic plugin feature beside deriver, the provider. It isn't used a lot in core for obvious reasons, but it's a valid use case to implement a plugin if another module exists.
Was this ever implemented for plugin attributes? Running into this now at the Linkit conversion: 📌 Support attribute based plugin discovery Active
The merge request fixes phpstan/phpcs/stylelint pipeline job findings
The autocomplete icon in the CKEditor widget cannot be updated with this approach without duplicating css, so the approach in 🐛 Improve autocomplete UI Active is preferable
Icon looks much better now, thanks!
Merge conflict resolved after 📌 Use latest rules for postcss-nesting Active was committed.
The WebformBreadcrumbBuilderTest @dataProvider is now a static method
This feature is available through contrib, see https://www.drupal.org/project/composer_deploy →
https://git.drupalcode.org/project/varnish_purge/-/merge_requests/12/dif...
In the commit message the dependencies in the info.yml file are assumed to resolve automatically. This assumption is incorrect for this module.
The rename of the info.yml file is out of scope for this issue
In the DisplayFeedTest.php the description is only checked for html, but not the CDATA. Can you update the assertion to include the CDATA, since this allows the inner text to be html ?
The proposed resolution is to add a composer.json. The MR does not match the proposed resolution.
Tests are failing on Drupal 11.2 regardless, see 📌 Fix tests on 11.2 Active
The merge request:
- fixes tests on 11.2
- includes the deprecation for invalidateAll(), see https://www.drupal.org/node/3500622 →
I added a screencast on a new Drupal standard installation on 11.2.x with steps to reproduce
The redundant lines were removed.
Updated the issue summary so it matches the current implementation
Code change works as expected, thanks!
I filed a follow-up issue to fix the unrelated issue in the cspell pipeline job, see 📌 cspell issues reported in pipeline Active .
idebr → changed the visibility of the branch 3185024-change-feature-policy to hidden.
Not sure why this was postponed in #5? Seems like a useful feature
To do: find out how to migrate the provider attribute. See #3396165-25: [meta] Convert all core plugin types to attribute discovery →
phpcs finding were fixed in 📌 Fix phpcs pipeline job findings Active
phpcs finding were fixed in 📌 Fix phpcs pipeline job findings Active
Test coverage shows the issue is fixed. Contrib tests in 🐛 Fix tests (next minor) Active are fixed as well with this change. Thanks!
I filed an issue for Drupal Core: 🐛 A reverted revision is not listed on the version history Active
\Drupal\node\Form\NodeRevisionRevertForm does not call \Drupal\Core\Entity\ContentEntityStorageBase::createRevision that sets the revision_translation_affected.
See \Drupal\Core\Entity\Form\RevisionRevertForm::prepareRevision for reference
These test failures now affect the regular 'phpunit' pipeline step
Closed as a duplicate of 🐛 Fix tests (next minor) Active
Patch file for 8.x-1.x for projects running the final version of 8.x-1.x
The merge request removes the outdated \Drupal\Tests\diff\Functional\CoreVersionUiTestTrait
Closed as a duplicate of 🐛 Fix tests (next minor) Active
The merge request updates 'assertEquals()' arguments in tests to expected, actual
The merge request adds support for Datetime Range field type and adds test coverage for the daterange field type