Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deactivate fx/new/desktop with <80% translations #11

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

janbrasna
Copy link

Will fall back to fx/new/basic that still meets the activation threshold.

See mozilla/bedrock#16010

@pascalchevrel
Copy link

Thanks @janbrasna, could you update the patch to also remove Urdu (ur) please?

@janbrasna
Copy link
Author

@pascalchevrel I'll look into it deeper, but my guess is that Urdu https://www.mozilla.org/ur/firefox/new/ cuts the mustard for threshold percentage, there are even less complete pages as Berber https://www.mozilla.org/kab/firefox/new/ that get enabled — these would most likely get activated in the next sync again anyways. So if there are locales+pages that should be kept disabled no matter what syncs, they'd need to be moved to the explicitly inactive_locales, that the metadata allows — but that would be first, it's not currently used anywhere, so l10ns should probably make such call(?) — as that setting ignores the translation percentage going forward, and keeps the fluent file inactive "forever", until manually changed, i.e. no amount of consumed pontoon changes would trigger enabling that page again.

Another option could be for a key page like this one, that also have a legacy experience/fallback, set a different %% threshold, say 90–95% — that would only activate locales that are translated almost perfectly (but, given there are no automated deactivations, would probably need disabling all first, and get the ftl management publish a fresh list with the new metadata inputs then…)

EDIT: Yup, did check, and both ur and kab got activated shortly after the page went live by passing the 80% activation threshold, and no content got removed since (only a little bit of en added over the years), so it's still around the 80% completion to this day. That's a different case than the original ro issue linked as that had content removed falling below the threshold to ca. 20-25%, only failing to be withdrawn from the list of active locales afterwards.

EDIT2: Ok now I see Urdu is 75% on Pontoon so it can be removed and won't activate again until more translations are added to reach 80%… however, the content is not "that bad", as most of the key content and CTAs, incl. the features list etc. are all translated, it's mostly the content below fold that falls back to English. Is it worth disabling?

@pascalchevrel
Copy link

I had this discussion with the l10n team earlier today and generally speaking I like what you propose, especially the higher threshold for key pages.

The Urdu l10n team is not very active on mozilla.org (15 strings last quarter), so that will only get worse over time as strings gets updates and they are unlikely to get back above 80% soon. Also, it is an RTL language with a Persian script, so the English content looks more out of place than it would be in a latin-script page, that's why I think it's safer to disable it for now.

@janbrasna janbrasna changed the title Deactivate fx/new/desktop for Romanian Deactivate fx/new/desktop with <80% translations Feb 19, 2025
@janbrasna
Copy link
Author

(Done.)

OK, I quickly checked a handful of "slower" locales and didn't find anything else currently below 80%, so these two should do for now.

I did check the math used for activation, and it counts the number of strings, not taking their length into consideration, so there are cases above 80% that look somewhat untranslated, but it's only due to the amount of short strings being translated (CTAs, labels, headings), with longer bodies of text missing, thus falling back to English for any longer paragraph. That seems to match how Pontoon does the math though, so the %% shown on resource pages match the data used for activation math.

There were some case of percent_required being used in the past, so that should be viable to add if necessary; however this particular page seems to be at around 100% in cases it ever went over 80% at some point for given locales, so I'm not adding any new threshold for now, but it's definitely an option in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants