Refactor to use libraries and compatibility with Big Pipe

Just to add a bit more clarity, because the translate js is currently not wrapped in a behavior, when the script tag gets rendered, it creates the gtranslate tag too and that code immediately runs on the page. So if something ajaxes something in or refreshes a block or region, drupal can trigger that js to run again. And so you end up with two translate drop downs.

By allowing the block to be cached and telling Drupal to not create a placeholder (see https://git.drupalcode.org/project/gtranslate/-/merge_requests/11/diffs#...) for that block, it won't let big pipe bring it in.

But by doing so, we want to ensure that block can be cached otherwise you break all caches on any page that block is on.

So we remove most of the work in the block template, use libraries properly and add a settings_alter for whatever logic needed to run for that block.

the MR applies cleanly.
How can I test?

is there a way to include the js locally if wanted?

my gtranslate Block no longer shows up in my theme.

I have cleared cache
there are no JS errors
Drupal 9.4.12
php 7.4.x

I had to remove the Block then re-enable each time I make a change to the gtranslate settings page.

Probably a cache tag needs to be set or invalidated when a setting is changed if that's the case. I'll have a look.

Nice work, much cleaner code!

Noticed some wrong mappings of the widget look options (e.g.: dropdown_with_flags) and their corresponding service names (e.g.: widget_dwf) in libraries.yml.

Proposed change:

cdn_widget_dropdown_with_flags:
  js:
    https://cdn.gtranslate.net/widgets/latest/dwf.js: {
      type: external,
      minified: true
    }
  dependencies:
    - gtranslate/init

@LaurentD

I do not see cdn_widget_dropdown_with_flags in the MR. Are you saying it should be added? If so what else should be added?

@minorOffense

The gtranslate block cannot be cached. Is this correct?

'#cache' => array('max-age' => 0), is set in gtranslate/src/Plugin/Block/GTranslateBlock.php

Should it be cached per role or per site?
Should per site be best since as of now, the settings do not change per user.
I am currently using it sitewide per theme.

This is interesting ✨ Asynchronous Google Translate Needs work

As far as I can tell since everything happens clientside the cache on that block should almost never expire. Only if the config changes or a CR. THe markup for the block is the same regardless.

I removed the cache set in my merge request ( I should have remove the commented out code too so I'll have to do that).

// '#cache' => ['max-age' => 0],

The markup is fixed, just the attached libraries change (which Drupal takes care of separately).

I should probably add the cache tags and contexts to the block so it clears when config changes. (I can see my notes from a month or two ago about doing so, haven't had time yet :-/)

@LaurentD Thanks.

Yeah there was a lot of copy/pasting to build out that library. I may have messed some of the dependencies up. I'll check again.

Block is not showing after I applied the patch.
do i need to totally uninstall.
I did do a drush cr and even cleared cache from the UI

The config changes made the block not show up at all with an upgrade. I had to do a full reinstall going from the 2.x to 3.x. I don't remember if I needed to do a full install between the 3.x versions.

There is something wrong.
I uninstalled and installed and it showed for a brief time.
Then I changed the settings and it disappeared.
Now no matter what I do I cannot get the block back.

Maybe add the cache invalidation when the config changes would help?

Right now, I have no gtranslate showing on my pages.

Great work! I've attached the patch here while waiting to be merged.