IMPORTANT: We would like to use the file structure /front-end/src/locale/{iso}.js, would this work ?

I don’t see /front-end/src/locale/{iso}.js, but I do see a directory named /front-end/src/i18n (i.e. the last piece is i18n rather than locale), which contains en.js, en.json, de.json and fr.json. So what do you want, JS or JSON?

IMPORTANT: Our repository is on gitlab.wikimedia.org, let me know if we need to move to github.com or anything to invite your bot.

There are already some repos from gitlab.wikimedia.org supported by Translatewiki, including https://gitlab.wikimedia.org/repos/wikimedia-france/qrmedia, so I don’t think this should be a problem (although I’m not an expert of Translatewiki configuration).

@Tacsipacsi hello, thank you for your guidance.

Locales

• /locale/{iso}.js is favored by Python / Django projects I believe.
• /i18n/{iso}.json is the banana.js & translatewiki convention. I asked our main dev to migrate to this few days ago, but it could cause side effects.

I would like to know if we can change the files paths, and if so what is the procedure. There is the possibility our paths change in coming months. By example due to T375962 .

Gitlab bot

About Gitlab I jumped in and invited L10n-bot. I already worked with it on Github.

Messages documentations (qqq)

Last, the qqq.json isn't created yet, but it will come within a month.

On T373191 @Raymond specifies :

qqq.json is empty. Without a complete message documention it is not possible to register the repo on translatewiki.net

So I will contact you back when our qqq.json is mature and done.

In T375653#10223973, @Tacsipacsi wrote:

In T375653#10223856, @Yug wrote:

So I will contact you back when our qqq.json is mature and done.

Okay, I set the task stalled for now. Feel free to set it to open once the documentation is ready.

You set the task to open (six days ago), but I still don’t see message documentation in the repo, while I do still see both en.js and en.json. Are you sure this is ready to be worked on by the TranslateWiki people?

(A side note: I noticed that there hasn’t been a single CI pipeline that would have passed without warnings. I don’t think failing pipelines would cause any issues in the TranslateWiki integration, but it’s generally not a good practice: if you set up CI, you should keep it passing. Otherwise you could just throw it out, and don’t let CI runners work unnecessarily.)

The qqq.json is coming. Please wait a bit, I plan to clean this up this week. Should I stale then reopen ?
Thank you for the CI advise, we may move to take this off indeed.

In T375653#11019580, @Yug wrote:

The qqq.json is coming.

And what about the two English files?

Should I stale then reopen ?

Setting the task to stalled signals to the TranslateWiki people that it’s not yet actionable for them, so yes, I’d do so.

Thank you for the CI advise, we may move to take this off indeed.

I’d try to fix it if possible (being a Python+JavaScript project, there are no compile-time checks, which makes tests important to avoid regression), but removal is still better than constant failure.

Hello @Tacsipacsi,
I cleaned up the the gitlab directory:

• i18n/qqq.json added, work is ongoing.
• en.json is the translation of reference.
• en.js got deleted

I believe we are good to go, let me know. 👍🏼

Thanks! I opened a merge request with a couple of copy edits. Other questions/requests (I hope all or most of them can be addressed before translation is enabled to avoid waiting translators’ time, but do tell if some take much longer to fix):

• The button says “Log in through Wikimedia Commons”, but it brings me to Meta, not Commons, and asks for permission to edit pages on any Wikimedia wiki. Could this be changed, so that it really goes to Commons, and it requests permission only there?
• There are a couple of “common” messages. This practice is discouraged, for example because of gendering issues.
  • I don’t know if it’s really correct in French to always use précédent and never précédente, but I’m sure there are languages in which it’s problematic.
  • In what context will the words “Wikipedia” and “Wiktionary” be used? (They’re currently unused.) In agglutinating languages like Hungarian, it’s a pain to translate messages that include such words as parameters, as the word “Wikipedia” can be “Wikipédia”, “Wikipédián”, “Wikipédiába”, and so on, depending on the context, and it’s impossible to change the last letter of the word “Wikipédia” (a to á) if it’s a parameter. Similarly, the deletion popup passes locutor as a (not even translatable) parameter, which is used in three different messages; the three messages may not need the same word form.
  • So please constrain the meanings of these messages, for example by saying that common-previous will always mean “previous step” (and not, for example, “previous file version”) or that common-close will always mean “Close dialog” (and not, for example, “Close case”). Please also remove unused messages, or at least document where you plan to use them.
• In the locutor step, I see “1 languages”. This is incorrect, it should be “1 language” (but “2 languages”). See pluralization docs. I’m not sure if translatewiki.net supports this syntax, but worst-case it just doesn’t touch it, and translators will have to figure out (with the help of the message documentation) what to do; even strange syntax is much better than an untranslatable message.
  • batches-view-title contains a parameter, but that cannot be used for pluralization, please fix that one as well.
• Languages at various places appear in French, despite my UI language being set to English.
• Could locutor-main-required and locutor-main-nodelete be merged in the same message? They form one Codex message, and it’s easier to translate one (Codex) message as one (i18n) message.
• locutor-languages-proficiency-default doesn’t actually ever appear, as languages always have proficiency set (a newly added language automatically has Beginner). Either there should be no proficiency pre-selected, forcing the user to select one, or the message can be removed.
• language-proficiency-professional is missing from the dropdown in the locutor form. It’s used in the language selector, but how would such a proficiency be added to the database?
• locutor-licence-guideline isn’t used at all.
• locutor-licence-CC0, locutor-licence-CCBY4.0 and locutor-licence-CCBYSA4.0 aren’t used at all, hardcoded English strings are used instead. Either the messages should become used (in this case, the latter two should be fixed: they should be CC BY 4.0 and CC BY-SA 4.0, the spaces and dash are important), or the strings should be queried from Wikidata.
• The message languages-proficiency should include the colon and a placeholder for the proficiency to ensure that translators can apply the appropriate spacing (e.g. as far as I know, there should be a space before the colon in French; other languages like Chinese use characters other than : for colons). Again, I’m not sure if translatewiki.net can handle this syntax, but unsupported syntax is better than untranslatable.
• hardware-permission-image-alt is not a good alt text. Ideally, it should textually describe what the image shows (i.e. that the user should look for a permissions button in the URL bar and allow microphone/camera access there).
• lists-placeholder, lists-hint-homographs, lists-hint-edit, lists-alert-few, lists-filter-limit, lists-filter-remove-by-community, lists-filter-remove-by-user, lists-generators-local-title, lists-generators-nearby-title, lists-generators-categories-title and lists-generators-categories-code aren’t used at all.
• record-guideline isn’t used, hardcoded English text is used instead. I find the blue word much more confusing than helpful, so I’d just drop the styling and use the message.
• I tried to find out whether the shortcut p is localizable (I guess it should), but I couldn’t find it out; I guess the shortcut doesn’t work at all.

Comments not related to i18n (sorry for being a bit off-topic here):

• The locutor and language selectors are not keyboard-accessible: they’re <label>s, but the corresponding <input>s are not interactive because they have display:none.
• How can I save a new locutor without doing a recording? Maybe I want to create the locutors before I meet with the people, so that I don’t waste their time with filling out forms (or I just want to use another device: for recording, a smartphone is a good fit, as it’s portable and has a built-in microphone, but a complicated form is hard to handle on a small screen, and doesn’t require a microphone).
• In the list step, Remove words already recorded is non-functional (it has no click listener). This also means I could only guess what it means.
• alert() should probably not be used, but rather some non-blocking way of feedback.

Hello @Tacsipacsi , your review was quite broad so I couldn't attack it before. I started my review. Will need some time to address it in full. But thank you already for this deep review !

I will answer with the same structure, with numbered list, but be as short as possible. Using nc for no comment.

1. ✅ Oauth target is Meta : We decided to log in to meta due to possible software extension in coming years (multi wiki Lingua Libre bot). The message now reads "Log in through Wikimedia"
2. Common message:
   1. ✅ and gender : for French, it's mostly ok, you can assume it's La page (f), or L'onglet (m), natives locutors have some flexibility on those.
   2. ✅ unused : ok, I removed common-Wikipedia and common-Wiktionary
   3. 🔸 need constrains: received, I will watch more carefully.
3. ✅ Pluralization: 1 languages -> I created singular "locutor-menu-language":"language", but I would favor merging both into "locutor-menu-languages":"language(s)" with translators figuring out a way.
   1. 🔸 `batches-view-titles: I would prefer to keep this title plural by default, a list of batches as a bag dedicated to apples can be empty or have just one apple.
4. French labels while settings are on English : needs a phab ticket and review. Now we know, good catch 👍🏼
5. ✅ locutor-main-required and locutor-main-nodelete : agree, both messages merged.
6. ✅ "locutor-languages-proficiency-default" : removed.
7. 🔶 "language-proficiency-professional" (C2) : good catch, we see different value when in LanguageStep.vue L36 and LocutorStep.vue L210. Needs review.
8. ✅ "locutor-licence-guideline" : merged "locutor-licence-future-guideline" into "locutor-licence-guideline"
9. ✅ CC acronyms x3 : implemented in the code.
10. ✅ "languages-proficiency": fixed and renamed into "languages-proficiency-with-colon"
11. ✅ "hardware-permission-image-alt" text improved.
12. 🍏 list-* : on hold for next development round.
13. ✅ record-guideline: moved to $t('record-guideline'), considering removing it entirely.
14. 🔶 p for play audio: indeed, this is not localize as of now. We assumed user would have an latin alphabet keyboard. Need to think about it

Other comments :

1. 🔸 Keyboard-accessible : indeed, early steps are not keyboard-accessible. We don't have the HR as of now for that.
2. ✅ Pre-create speaker: I just tested your scenario, you actually can, just go through step 1 to 2.
3. 🔶 Remove words already recorded: has no listener, good catch indeed (I forgot about that one).
4. 🔶 alert() : received, we will monitor that.

Ok, I pushed the changes to the repository. Could you help us move this to translatewiki validation ?

In T375653#11190138, @Yug wrote:

1. ✅ Oauth target is Meta : We decided to log in to meta due to possible software extension in coming years (multi wiki Lingua Libre bot). The message now reads "Log in through Wikimedia"

If it’s a bot, you don’t need permission for that, since it doesn’t happen in the user’s name. Or do you simply mean editing many wikis in the user’s name? In that case, the permission is indeed necessary, but I’m not sure if I’d like a tool to edit many wikis in my name (with no way to prevent it other than not giving it any permission, or not pressing the button and hoping for the best), couldn’t that be made optional? Also, if it’s not a separate account, please don’t use the “bot” wording, it’s confusing.

2. Common message:
   1. ✅ and gender : for French, it's mostly ok, you can assume it's La page (f), or L'onglet (m), natives locutors have some flexibility on those.
   2. ✅ unused : ok, I removed common-Wikipedia and common-Wiktionary
   3. 🔸 need constrains: received, I will watch more carefully.

You named two words with two different genders even in French, let alone other languages. I wouldn’t call it “mostly OK”; I still ask you to constrain the meaning of the messages – present ones just as well as eventual messages added in the future. Thanks for removing Wikipedia and Wiktionary!

3. ✅ Pluralization: 1 languages -> I created singular "locutor-menu-language":"language", but I would favor merging both into "locutor-menu-languages":"language(s)" with translators figuring out a way.

That’s exactly what pluralization is about. You just need to provide the number as described by the documentation – otherwise vue-i18n will have no idea what number you mean.

A. 🔸 `batches-view-titles: I would prefer to keep this title plural by default, a list of batches as a bag dedicated to apples can be empty or have just one apple.

You are free to do that in English and French, but please still give translators a choice – this reasoning, which makes perfect sense in Indo-European languages, may fail in other languages. If you prepare it for plural handling, that’ll give you an implicit parameter, so you don’t have to provide two parameters.

4. French labels while settings are on English : needs a phab ticket and review. Now we know, good catch 👍🏼

Thanks in advance for fixing!

5. ✅ locutor-main-required and locutor-main-nodelete : agree, both messages merged.

Thanks!

6. ✅ "locutor-languages-proficiency-default" : removed.

Thanks!

7. 🔶 "language-proficiency-professional" (C2) : good catch, we see different value when in LanguageStep.vue L36 and LocutorStep.vue L210. Needs review.

Thanks in advance!

8. ✅ "locutor-licence-guideline" : merged "locutor-licence-future-guideline" into "locutor-licence-guideline"
9. ✅ CC acronyms x3 : implemented in the code.

Thanks for both!

10. ✅ "languages-proficiency": fixed and renamed into "languages-proficiency-with-colon"

Thanks, but I also asked for a placeholder. The space is also problematic in some languages, for example in Chinese, where the localized colon character ： includes the spacing and thus should not be followed by another space. (And including the space but not the parameter is problematic because MediaWiki would simply cut the space off when saving translations on translatewiki.net, so the majority of languages, which do need the space, would be broken.)

11. ✅ "hardware-permission-image-alt" text improved.

It’s still not really good. Imagine you see the alt text instead of the picture (because that’s basically what people using screen readers – or people on unstable connections – get), would you get the same amount of information? For example, where to look for the permission settings? And is all information you get relevant? For example, do you really need to state that this image is an illustration?

12. 🍏 list-* : on hold for next development round.

In this case, I’d remove them for now (they can always be restored from Git history), so that translators don’t get confused if they want to check what they’re translating in action; and they don’t work unnecessarily in case that next development round doesn’t use them or uses different wordings.

13. ✅ record-guideline: moved to $t('record-guideline'), considering removing it entirely.

Thanks!

14. 🔶 p for play audio: indeed, this is not localize as of now. We assumed user would have an latin alphabet keyboard. Need to think about it

But does it work at all? I pressed it (Firefox 140), and nothing happened.

Other comments :

1. 🔸 Keyboard-accessible : indeed, early steps are not keyboard-accessible. We don't have the HR as of now for that.

I understand that, but you should fix this before you can call the app production-ready.

2. ✅ Pre-create speaker: I just tested your scenario, you actually can, just go through step 1 to 2.

I added a new locutor in step 1, selected a language in step 2, and when I was at step 3, I refreshed the page, and the locutor was not there. (Currently I have !73 checked out, although I don’t think it matters a lot.)

3. 🔶 Remove words already recorded: has no listener, good catch indeed (I forgot about that one).

Could you please either fix it, or comment it out and remove it from translation if you need more time to fix it?

4. 🔶 alert() : received, we will monitor that.

Thanks in advance!

Ok, I pushed the changes to the repository. Could you help us move this to translatewiki validation ?

There’s still work left that should be done before this goes to translatewiki.net, see above. After that, I may try to prepare a patch, but I’ll definitely need help for how to handle the vue-i18n syntax (if I have time for this at all at that time – I’m entirely volunteer here).

Hello and thanks again Tacsipacsi,

I will use the numberings use above to answer your remaining concerns :

1. ✅ Oauth : I requested a Commons Oauth, here, it will take ~2 days to get approved.
2. > C ✅ common-* need constrains: edit made here.
3. > A ✅ `batches-view-titles: ok, let's try this vuei18n feature. I implemented it and explained it in the qqq.json, see here.
4. 🔶 language-proficiency-professional: there are references to id values so it may be connected to the database. I will ask Pushkar if editing this would have negative side effects.
5. ✅ Keyboard controls : I think I fixed it, I changed the code from 80 (Uppercase P) to 112 (lowercase p), here.

Others:

1. 🔸 Keyboard-accessible : I not sure what you mean by that. I believe you want, for the elements screenshoted below, to be able to use previous/next via the keyboard arrows ?? We don't have budget anymore for new-feature on this coding cycle. I don't understand the link with the explaination below:

Tacsipacsi: they’re <label>s, but the corresponding <input>s are not interactive because they have display:none.

2. ✅ Create a speaker but not doing any recording : I tried again via two different browsers and it works for me, the speaker profile is available to my 2nd connexion and web browser.
3. 🔸Remove words already recorded: ok, will hide that feature for now.

<CODE EDITING ONGOING, COMMIT TODAY.>

{F66088178}

{F66088177}

In T375653#11199498, @Yug wrote:

1. ✅ Oauth : I requested a Commons Oauth, here, it will take ~2 days to get approved.

Thanks!

2. > C ✅ common-* need constrains: edit made here.

Thanks! However, the documentation should also be updated, it still says could be used at different places of the app for many messages.

3. > A ✅ `batches-view-titles: ok, let's try this vuei18n feature. I implemented it and explained it in the qqq.json, see here.

The commit you linked is from Wednesday. As I wrote, you didn’t provide the number as a parameter to the message; nor did you fix it since then. The upload batches are also wrong: I have 6 batches, yet I see My upload batch (1) – probably because the fallback, in case there is no number provided, is one.

7. 🔶 language-proficiency-professional: there are references to id values so it may be connected to the database. I will ask Pushkar if editing this would have negative side effects.

Okay.

14. ✅ Keyboard controls : I think I fixed it, I changed the code from 80 (Uppercase P) to 112 (lowercase p), here.

Thanks, it indeed works now. However, I’m not sure if it’s a good idea in the follow-up commit to accept both p and its translated version (if any); I think it should be either translatable or untranslatable, not a mix of both.

Others:

1. 🔸 Keyboard-accessible : I not sure what you mean by that. I believe you want, for the elements screenshoted below, to be able to use previous/next via the keyboard arrows ?? We don't have budget anymore for new-feature on this coding cycle. I don't understand the link with the explaination below:

Tacsipacsi: they’re <label>s, but the corresponding <input>s are not interactive because they have display:none.

Unfortunately I don’t see the images (please attach them to the task), but I try to be more specific about the steps to reproduce:

1. Open the app.
2. Press the Tab key until you select your main locutor. This won’t happen!
3. Give up, and use your mouse to select the locutor. Note that people without a pointing device, for example blind people or those who can’t operate a mouse due to tremors, won’t be able to do this!
4. Press the Tab key until you select the Next button, and use the spacebar or Enter key to press it. (This will succeed.)
5. Now press the Tab key until you select a language. Again, this won’t happen!

This isn’t a “new feature”, keyboard accessibility should be the bare minimum, not a question of budget. People with disabilities have rights, internationally, in the European Union and probably also in France specifically.

2. ✅ Create a speaker but not doing any recording : I tried again via two different browsers and it works for me, the speaker profile is available to my 2nd connexion and web browser.

It still doesn’t work for me, not even in the latest version, but I realize I changed/commented out some parts that I didn’t commit so that I can use the interface without an OAuth consumer (since I don’t have access to your credentials – nor should I –, and I was too lazy to create my own owner-only consumer), so that may be the cause. However, in any case, this procedure isn’t obvious, so it’d be nice if there was another way to do this. (But unlike the keyboard accessibility, this is negotiable, as it doesn’t affect people with disabilities disproportionately.)

3. 🔸Remove words already recorded: ok, will hide that feature for now.

Thanks!

<CODE EDITING ONGOING, COMMIT TODAY.>

Note: you don’t need to send your comment on Phabricator immediately. You can start drafting it, rephrase, extend etc. it as you work, and send it only once it’s ready. Phabricator saves the draft even in case you close the browser tab. This way, I’m notified only once you finished everything.

1. 🔸Oauth 2.0 on Commons :
2. > A ✅ Get new creadentials : 1790f6a39f53cadf7ce2ac7d82b961f8
3. > B 🔸T405919 Oauth related url are hardcoded. Please note Pushkar our main dev pointed out some API requests on user data must be done on other sites, so it's why he picked meta as the consumer's target.
4. > A ✅ batches-view-titles: I did one more round of improvement with {n}`
5. ✅ language-proficiency-professional : with guidance from Pushkar, I removed it in both UI and database models.
6. ✅ Keyboard controls 'p' : ok, so i only kept the localized version of it with `case t('shortcuts-p'), see here.

Others:

1. ✅ Keyboard-accessible : I got it with Claude Sonnet, see lingua-libre.toolforge.org.
2. ✅ Remove words already recorded by locutor : done, see MR78 !

See git history.

Hello @Tacsipacsi , I fought well with those later items. Clearly could not have done it this "fast" ( 😆 ) without Claude Sonnet 3.7, who was of a great help.

Also, we needs a dozen of translations reviews and additions before the get into production. We only have one feature to hide or fix left, we can parallelize those two efforts before pushing into production. Could you green-light our project for translatewiki ?

Thanks @Tacsipacsi for your review @Yug, I think we can go ahead and onboard the project, and other improvements can be continued. Few things:

1. Is the license AGPLv3 or GPLv3?
2. Not super happy with the pluralization approach used in locutor-menu-languages. There maybe incorrect translations submitted. Please add additional instructions in the qqq.json file to avoid incorrect translations.
3. Please provide access to https://gitlab.wikimedia.org/l10n-bot to submit translations to the project.

Hello @abi_ ,
I will answer following your numbering scheme.

1. License : AGPL3 license, here
2. locutor-menu-languages : see 93f70950.

diff
- "locutor-menu-languages":"Text appearing after a number of languages in the locutor selector",
+ "locutor-menu-languages":"Text stating the number of language(s) attached to a locutor",

3. L10n-bot : already a member.

Ping to @Tacsipacsi too, see message above. We answer all of your concerns but one, underway.

Also, WMFR's dev will try your docker compose today. 🎉👍🏼

Change #1193112 had a related patch set uploaded (by Wangombe; author: Wangombe):

[translatewiki@master] Lingua Libre Django: Add to translatewiki.net

https://gerrit.wikimedia.org/r/1193112

In T375653#11217673, @Yug wrote:

1. 🔸Oauth 2.0 on Commons :
2. > A ✅ Get new creadentials : 1790f6a39f53cadf7ce2ac7d82b961f8

Thanks! However, as far as I see, it’s not yet used on https://lingua-libre.toolforge.org/. Is it because the below point?

1. > B 🔸T405919 Oauth related url are hardcoded. Please note Pushkar our main dev pointed out some API requests on user data must be done on other sites, so it's why he picked meta as the consumer's target.

Replied over there.

3. > A ✅ batches-view-titles: I did one more round of improvement with {n}`

Thanks! It looks good, except that the 0-case should be plural in English – “I have 0 batches” is correct, “I have 0 batch” isn’t.

7. ✅ language-proficiency-professional : with guidance from Pushkar, I removed it in both UI and database models.
8. ✅ Keyboard controls 'p' : ok, so i only kept the localized version of it with `case t('shortcuts-p'), see here.

Thanks!

Others:

1. ✅ Keyboard-accessible : I got it with Claude Sonnet, see lingua-libre.toolforge.org.

Thanks! There are some code maintainability issues (commented-out code, the definition of .sr-only is redundant – Claude Sonnet probably doesn’t have deep enough knowledge of the project to tell this), but those are not that urgent; from an accessibility perspective, it looks fine.

3. ✅ Remove words already recorded by locutor : done, see MR78 !

Thanks!

In T375653#11224214, @abi_ wrote:

2. Not super happy with the pluralization approach used in locutor-menu-languages. There maybe incorrect translations submitted. Please add additional instructions in the qqq.json file to avoid incorrect translations.

Maybe we could use {{PLURAL}} on translatewiki.net, similarly to how Android translations work (completely different syntax on translatewiki.net and in the XMLs)? Given that Codex is the preferred UI design system of Wikimedia, which is based on Vue, I think Lingua Libre won’t be the only project using vue-i18n, so the development cost will hopefully be worth it. (This is the standard plural syntax of vue-i18n, not something I made up when I suggested its use in T375653#11072390.)

1. > B ✅ Oauth 2.0 on Commons : yes, I first focus on UI/i18n fixes, I will come back to those config.ini edit later this week, but before publishing the app. See T405919 . EDIT: resolved in MR#91!
2. > A ✅ batches-view-titles: implemented, pushing it soon.

Others :

1. ✅ Keyboard-accessible : ok, great. Happy we achieved it ! Code maintainability issue received.
2. 🔶 alert() : received, we will monitor that.

Also, thanks for the overall help this coding cycle. It pushed our project upward, thank you. 🙏🏻🎇

Change #1193112 merged by jenkins-bot:

[translatewiki@master] Lingua Libre Django: Add to translatewiki.net

https://gerrit.wikimedia.org/r/1193112

Change #1194476 had a related patch set uploaded (by Wangombe; author: Wangombe):

[translatewiki@master] Lingua Libre Django: Add to translatewiki.net

https://gerrit.wikimedia.org/r/1194476

Change #1194476 merged by jenkins-bot:

[translatewiki@master] Lingua Libre Django: Add to translatewiki.net

https://gerrit.wikimedia.org/r/1194476

In T375653#11254065, @Wangombe wrote:

• Update Translatewiki.net group description

Thanks for adding the message, but please note that a translation admin will need to mark the page for translation (which pushes both the Lingua Libre message, and the MediaWiki core messages I added a week ago, for translation) before this can be called done. Until that, https://translatewiki.net/wiki/Special:Translate/lingua-libre continues to show nothing.

Hey, as the translatewiki page is online and this task is coming to a close allow me to thank @Tacsipacsi for his in depth user test and all contributors who helped with this ticket. 🙏🏼 Thank a lot !

/home/betawiki/config/bin/clupdate-git-repo 'git@gitlab.wikimedia.org:repos/wikimedia-france/lingua-libre/lingua-libre.git' '/scratch/exports/lingua-libre' 'main' 'c4d2e1e8057497e14880277e2b8a6b896e0dad11' 'none'
Cloning into '/scratch/exports/lingua-libre'...
Updating files:  94% (176/186)↵
Updating files:  95% (177/186)↵
Updating files:  96% (179/186)↵
Updating files:  97% (181/186)↵
Updating files:  98% (183/186)↵
Updating files:  99% (185/186)↵
Updating files: 100% (186/186)↵
Updating files: 100% (186/186), done.

No export yet, it seems.

Hi there. <s>Since the Translating:Lingua_Libre is online, I believe this task can be closed ?</s>

Exports are not happening. @Wangombe please see my comment here: 1194476: Lingua Libre Django: Add to translatewiki.net | https://gerrit.wikimedia.org/r/c/translatewiki/+/1194476

Still not synchronizing.

Change #1197923 had a related patch set uploaded (by Wangombe; author: Wangombe):

[translatewiki@master] Add lingua-libre to group list in repoconfig.yaml

https://gerrit.wikimedia.org/r/1197923

Change #1197923 merged by jenkins-bot:

[translatewiki@master] Add lingua-libre to group list in repoconfig.yaml

https://gerrit.wikimedia.org/r/1197923

Error Output:                                                                                                                                                                                          
================                                                                                                                                                                                       
remote: GitLab: You are not allowed to push code to protected branches on this project.                                                                                                                
To gitlab.wikimedia.org:repos/wikimedia-france/lingua-libre/lingua-libre.git                                                                                                                           
 ! [remote rejected] main -> main (pre-receive hook declined)                                                                                                                                          
error: failed to push some refs to 'gitlab.wikimedia.org:repos/wikimedia-france/lingua-libre/lingua-libre.git'

@Yug, the translatewiki bot might need maintainer access to push code directly to main branch

• ✅ Userright granted to Gitlab L10n-bot. @abi_ thank for that idea. 👀

1. > B ✅ Oauth 2.0 on Commons : @Tacsipacsi, we now connect via Commons alone so all key issues you raised have been resolved. I updated my previous review on the mater

August 10th, Sept 17th, MR#91 on Oct. 20th : It's been quite an adventure ! Thank again, the report you did was something ! 👍🏼

No export today because most of wikimedia-misc-tools failed due to T407479#11303482

@abi_ , @Nikerabbit , @Wangombe thank you ! I will now move to T407063 i18n call for translation on translatewiki.net to translate faster :D
Thank again for your support. 🌻