Remove custom Plugin architecture

Created on 19 October 2023, 9 months ago
Updated 21 November 2023, 7 months ago

Problem/Motivation

Investigate and remove all plugins which has their replacements on Lingotek.

API changes

Adapt changes to work with Lingotek 4.x API.

πŸ“Œ Task
Status

Active

Version

3.8

Component

Code

Created by

πŸ‡΅πŸ‡±Poland relim

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @relim
  • πŸ‡ΊπŸ‡ΈUnited States partdigital

    I spent some time with Lingotek overrides and this is what I found that we need to do to start upgrading lingotek overrides so that it supports Lingotek 4.1.0.

    LingotekConfigManagementForm

    • Most of the code in this file was copied from the original form.
    • This only adds 5 lines of code that affects query search in the form.
    • This can probably be removed.

    LingotekManagementForm

    • Most of the code was copied from the original form.
    • This was added to support showing untracked content. It copied most of the code from the original class with about 20 lines of code changes and no comments.
    • The 4.1.0 version of this has changed a lot.
    • It may be possible to simply remove this.

    LinogotekManagementRelatedEntitiesForm

    • This was added to support the custom form_filter, form_field, form_operation and form_option plugins. Which are all deprecated in favor of Lingotek's own Form plugins (see below for details).
    • Note that the existing plugins should be removed/refactored first.

    LingotekContentTranslationService

    • Most of the code was copied from Lingotek 3.8 with some changes to support LingotekFieldProcessor plugins. (LingotekFieldProcessor plugins are introduced in Lingotek 4.x and backported in lingotek_overrides to support Lingotek 3.8.
    • If we upgrade to Lingotek 4.x we can remove all the LingotekFieldProcessor plugins in `lingotek_overrides` and refactor any custom field processor plugins.

    LingotekContentModerationHandler

    • This adds a custom method getLatestAffectedRevisionByState() which only gets called as part of the LingotekContentTranslationService. i
    • If we remove LingotekContentTranslation service, this can be removed.

    Plugin Mapping:

    Can remove the following plugin types, Lingotek has their own versions of them now. Note that some custom plugins will need to be refactored. Not all of them though, many have already been brought over to Lingotek proper.

    LingotekOverridesFormOption

    • Replaced with LingotekFormComponent/BulkActionOption
    • Remove JobId
    • Refactor: Language
    • Refactor: Profile

    LingotekOverridesFormOperation

    • Replaced with: LingotekFormComponent/BulkAction
    • Remove AssignJob
    • Remove Cancel
    • Remove Cancel Translation
    • Remove Check Translation
    • Remove ClearJob
    • Remove DeleteTranslation
    • Remove Download
    • Remove RequestTranslation
    • Remove Upload

    LingotekOverridesFormField

    • Replaced with LingotekFormComponent/Field
    • Refactor all.

    LingotekOverridesFormFilter

    • Replaced with: LingotekFormComponent/Filter
    • Remove: EntityBundle
    • Remove: JobId
  • πŸ‡ΊπŸ‡ΈUnited States partdigital

    I've pushed up a branch with most of these changes implemented. I've been able to get it to work with Linogotek 4.1.x

    The biggest noticeable effect is on the /node/{%node}/manage. Instead of a collection of checkboxes for each language you have to select each language from a select list e.g "Download French (fr) translation)" very similar to what you see in Views bulk operations. This is probably because Lingotek proper makes use of "Action" plugins instead of "Option" plugins. They do essentially the same thing but with a different implementation.

Production build 0.69.0 2024