1947822 - Summation of model size needs to be checked

Status: RESOLVED WORKSFORME

(GeckoView :: Translations, defect)

Description

[Olivia Hall [:olivia]]

The model size the UI is displaying isn't matching this chart both on the model download size and in the low data popup.

I tend to think this is a regression because I recall auditing and comparing these lists several times during the development process.

Need to check the logic in summation of these files:

• GeckoView:Translations:ModelInformation
• GeckoView:Translations:GetTranslateDownloadSize

Comment 1

[Olivia Hall [:olivia]]

I'm not 100% sure yet if bug 1942349 is the regressor, but it matches the regression range and this seems to have the right value in production.

134.0.2 Release: French download size on an English device - 50.21 MB (This doesn't 100% match the prescribed 26.8 + 25.9 = 52.7 MB, but IIRC, there is some front-end rounding that accounts for it. I suspect if I looked at the raw bytes reported that it would match.)
136.0b4 Beta: French download size on an English device 34.28 MB
137 Development - French download size on an English device 34.28 MB

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1942349

:gregtatum, since you are the author of the regressor, bug 1942349, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 3

[Olivia Hall [:olivia]]

With mozregression using Fenix, I was able to narrow down to:
Newest known good nightly: 2025-01-16
Oldest known bad nightly: 2025-01-17

I might try again with GVE, which might have narrower ranges, or see if I can identify from the push log.

That seems to eliminate bug 1942349, which landed 1-28-25.

Comment 4

[Olivia Hall [:olivia]]

Bug 1940972 or bug 1940756 are the best candidates from looking at the changelog, both landed on 2025-01-16.

Comment 5

[Olivia Hall [:olivia]]

Looks like it is bug 1940972, the patch of "Introduce useLexicalShortlist", found through reverting down the stack.

With this reverted:
French size on downloads screen is reporting: 50.21 MB
French size for on-the-fly translation download is reporting: 25.55 MB (one-way download)
GeckoView reported: French raw bytes are 52649954 b
Summing downloaded files manually from website, I get: 52649954 b

Comment 6

[Olivia Hall [:olivia]]

Hi Erik,

Could you take a look at this bug when you have some time?

Comment 7

[Erik Nordin [:nordzilla]]

Attachment: lexical-shortlist-flip.webm

Hey Olivia!

It's expected that download sizes will be smaller with the lexical shortlist pref set to false, and larger when it is set to true, because it does not need to download/use the lex file for translating.

I've attached a video of the Desktop settings.

Is there a discrepancy on Android from what the video shows on Desktop? 50.21 looks to match what I am seeing.

Comment 8

[Olivia Hall [:olivia]]

Awesome, sounds like this isn't a bug and is working correctly! I had thought from our earlier conversation on Slack that all three artifacts should always be calculated in the download size and didn't know about this preference.

I checked and when browser.translations.useLexicalShortlist = false, French is 34.28 MB and 50.21 MB when true. So, all in alignment! Thanks for taking a look!

Comment 9

[Olivia Hall [:olivia]]

Updating the flags for tracking

Comment 10

[Olivia Hall [:olivia]]

Reopening because there is still something odd here. The translation size displayed during the download of an on-the-fly translation still appears off.

• Fr -> En has the UI reporting 17.14 MB

As identified by :nordzilla:

• With lexical shortlist: 8,818,768 + 17,140,961 + 831,382 = 26.79 MB
• Without lexical shortlist: 17,140,961 + 831,382 = 17.97 MB

Comment 11

[Olivia Hall [:olivia]]

Good news, I added logging to get the actual value, which is 17972343 bytes. The display is using the binary definition of a byte and not the decimal definition.

Without lexical shortlist: 17,140,961 + 831,382 = 17972343 bytes / (1024 * 1024) = 17.1397 MiB

The 17.14 MB (really MiB) reported does look suspiciously just like the decimal definition of a byte model value, but it is just coincidental.