Right. That is also a solution.
The way we have solved in custom code is the following:
- Create a custom action which add all the selected entities to the cart using the service tmgmt.cart. You may need to add the action per entity or alter it using hook_action_info_alter() afterwards to get it added to all translatable entities.
- Create a view that list all the terms in a vocabulary. It should include the bulk actions column and the new action enabled.
We implemented this solution for taxonomy terms, menu links etc. to make it much faster to translate these entities. Both our taxonomy term and menu link views are just flat lists and not showing the hierarchies.
Unfortunately we cannot use the same logic in 2.3.x, where the Source/ Target languages are retrieved via the API.
In case of English we would get EN-GB and EN-US.
So we will still need to fix the mapping manually - even if we get use the remote language mappings. But since we are using remote language mappings custom langcodes are working also.
Interesting. I'm quite busy this week and next week, but would be happy to help with testing our big multilingual installation on 2.3.x mid/ultimo February if it is not too late for your rollout plans.
Thanks for your input @steffenr!
I'm aware that it is common to follow the ISO 639-1 notation and it also works fine in most cases, but not in all....
Our current case is a bit different and not the most common. It is a global multilingual website where each country/market have their own area under one global domain. Each country/market has one or more languages and use language codes in the format country-language e.g. sm-it and sm-en for Italian and English languages for San Marino. We have at 75+ languages configured with fallback and other things. We have for example 20+ country specific English languages configured with fallback to one main English language (eu-en).
The glossary matching functionality will always take the first two letters based on ISO 639-1 and will use this for its matching logic.
You could get rid of fixLanguageMappings() completely if the code moved from the local language pairs to the remote language pairs in the job entity, as the remote language pairs will always use the format expected by DeepL and that is stored in DeepL's glossaries.
The proposed resolution is implemented in the issue fork.
beltofte → created an issue.
Since Drupal 10.1, the revision UI for block has been implemented by core. See #1984588: Add Block Content revision UI
In other words, you don't need this module anymore.
Wrong. Drupal core now supports a revision for block, media, taxonomy, but it does not support a diff between two revisions. Nor does the Diff module it self at the moment (work is in progress https://www.drupal.org/project/diff/issues/2452523 → ), and this is the reason why Entity Diff UI is still relevant as a temporary solution till Diff support block, media, taxonomy etc.
The duplicated tab issue also exists on Taxonomy terms...
@SteffenR: Thanks for this killer-feature. What is the plan to get a tagged version of the 2.3.x-branch?
Fixed in https://www.drupal.org/project/siteimprove/releases/3.0.1 → .
Thanks for helping with the Drupal 11 support.
@morten: We need this added to the 3.0.x branch next week.
The following changes have been implemented:
- Logo.png added to Git
- Summary added to the project page.
- Module/project categories updated.
beltofte → created an issue.
Ready for review.
beltofte → created an issue.
beltofte → created an issue.
+1 for rolling back the name change + documenting on the project page that the developers and site owners should NOT use the 10.2.0 tagged release nor the 10.0-dev version.
Compared version 10.0.0 and 10.2.0 and this major name change has not been documented with a single line. There is also no issue in the queue covering the renaming as far as I can see. This is really bad practice and causing big headaches for us too, as we have a bigger Canto integration built on top of the Canto Connector module.
I have seen many weird things in my 17 years on d.o, but this definitely end in top 10.
Co-maintainer ship granted. Thanks for helping moving this module forward.
Moving to "Drupal.org project ownership".
Source project: https://www.drupal.org/project/canto_connector →
Right. The official process to get maintainer access is described in the link I posted in my comment:
If the owner does not reply after two weeks, move the issue to the Drupal.org project ownership issue queue, by changing the issue's Project field to Drupal.org project ownership. Please include a link to the project page.
Site moderators will normally try to contact the owner as an extra safeguard unless it is evident the owner is no longer active in the Drupal community, giving to the contacted users two weeks for replying to the message they sent via the Contact tab.
beltofte → created an issue.
Committed. Thanks for reviewing the patch!
Thanks for working on the fix. parse_str() returns either an array or FALSE, and isset() will return TRUE even the variable in argument is FALSE. I have therefore change it from isset() to !empty(). Also implemented a minor change to the foreach loop filtering unwanted query parameters, as $query_parts may not be set.
beltofte → created an issue.
A bit late, but implemented a small wrapper method named filterValidItemIds in ContentEntityFallback which tries to handle the problem. Thanks for reporting this issue.
Thanks all for helping fixing the coding standard issues. I fixed the issues locally with phpcs and also implemented some further adjustments to comments in the code and other things.
Reviewed and merged. Thanks for fixing this issue.
beltofte → made their first commit to this issue’s fork.
Merged. Thanks for fixing the issue!
beltofte → made their first commit to this issue’s fork.
Committed. Thanks for help testing the patch!
@bartvig: Please, look into the temporary fix we discussed and commit it to both versions.
beltofte → created an issue.
Update screenshots and texts to match new version of the Siteimprove overlay UI.
Update screenshot with admin toolbar due to new Siteimprove logo.
Update screenshot + add new bullet with info about the use latest experience checkbox.
Fixed. Included in today's releases.
Committed. Thanks for helping solving the issue. Included in today's releases.
Fixed. Included in today's releases.
Fixed. Included in today's releases.
beltofte → created an issue.
Fixed in both 2.0.x and 8.x-1.x branches. Need backport to 7.x-1.x
Support for Group 3.1.x added in the issue fork. It includes a bit of rewrite of the code in siteimprove_toolbar() too. MR created and assigned to @bartvig.
Notice: The MR is only tested on Group version 3.1.0 and NOT tested on earlier minor or major versions of the module. The code does not really on any API calls or similar to the Group module, but solely "white list" some menu routes and support enabling prepublish for specific Group Types. So it may work on earlier major versions of the Group Module.
Backport: We will not backport this change to the 8.x-1.0 branch, as none of the recommended versions of Group nor the old 8.x-1.5 version supports Drupal 8 or the early minor versions of Drupal 9.
Code changes committed to 8.x-1.x.
Code changes committed to 2.0.x,
Code changes committed to 2.0.x and 8.x-1.x. Thanks for reporting and help fixing the issue.
@bartvig please review and merge.
beltofte → created an issue.
beltofte → created an issue.
Hi Jari,
The issue here is that we have a whitelist of route names where the Siteimprove plugin should show the "This page"-tab (method: input) and fallback to the "Site summary"-tab (method: domain) on all other routes. Right now is whitelist only including entity node and taxonomy_term routes, and not on group routes for example. We will discuss the issue with our Siteimprove contacts and get back to you.
Best regards,
Jens Beltofte