1. Install a l10n build here - ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central-l10n/ for a particular locale (I tested AF and JA)
2. Launch the build
3. Install a web app from apps.mozillalabs.coma/appdir
4. Launch the web app
The app should launch - menus should be localized.
The app fails to launch with a XUL error. So far seen on AF and JA locales.
Example error in Japanese:
XML パースエラー: 定義されていない実体が使用されています。
行番号: 32, 列番号: 3: <key id="key_undo"
Regression testing has shown so far:
- 7/17/2012 l10n build: Busted
- 7/14/2012 l10n build: Busted
- 7/11/2012 l10n build: Working
The error translates to (courtesy of Google translate):
XML parse error: entity not defined has been used.
line number 32, column number 3: <key id = "key_undo"
Okay, I was able to reproduce this on a en-GB build. Definitely a l10n issue.
An app fails to launch with any localized version. Likely an issue with the DTD include in webapp.xul.
Unpacking omni.ja from these builds show no webapprt directory:
chrome/en-GB/locale/webapprt doesn't exist
Only these directories exist at chrome/en-GB/locale:
branding browser browser-region en-GB feedback pdfviewer
Regression is from bug 762864.
I do see the expected locale files here,
Perhaps this isn't the right way to reference that file:
contents of webapprt/chrome/en-GB.manifest:
locale webapprt en-GB en-GB/locale/webapprt/
with this directory structure for chrome:
The problem is that webapprt/omni.ja!/chrome.manifest contains manifest chrome/en-US.manifest instead of manifest chrome/$(AB_CD).manifest.
Created attachment 643262 [details] [diff] [review]
Fix webapprt l10n after bug 762864
Jason, it'd be great if you could verify this, AFAICT, we should get aurora approval on this.
This is not in a nightly yet. I was waiting for a nightly to come up to double check and request an aurora approval.
7/19 nightlies are up and the l10n packages look good. Jason, please confirm that they work properly. Thanks.
Verified on the 7/19 l10n build on Windows 7 by installing and launching 4 distinct apps. Note although launching is fixed, there's still problems in the menu and notification localization (i.e. it isn't being localized), but I'll file separate bugs for that. That shouldn't block an uplift though.
Please nominate for aurora uplift when you get the chance.
I should clarify - When I say it isn't being localized, I mean not everything is localized. The words "File," "Quit," "Edit", and everything in the application installed notification isn't localized. The menu under the edit menu is localized.
(In reply to Jason Smith [:jsmith] from comment #18)
> I should clarify - When I say it isn't being localized, I mean not
> everything is localized. The words "File," "Quit," "Edit", and everything in
> the application installed notification isn't localized. The menu under the
> edit menu is localized.
How was it before bug 762864 landed?
(In reply to Mike Hommey [:glandium] from comment #19)
> (In reply to Jason Smith [:jsmith] from comment #18)
> > I should clarify - When I say it isn't being localized, I mean not
> > everything is localized. The words "File," "Quit," "Edit", and everything in
> > the application installed notification isn't localized. The menu under the
> > edit menu is localized.
> How was it before bug 762864 landed?
I re-tested this actually on the most recent nightly again. This looks okay now. I cc-ed you on two l10n bugs though that I did recently pick up from testing this. See bug 776362 and bug 776365.
Comment on attachment 643262 [details] [diff] [review]
Fix webapprt l10n after bug 762864
[Approval Request Comment]
Regression caused by bug 762864
User impact if declined: Launching web apps doesn't work on non en-US builds
Testing completed (on m-c, etc.): see comments 17, 18 and 20
Risk to taking this patch (and alternatives if risky): Low risk
String or UUID changes made by this patch: None