Gabriel Barata

I was also expecting the action to be self contained. For example, there might be two client projects, using the same Crowdin project, leveraging the github action to download the...

Thank you for the response, @andrii-bodnar. So, if we want to have the very same translations and just use two different translation formats, i.e, export the files with a different...

My last comment concerned a future use case. Our current use case is a bit more simple but still affected by this issue. We have the following consumers of our...

Build broke initially because of incompatible versions of `@lit/reactive-element` between `mwc-snackbar` (which used an old one) and elements. This [PR](https://github.com/material-components/material-web/pull/3057) landed and a new release of `mwc-snackbar` was done, which...

Please ignore 8b68ad0f09ef60c4842ade12363d73159ec7bcf4, a3beb615a2bff62b769686e8ad5588f3f4bccf83 and 0127b757e95cc41fb6c4f49333fc31bf7554bb3d.

Requirements: - Update `vaadin-date-picker`, which is already planned (see [WEBUI-799](https://jira.nuxeo.com/browse/WEBUI-799)). - Update nodejs version, which is already planned (see [WEBUI-792](https://jira.nuxeo.com/browse/WEBUI-792)). - Update `mwc-snackbar` (4e4e1ce17af37bf92607ca7a3f3d49df4a5d5648). The API of the element seems...

Beyond the requirements, no further effort is needed on the Web UI side to make sure an element that was converted on `nuxeo-elements` can be safely used.

I proposed it as a custom code on the ticket. If it accepted as a workaround we won't have to merge, which is probably the safest path.

It is my understanding that we already have debouncers in place that prevent too many request to be made, so I wouldn't expect this to degrade performance, but I would...