Unknown private browsing entities for kk locale, which breaks private browsing mode

RESOLVED FIXED

Status

defect
--
major
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: whimboo, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [4b11][mozmill], URL)

Attachments

(1 attachment)

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b11) Gecko/20100101 Firefox/4.0b11 (kk)

By running our Mozmill BFT tests against all locales for b11 builds we have found problems in the kk locale, which is broken for the private browsing mode.

Results:
http://mozmill-archive.brasstacks.mozilla.com/#/general/report/00edfccff35537bd5dcddb5129741329

Some of the entities cannot be found which causes a YSOD when entering private browsing mode or opening about:privatebrowsing.

It's the first time I have run the BFT tests for all locales, so not sure if this is even an older problem.

As talked with Axel, I file this under release engineering, because it could be a problem with the build process. The DTD files look ok.
Posted image XML parsing error
Attached is a screen shot taken after I tried to switch to private browsing mode.

aboutPrivateBrowsing.xhtml is not a locale specific file, it's common for all locales.
I've tried to "lint" the translation and have the following:

en-US:
<!ENTITY privatebrowsingpage.title                 "Private Browsing">

kk:
<!ENTITY privatebrowsingpage.title                 "Бетбелгілер мен тарих қазір қолжетерсіз, өйткені %S кейбір файлдарды басқа бағдарлама қолданып тұр. Кейбір қауіпсіздік бағдарламалар осындай мәселені тұғызуы мүмкін.">

Note %S in kk. Do you think it's fatal?
I unpacked omni.jar from the en-US and kk b11 builds and compared file existence. After renaming all of the 'kk' dirs to 'en-US', the only difference between the two was that defaults/profile/prefs.js existed in en-US, but not in kk.
Full list of entities with printf type errors for kk:

browser/chrome/browser/aboutPrivateBrowsing.dtd:
privatebrowsingpage.title
privatebrowsingpage.title.normal

browser/chrome/browser/syncQuota.properties:
quota.usagePercentage.label

dom/chrome/appstrings.properties:
confirmRepostPrompt


./toolkit/crashreporter/crashreporter.ini:
CrashID
%S is the culprit, no idea why compare-locales on the dashboard didn't find that, but I'll look.

Rail, what printf type errors do you see in the non-DTD files?
Whiteboard: [4b11][mozmill]
Axel, does it mean this single failure breaks all other entities too? As I have mentioned in comment 0 we also see failures in other entities.
Ignore browser/chrome/browser/syncQuota.properties, false alarm, imo.

dom/chrome/appstrings.properties:
confirmRepostPrompt

"To display this page, the application must send information that will repeat
any action (such as a search or order confirmation) that was performed
earlier."

vs

"%S бетін көрсету үшін жіберілетін ақпарат алдынғысын қайталауы мүмкін
(мысалы, іздеу сілтемесін немесе онлайн сатып алуды)."

./toolkit/crashreporter/crashreporter.ini:
"Crash ID: %s"

vs

"Алдында сәтсіз жіберілген хабарды қайта жіберу…"
AFAICT, this should only break about:privatebrowsing.
Filed bug 631248 on compare-locales not catching the issue at hand.

(In reply to comment #7)
> Ignore browser/chrome/browser/syncQuota.properties, false alarm, imo.
> 
> dom/chrome/appstrings.properties:
> confirmRepostPrompt
> 
> "To display this page, the application must send information that will repeat
> any action (such as a search or order confirmation) that was performed
> earlier."
> 
> vs
> 
> "%S бетін көрсету үшін жіберілетін ақпарат алдынғысын қайталауы мүмкін
> (мысалы, іздеу сілтемесін немесе онлайн сатып алуды)."

This one's border line. It's not really an error, as it's not breaking the build, but it might be OK to issue a warning. Having printf strings show up in localized strings and be right is not really likely, I guess.

> ./toolkit/crashreporter/crashreporter.ini:
> "Crash ID: %s"
> 
> vs
> 
> "Алдында сәтсіз жіберілген хабарды қайта жіберу…"

Hrm. I don't run any checks on ini files at all at this point. That string looks pretty off anyway.

Thanks for the input, this is actually an l10n bug, so moving it over to the Kazakh localization.
Component: Release Engineering → kk / Kazakh
Product: mozilla.org → Mozilla Localizations
QA Contact: release → kazakh.kk
Version: other → unspecified
Here a list of entities we weren't able to resolve in the Mozmill test:

privatebrowsingpage.issueDesc.normal 
privatebrowsingpage.description 
privateBrowsingCmd.commandkey
(In reply to comment #3)
> I unpacked omni.jar from the en-US and kk b11 builds and compared file
> existence. After renaming all of the 'kk' dirs to 'en-US', the only difference
> between the two was that defaults/profile/prefs.js existed in en-US, but not in
> kk.

I filed bug 631271 to check in on that, I assume that's just left overs in en-US.

Tim, just to give you a summary:

Please check the %S in browser/chrome/browser/aboutPrivateBrowsing.dtd, those shouldn't be in there. Also, "Privat Browsing: " becomes that long? (Sadly, I don't know how to actually show that string in action.)

Also, the two strings that Rail saw in comment 7 sound like you should revisit those. "Crash ID" probably isn't a full sentence?

The appstrings.properties is likely a copy from the browser-specific override at browser/chrome/overrides/appstrings.properties, you should review those strings in general, even if they're not used in Firefox itself (that uses the override).
Changeset 5c7ac30c9ae2 of kk repo in central-l10n should close this bug.

Updated

8 years ago
Summary: Unkown private browsing entities for kk locale, which breaks private browsing mode → Unknown private browsing entities for kk locale, which breaks private browsing mode
Let's mark this bug fixed. I'll file a follow up to talk more about appstrings.properties, there are some things that aren't quite right there yet.

Thanks for the quick fix.

FTR, given that we have a fix in hand, I don't think this is blocking exposing kk to the beta audience. We'll fix private browsing with the next update.

Timur, don't forget to sign off on the new revisions? Thanks.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Filed bug 631486, fyi.
You need to log in before you can comment on or make changes to this bug.