Remove Sinhala (si) and Persian (fa) from Thunderbird builds

We recently reached out to locale managers on Pontoon to clean up their projects. A couple of locales asked to remove Thunderbird and related projects from Pontoon:

• Persian (fa)
• Sinhala (si)

Both seem to be in the builds, so they should be removed. Existing users should be redirected to a different locale, depending on the number of users.

We Transfer Add-ons

Several locales requested to remove this project. I've checked, and seen no activity for it, so I disabled it completely.
https://github.com/thundernest/wetransfer-extension

L10N Point of contact

Currently, Philipp Kewisch is indicated as point of contact for Thunderbird projects in Pontoon. Is that still accurate? If not, there should be someone else there.
https://pontoon.mozilla.org/projects/thunderbird/

Note that is not possible to request a new locale for Thunderbird in Pontoon, since our team doesn't manage it, and the point of contact is the only way to make it happen. If you prefer, I could create a link to a bug template to request new locale for Thunderbird.

Locales

Strictly related to the previous point. I've taken a quick look, and the situation requires some attention. This is the script I used: https://gist.github.com/flodolo/d43f5a319e1209e649cb6dca49e85407

At least two Nighly locales seem to be done but are not in release, and 5 locales don't have Nightly builds. Someone should own this, to avoid wasting community resources.

Locales missing from Nightly builds
es-MX: 91.24%
bs: 89.82%
km: 82.19%
ia: 80.68%
eo: 77.77%
hye: 1.86%
xcl: 0.0%

Nightly locales missing from release builds
en-CA: 100.0%
th: 97.74%
pa-IN: 75.94%
af: 62.15%

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

Remove Sinhala (si) and Persian (fa) from Thunderbird builds

I can do a patch for this.

Both seem to be in the builds, so they should be removed. Existing users should be redirected to a different locale, depending on the number of users.

Not sure where that's done. In balrog perhaps? Rob?

Several locales requested to remove this project. I've checked, and seen no activity for it, so I disabled it completely.
https://github.com/thundernest/wetransfer-extension

No further action needed I suppose?

L10N Point of contact

Currently, Philipp Kewisch is indicated as point of contact for Thunderbird projects in Pontoon. Is that still accurate? If not, there should be someone else there.
https://pontoon.mozilla.org/projects/thunderbird/

Philipp is still correct though he's indicated he'd like to transfer that responsibility to someone else. After a transition period I think Lasana Murray who recently joined the Thunderbird team could take on this task.

Note that is not possible to request a new locale for Thunderbird in Pontoon, since our team doesn't manage it, and the point of contact is the only way to make it happen. If you prefer, I could create a link to a bug template to request new locale for Thunderbird.

Sounds good to me!

Strictly related to the previous point. I've taken a quick look, and the situation requires some attention. This is the script I used: https://gist.github.com/flodolo/d43f5a319e1209e649cb6dca49e85407

At least two Nightly locales seem to be done but are not in release, and 5 locales don't have Nightly builds. Someone should own this, to avoid wasting community resources.

Locales missing from Nightly builds
es-MX: 91.24%
bs: 89.82%
km: 82.19%
ia: 80.68%
eo: 77.77%
hye: 1.86%
xcl: 0.0%

What level is usually deemed necessary to enable for nightly/release? Seems we could want to enable the ones that are 77 and up.

Nightly locales missing from release builds
en-CA: 100.0%

Bug 1642477 is on beta (only), and Thai as well.
I think https://hg.mozilla.org/releases/comm-release/ is not something used by Thunderbird (I think Seamonkey used it). We use the https://hg.mozilla.org/releases/comm-esr68/, soon https://hg.mozilla.org/releases/comm-esr78/ for the non-beta releases. I don't see the mentioned locales there though so indeed missing for some reason.

(In reply to Magnus Melin [:mkmelin] from comment #1)

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

Both seem to be in the builds, so they should be removed. Existing users should be redirected to a different locale, depending on the number of users.

Not sure where that's done. In balrog perhaps? Rob?

For Firefox I would look at telemetry to check how many users there are, then decide what to do. Bug 1544725 is a recent example, if it helps.

Several locales requested to remove this project. I've checked, and seen no activity for it, so I disabled it completely.
https://github.com/thundernest/wetransfer-extension

No further action needed I suppose?

Correct, mostly an FYI, unless you're planning to make further changes to that add-on.

Note that is not possible to request a new locale for Thunderbird in Pontoon, since our team doesn't manage it, and the point of contact is the only way to make it happen. If you prefer, I could create a link to a bug template to request new locale for Thunderbird.

Sounds good to me!

What's the best component, and who should be CCed to that bug?

What level is usually deemed necessary to enable for nightly/release? Seems we could want to enable the ones that are 77 and up.

That's up to the Thunderbird team to decide. For Firefox:

• A locale is normally added to Nightly above 30%, as long as there's an active team working on it.
• For release, I would test the build to see how much it's untranslated, and how much high-priority content is missing.

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

What's the best component, and who should be CCed to that bug?

I guess Thunderbird General is ok. Cc me, Philipp, Lasana, and rjl

OK, I'm going to create a template and link it in the header as a resource for both Thunderbird and Lightning. To actually add the project, you'll still need to ping someone with admin access to Pontoon.

For reference:

• We try to steer folks away from products as large as Firefox or Thunderbird, unless there's already a proven group of folks translating.
• Existing locale managers should be OK with adding the project.

But that's something that can be discussed with Philipp/Lasana.

(In reply to Magnus Melin [:mkmelin] from comment #1)

Both seem to be in the builds, so they should be removed. Existing users should be redirected to a different locale, depending on the number of users.

Not sure where that's done. In balrog perhaps? Rob?

Yeah there's some fancy Balrog rules that can be done.

The intent was to ship en-CA, pa-IN, and th with 78. I think I might have missed a step somewhere though because the beta builds are not generating them.

First part. Remove "fa" and "si". Sync the mail and calendar all-locales files - could fix the en-CA missing perhaps?