dan2k3k4 → credited artusamak → .
Fix pushed in MR.
Artusamak → created an issue.
dan2k3k4 → credited Artusamak → .
dan2k3k4 → credited Artusamak → .
dan2k3k4 → credited Artusamak → .
dan2k3k4 → credited Artusamak → .
jjchinquist → credited Artusamak → .
dan2k3k4 → credited Artusamak → .
dan2k3k4 → credited Artusamak → .
dan2k3k4 → credited Artusamak → .
dan2k3k4 → credited Artusamak → .
Hi, thank you for your proposition, i've granted you maintainership access to the repository. I'm not maintaining it anymore so be my guest to fix it and bring it forward. ;-)
mradcliffe → credited Artusamak → .
Artusamak → created an issue.
Thank you.
Ahah, after obscure digging i found something! (Searches for d.o API information that are really related to d.o itself are not easy to find with all the modules that pops for related features :D).
The key page is https://www.drupal.org/drupalorg/docs/apis/rest-and-other-apis#s-get-the... → that lists exposed endpoints.
We can extract project usages from it, eg:
https://www.drupal.org/api-d7/node.json?field_project_machine_name=flag →
Two drawbacks:
- it doesn't look like there is an aggregated query available, leading to multiples calls that will have to happen against the node endpoint (one per project every x weeks).
- the usage are aggregated per branch(?) and not per release so, we may not be able to lead to the latest releases if we want to guide translators. It is balanced by the fact that we'd probably like to promote projects as a whole more than specific releases.
Interesting to see that this never went in. :D We even lost the usage access on projects since.
It looks like there was a dedicated table that was populated on D6 version: https://git.drupalcode.org/search?search=project_usage_week_release&nav_... but it's not here anymore. By any chance, does anyone remember why this information has been cut off?
We could leverage such information. I don't know if we have an API parsable way to extract usage stats from d.o. We could ask to have it exposed as we extract the releases maybe?
It could be interesting to be able to extract "promoted" releases that are exposed on project pages on d.o in order to focus translations' suggestions on those.
Eg for
Flag project →
, it would be:
- 8.x-4.0-beta4
- 7.x-3.9
Can we agree that it's a similar issue to #1095806 ?
As of today we don't have access to the usage statistics of the projects on d.o to increase the translations impact. The most we could do is find a string that have multiple usages across projects.
Still your suggestion is interesting. Let's see if we can get the usage info available.
What is remaining on this issue? Import & export ports have dedicated issues and a comment says the problem has been solved.
Can this issue be closed @FMB?
This issue has been covered in #3338991
Artusamak → created an issue.
Alright, the MR is now reviewable. Thank you TeeBeeCoder for the pair programming.
I allowed myself to rephrase the form input labels and comments to try to be more explicit for new comers.
I also added code context for the choices made in the MR.
Trying to discuss with Thomas how to solve it.
Yes, the trustedCallbacks needs only to be declared for pre_render callbacks.
Details here: https://www.drupal.org/node/2966725 →
Two above points are fixed.
There is now the last step not working which is the project selection with autocomplete. I managed to extract the project ID from the autocomplete response but the AJAX process triggers the form submission despite not having clicked on "Export Gettext file".
I tried the tricks to use $form_state->setRebuild() in the ajax callback or the #limit_validation_errors attribute but it didn't change the outcome. When i input a project name in the field, the form is fully submitted and the triggering element is set to the full form (which is what we DONT want).
Once this issue is solved, the export form will be fully functional.
I have a working export form. I rephrased the export options to be consistent and understandable since what we had in ldo was sometime surprising as an export result.
Remaining tasks are:
* Trying to cleanup the URI value expected to be an internal project ID in \Drupal\l10n_community\Controller\L10nCommunityLanguagesController::export().
* Doing additional testing with the ajax selector that have inconsistent behavior based on the step you follow to export (sometime the releases are not listed, sometime they generate an error). It's hard to define the blocking steps to reproduce.
I didn't open the merge request yet since the first remaining task is important to be cleanup in my opinion (but the commits are shared).
Artusamak → created an issue.
Having a look at it.
For which hooks would you like to use this pattern? From what i can see, they mostly call services we probably don't want to use that pattern there. I don't see interesting candidates. 🤔
Well, it looks like it has been solved. ;-)
There is a fix for the broken line in #3297480 but for a weird reason, composer install doesn't fetch the latest version.
Let's consider it as fix for now.
Artusamak → created an issue.
Can you add the steps to reproduce the issue please?
The issue still exists in 3.x branch and it is an issue if you are using Oauth authentication.
Steps to reproduce:
* Add a required agreement to your site
* Bind your site to a Oauth login flow
* When you get a call to /oauth2/authorize the Agreement module catches the request and redirects the user to the agreement form (which is a good thing)
* (Read and) agree to the Agreement, submit the form
* Your authentication is broken since the extra arguments injected in the call to /oauth2/authorize have been trimmed.
We need to preserve the query parameters to let the user login properly after agreeing to the Agreement (and reading it!).
If you go to language weighting and don't know it yet, UNESCO has 6 levels of classification for languages:
* Critically endangered
* Severely endangered
* Definitely endangered
* Endangered/unsafe
* Potentially vulnerable
* Safe
They are monitored, updated and documented here: https://en.wal.unesco.org/
dan2k3k4 → credited Artusamak → .
Artusamak → created an issue.
Here is a patch for that.
Artusamak → created an issue.
First step implemented in #3356894
It looks great but beware of #states, since it only hides / shows the subform fragment, you may end up with inconsistent form states values if no cleanup is managed afterward (maybe you already did, i didn't examine the MR).
Use case would be:
* Check an entity type
* Check several bundles
* Uncheck the entity type
* Submit the form
The bundle might end up selected since they are still checked in the final submitted form.
Please ignore this if it's irrelevant with what has already been implemented, i just wanted to wave a caution flag!
Feedback given, thanks for this very needed task!
My Drupal life started almost at the same time as you becoming a more and more prolific contributor.
You've been truly inspiring and an example for motivation and kindness.
I've been honored to meet you when you attended DDD 15 in Montpellier (gosh, time flies...).
You will remain one of my favorite person on the internet!
Thank you, keep rocking! \o/
It's the same behavior for nodes.
Artusamak → created an issue.
I guess that if there should be no god mode, the user #1 should not be able to access this view unless he/she has explicit access via group permissions as any normal person?
Will not happen in 8.0.x-dev since it's not critical.