Closed Bug 1466107 Opened 7 years ago Closed 6 years ago

Commit Access (Level 1 l10n) for Reşat SABIQ

Categories

(mozilla.org :: Repository Account Requests, task)

task
Not set
normal

Tracking

(Not tracked)

VERIFIED WONTFIX

People

(Reporter: haqer, Assigned: marcia)

Details

Attachments

(3 files)

Attached file id_rsa_moz.pub
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 Build ID: 20180516032328 Steps to reproduce: I've followed hg-related steps on: https://developer.mozilla.org/fr/docs/Localisation_avec_Mercurial https://developer.mozilla.org/en-US/docs/Mercurial/Using_Mercurial Actual results: My impressions are: a. Firefox account credentials don't work for it. b. It requires public key upload (via https://login.mozilla.com/). And credentials for my Firefox account which i use for pontoon are not accepted on https://login.mozilla.com/ Expected results: So following instructions on https://developer.mozilla.org/en-US/docs/Mozilla/Localization/Localizing_with_Mercurial#Mercurial_account_priviledges I'm filing this request. The email address of my bugzilla account could be used for this.
Adding Axel and Jeff since they are the named vouchers. Reshat: You will also need to agree to the Commit access agreement posted here: https://www.mozilla.org/en-US/about/governance/policies/commit/requirements/. Please post your acceptance in the bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(l10n)
Flags: needinfo?(jbeatty)
I have read, and agree to abide by, the Commit Access Requirements: https://www.mozilla.org/en-US/about/governance/policies/commit/requirements/
Flags: needinfo?(jbeatty)
Talked to flod, and we think think this bug is WONTFIX. We're working on pontoon for crh, so no requirement for an vcs account.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(l10n)
Resolution: --- → WONTFIX
Pontoon is not a holy application, & there are use-cases for which VCS would be easier & faster to use (conversely, for which pontoon wastes time & energy). E.g., anything where files need post-processing (e.g., from one variant to another), or cases in which there is meta-data existing only outside of Pontoon, etc. What this decision translates to is: "For all as long as you Reşat contribute to Mozilla l10n, you will need to continue wasting your time on things like uploading each and every of hundreds of files (dozens of which are changed in every single release) individually, having previously checked hg history anyway to make sure there are no other changes that need to be accounted for." For what it's worth, in light of the feedback above (in addition to prior ones), i kindly request you guys to reconsider, & let me know if you'd be kind enough to allow me to spend less time on unnecessary complications (via VCS access that is)...
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Sorry but that's not what we agreed upon when we enabled crh in Nightly, after months of discussion. We agreed to: 1) Work on localizing Nightly, and keep up the localization for a few cycles. That hasn't happened yet https://bugzilla.mozilla.org/show_bug.cgi?id=1360048#c8 2) Once that's done, we can talk about enabling hg access. And that will still require a few rounds of patch reviews https://bugzilla.mozilla.org/show_bug.cgi?id=1446888#c6 This doesn't mean that you will never get hg access, quite the contrary. It means that we need to work together on 1) and 2) before that happens (and keep a constructive attitude in the process).
(In reply to Francesco Lodolo [:flod] from comment #5) > 1) Work on localizing Nightly, and keep up the localization for a few > cycles. That hasn't happened yet Why would you say "That hasn't happened yet" given that regular localization updates have been made for well over 10 years and 4 months (!), including since crh locale has been added to Pontoon this year. I'm being put in a position of spending time to prove the obvious, instead of doing something useful (and this is discouraging & counter-productive). E.g., A. Highlights from Pontoon stats that i've kept since April (i.e., 7th cycle coming on December 11th) (more detailed files with this data to be attached below): 64.0/65.0a1 (20181126): 89% Deadline Nov 27, 2018 63/64.0a1 (20181125): 83% Deadline Nov 27, 2018 60/62.0a1: 87% Deadline Jun 12, 2018 59: 84% Deadline Apr 25, 2018 58: 81% Deadline Apr 25, 2018 B. Highlights from hg log: changeset: 126:72ca9d68a0f4 user: Reşat SABIQ <haqer@gmx.fr> date: Mon Nov 26 15:14:10 2018 +0000 summary: Pontoon: Update Crimean Tatar (crh) localization of Firefox ... changeset: 96:5749fc476ae6 user: Reşat SABIQ <haqer@g.f> date: Fri Aug 31 11:52:56 2018 +0000 summary: Pontoon: Update Crimean Tatar (crh) localization of Firefox ... changeset: 94:f6d06b047f81 user: Reşat SABIQ <haqer@g.f> date: Mon Jun 25 11:12:29 2018 +0000 summary: Pontoon: Update Crimean Tatar (crh) localization of Firefox ... changeset: 62:98e8df42d939 user: Reşat SABIQ <haqer@gmx.fr> date: Tue May 22 07:52:37 2018 +0000 summary: Pontoon: Update Crimean Tatar (crh) localization of Firefox ... changeset: 16:0d6b4b34397a user: Reşat SABIQ <haqer@g.f> date: Tue Mar 13 13:32:31 2018 +0000 summary: Pontoon: Update Crimean Tatar (crh) localization of Firefox ... And in light of this, i'd like to mention some locales in which Firefox is currently released as fully supported by Mozilla (with 4 out 5 examples (found in a few minutes) having numbers (well) lower than for crh locale, which has been at or above 80% since 24.05.2015 (for over 3.5 years!)): Afrikaans 56% localized Macedonian 53% localized Uzbek 76% localized Vietnamese 81% localized Xhosa 71% localized And for this sprint, i resolved 1 error and a few warnings (like single plural form (in most cases no effect in Turkic languages)) that Pontoon was listing. IMHO, enough said.
Attached file hg.crh.log
Just for the record, more of the relevant details from hg log on updates made.
Attached file pontoon.txt
Just for the record, Pontoon stats on localization updates made (April-November 2018).
We all agreed on keeping a constructive attitude when we added crh to builds, please let's keep this in mind. No value in adding attachments like these: there's a public log in hg showing your activity, and Pontoon stats are public. https://hg.mozilla.org/l10n-central/crh I'd also suggest to stop looking at other locales to make a case: they're falling behind because, in most cases, there's not a team to translate anymore, and it's really hard to drop a locale from release (but it will happen eventually). That's exactly why: a) We're making it much harder to get into release, and require a new locale to keep up for at least a couple of cycles in Pontoon. b) We encourage to have more than one person in the team (but we can make exceptions as needed). We can't afford to leave users stranded on older insecure versions, which means these users are receiving builds with more English than their native language, and that's not an experience we want associated to Firefox. > (In reply to Francesco Lodolo [:flod] from comment #5) > > 1) Work on localizing Nightly, and keep up the localization for a few > > cycles. That hasn't happened yet > Why would you say "That hasn't happened yet" given that regular localization > updates have been made for well over 10 years and 4 months (!), including > since crh locale has been added to Pontoon this year. I'm being put in a > position of spending time to prove the obvious, instead of doing something > useful (and this is discouraging & counter-productive). Did I ever say you're not localizing? "work on localizing Nightly" means exactly that: I don't believe you're focusing on the Nightly version when translating new strings, and we need that fully localized for a couple of cycles before moving forward. Am I wrong? The last group of changes landed from Pontoon on: - Nov 26-28 - Aug 31 - Jun 23-25 They're 2/3 months apart. In order to ship crh in release we need Nightly localized through the entire cycle (translating new strings once a week would be enough), and finally tested for issues on our side. Path forward: if you can localize Nightly through the next two cycles in Pontoon, clearing at least the files with higher priority (TAGS panel, 4/5 stars), I won't have a problem in moving crh to Beta and Release with Firefox 67. https://pontoon.mozilla.org/crh/firefox/tags/ As for getting Mercurial access, we can do that right after, but we'll still need to go through patch approvals before giving you access, to make sure that we all agree on what constitutes a good patch, and what tools are needed to check for that. I'm going to mark this as WONTFIX again, hoping that the path forward is clear once and for all (it doesn't mean you won't get access, it means it won't happen now). Please do not reopen the bug once again, at that point I would consider this a failed attempt. I've told you before: there's no "right" for a language to be included in Firefox. We'd be very happy to have crh in Firefox, but there are requirements that need to be met, and you need to respect them (and the persons who try to enforce them). There's nothing personal against you or the language you're working on, but we need to work on this together, and that requires being cooperative.
Status: REOPENED → RESOLVED
Closed: 7 years ago6 years ago
Resolution: --- → WONTFIX

(In reply to Francesco Lodolo [:flod] from comment #9)

Did I ever say you're not localizing?

I'd appeciate less equivocating, & more less putting down, & more appreciation for well over 10.5 years of work.

Path forward: if you can localize Nightly through the next two cycles in Pontoon, clearing at least the files with higher priority (TAGS panel, 4/5 stars), I won't have a problem in moving crh to Beta and Release with Firefox 67.

I try. I usually prefer doing stuff after a freeze. I don't have time to re-work things that (can) change on a daily basis.

I'm going to mark this as WONTFIX again, hoping that the path forward is clear once and for all (it doesn't mean you won't get access, it means it won't happen now).

Again, this is equivocating & extremely confusing. WONTFIX & "you will get access after crh locale gets into Beta & Release channels" are contradicting each other. The former excludes the latter, & vice-versa (something is wrong with this logic, or psychology...).

On the factual side, Pontoon as of today shows the following stats for
crh for Firefox:
94% localized.
Including:
Browser 93%
DOM Accessibility 100%
Shared 94%

I'd also appreciate less artificial barriers, & attention instead to some useful aspects. E.g., bug 1523590 (that i just logged).

P.S. I still think that given that locales like Afrikaans, Macedonian, Uzbek, Vietnamese, Xhosa with lower localization percentages are in Release channel, crh which is now at about 94% should be moving forward after about a year in Nightly. To me this situation, & all the rationalizing of it, is discouraging & of course unnatural. As i've mentioned, at Gnome, the threshold for officially supported status last i checked was 80% (& crh locale there, like many others, is released even at 22% (the release i'm using is at below 40%)).

Status: RESOLVED → VERIFIED

Just to be clear: I didn't mean to mark this as resolved. I refreshed the page to leave the status as is, but despite the UI having been reset, the status change from a prior tentative button click persisted on the form behind the scene. Let me know whether i should log another bug, etc.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: