🇫🇷France @fmb

Member

Note : The user is automatically accepted in group hence he can create group stories right after join), i think stories creation might be limited either by an higher group role or by a people role eg. confirmed (i guess we could eventually rely on community validation as it’s used on drupal.org to confirm. people are not spammers).

This is how it is currently configured → . Now, how relevant this is, we may wonder.

Test permissions in my group:

add story > yes OK

Can create stories in his groups but cannot edit or delete those is it normal ?

I added the edit permission, but deletion is currently not allowed, maybe for good reason.

Translation community moderator

Test permissions in my group:

add story > yes OK


make suggestions > yes
 OK

moderate suggestion > yes OK


self moderate > no OK ?

Can create stories in his groups but cannot edit or delete those is it normal ?

Now they should be able to edit stories (but not to delete them).

Translation community manager

Test permissions in my group:

add story > yes OK


make suggestions > yes OK


moderate suggestion> no KO


self moderate > no KO


Maybe it's ok not to allow moderation and is intended to be used alonside with Translation community moderator when needed (which would make sense imho), can you confirm ?

You are right, this is the job of the translation community moderator.

Admin

Test permissions in my group:

add story > yes OK


make suggestions > yes OK


moderate suggestion > no KO ?


self moderate > no KO ?

I have just added this permission.

Any authentificated user has import tab avalilable on all groups (even when not in this group) bu the import trigger the following error
The website encountered an unexpected error. Try again later.

TypeError: Drupal\file\Upload\FileUploadHandler::handleExtensionValidation(): Return value must be of type string, null returned in Drupal\file\Upload\FileUploadHandler->handleExtensionValidation() (line 431 of core/modules/file/src/Upload/FileUploadHandler.php).
Drupal\file\Upload\FileUploadHandler->handleFileUpload(Object, Array, 'temporary://', Object, ) (Line: 660)
file_save_upload('file', Array, 'temporary://', 0) (Line: 143)
Drupal\l10n_community\Form\ImportForm->submitForm(Array, Object)

We are currently investigating on this one.

NOTE: a group member doesn't have a link to leave a group is it normal ?

No, it is not. I created 🐛 Incomplete block Active .

fmb → created an issue.

fmb → created an issue.

fmb → created an issue.

I understand Asset Inject → is the successor of this module.

It turns out the source value (whether it is correct or not) is correctly injected into the destination.

I believe this is an issue with the Bluecheese → theme (we are using the 1.x branch). I confirm there is no CSS rule associated to the form-required class, and the label contains neither a span element with an asterisk nor an ::after pseudo-element. Could this be related to Stable9, wich at some point must have replaced Stable?

Postponing, as we would be better off upgrading after the migration to Drupal 10/11.

The rest of the work happens in #3541994: Fix CI → .

The rest of the work happens in #3541994: Fix CI → .

I think this works well now.

fmb → created an issue.

Thanks!

fmb → made their first commit to this issue’s fork.

Thanks @colorfield!

@ericdsd thanks! Could you please review 🐛 Translation suggestion creation and moderation don't provide group permission Active first, and perhaps amend your report, as I fear there might be interferences between both issues?

For the record, you will need to configure group permissions at /admin/group/types/manage/translation/permissions#module-l10n_groups (since the MR is not merged yet, I cannot provide the corresponding configuration, which is stored in another repo).

Merci @mupsi !

Le statut d'intérêt général me semble en effet beaucoup plus facile à obtenir :

Selon la loi de 1901, vous êtes soumis à des réglementations pour votre association. Pour être reconnue d'intérêt général, votre association doit tout d’abord présenter "un caractère philanthropique, éducatif, scientifique, social, humanitaire, sportif, familial, culturel ou concourant à la mise en valeur du patrimoine artistique, la défense de l’environnement naturel"*. La loi de finances 2024 ajoute également à cette liste les organismes et associations luttant pour l'égalité entre les femmes et les hommes.

De plus, vos activités doivent être exercées en France. Il existe toutefois quelques exceptions : il reste par exemple possible pour des organismes établis dans un état membre de l’UE d’émettre des reçus fiscaux.

Enfin, votre structure doit également :

• avoir une gestion désintéressée,
• être à but non lucratif
• ne pas réserver ses activités à un cercle restreint de personnes.

L'activité s'exerce bien en France, la structure a bien une gestion désintéressée, est à but non lucratif et n'est pas réservée à un cercle restreint de personnes. Pour ce qui est du caractère à retenir, il faudrait voir si on peut retenir l'aspect éducatif. On en reparle.

goz → credited fmb → .

We cannot upgrade to Drupal 11 right now, since the following modules do not have a Drupal 11 version yet:

• drupalorg_crosssite →
• l10n_pconfig ✨ Automated Drupal 11 compatibility fixes for Plural formula configurator Closed: outdated
• bluecheese →

I suspect drupalorg_crosssite and bluecheese need to be replaced by other modules.

See 📌 Staging instance for D10 Localize port Active .

We ended up setting up a private staging instance.

At the same time, I notice that since commit d941cd35 from #3395327: Replace xmlrpc for new localize.drupal.org, we are not using that field anymore.

Mmmh, but we will need a way to store credentials for a given user in 📌 Localize client authentication with d.o infrastructure Active . But then, of course, nothing forces us to use a field if we judge this is not an appropriate solution (personally, I do not think it is, though it certainly appears to be the easiest method at first).

If for whatever reason we decide to stick with a field, we would need a way to advise users to manually delete the field first, just like we need to manually delete content when removing an entity type, for instance. Since this task might not be trivial, this is another argument against using a field in this context.

I notice that the submodule does not have a README.md or .txt.
Should we add one, or put everything in the main module README?

I think a README for the submodule would be fine.

fmb → created an issue.

Thanks!

All right, let's move it here then.

The commented part in l10n_packager_cron() creates queues that will later parse releases. This part did not exist in the Drupal 7 version. Besides, we already have a drush command (drush 10n_server:parse) which implements this and could be used directly in a crontab. Implementing this feature also in a queue would either lead to code duplication or require some refactoring. How relevant is this?

fmb → created an issue.

fmb → created an issue.

Validation des traductions et poursuite du développement de Localize D10.

nicoloye → credited fmb → .

fmb → created an issue.

What is the translation you are trying to save?

fmb → created an issue.

fmb → created an issue.

Thanks!

fmb → made their first commit to this issue’s fork.

Thanks!

See 📌 Update groups to 3.x Active .

I think this has long been fixed.

fmb → created an issue.

submit suggestions. moderate suggestions from others, moderate own suggestions are now group permissions instead of global permissions.

In a follow-up issue, we should also review other permissions (see attached capture of Drupal 7 group permissions configuration). As some of them are currently used in routes, I am leaving as they are for the time being.

fmb → created an issue.

Fastly dealt with in 📌 Review integration of l10n_drupal_rest with drupalorg_crosssite Active .

Fixed in 📌 Improve code and performances of the homepage Active .

Make this step optional and improve documentation to explain how to import projects and strings.

For performance reasons, these data will be kept in cache for 3600 seconds before they are updated.

For performance reasons, these data will be kept in cache for 3600 seconds before they are updated.

Will be dealt with in 📌 Finalize l10n_packager route /downloads. Active .

This feature will not be supported by the new 3.0.x branch.

It turns out that docker-compose.chromedriver.yaml is not actually needed by anybody working on the project, so I removed it.

Wow, thanks a lot Randy for passing by here! Much appreciated.

I am sorry I did not give enough details. The main module is here, but the platform is on gitlab.com. We are talking about this file.

I think we are good regarding suggestions, can somebody review this?

Now, It looks like at least some global permissions defined in l10n_community.permissions.yml should be turned into group permissions. Then, we may get rid of global permission checks in L10nAccess, but this could be done in a follow-up issue.

fmb → created an issue.

Even as a maintainer, I cannot use "git push --force" on a branch which is used for a dev release.

Mainly, the culprit is this commit which caused a conflict in l10n_contributor.module which was not correctly dealt with, introducing again the l10n_client_contributor_send_translation() function which had been previously removed in a previous commit (for good reason, as it is now implemented in a service, plus it used xmlrpc). Some things need to be removed (like old xmlrpc-based tests) but this commit cannot be held as responsible.

I think this can now be closed, since the rest of the work (authentication) will be dealt with in 📌 Localize client authentication with d.o infrastructure Active .

I was able to successfully test this in a new installation (the only thing to know is that you need to manually install External Entities first because of some dependency on external_entity_type, but I guess this is a completely different matter). Thanks!

@guignonv I wondered why this MR was so gigantic when I realized you had requested a merge into the 7.x-1.x branch. I took the liberty to edit the MR to set it to 2.0.x.

Thanks Guiu! I successfully tested this on a development Drupal 7 instance. Failing tests are not related to this change. @drumm, could you deploy this onto the live instance (localize.drupal.org)?

@kartagis for now, the fix was applied to the 3.0.x branch of the l10n_server module, which is currently under development. The next step is to backport it to the older 7.x-1.x branch, which is still the live version (i.e. the on on localize.drupal.org).

It is a good thing that JSON:API does not match, it means it will not be mistaken as a replacement token.

Thanks Guiu! This now needs to be backported to 7.x-1.x-dev.

fmb → made their first commit to this issue’s fork.

Thanks @donquixote!

Thanks for spending time on analyzing this bug. We do not really care about data deletion in this case. I would say it is expected to remove the key when the module is uninstalled. Generating a new token would not be that hard anyway.

Thanks for reporting this. Is it also happening with the latest Git version?

String 5052 (Audio File Info) does not have this issue. In string 2718592, the "JSON:API-specification-compliant" is partly interpreted as a replacement token (:API-specification-compliant), apparently because of the colon. If you can replicate this bug, it might be related to the regexp in the TranslateForm::validateForm() method.