1343890 - Firefox 52.0 en-GB localization 'XML Parsing Error' on 'urlbar.extension.label'

Status: RESOLVED WORKSFORME

(Localization Infrastructure and Tools :: General, defect)

Description

[RayV]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170127092954

Steps to reproduce:

Firefox 52.0 with en-GB localization builds but fails to start


Actual results:

XML Parsing Error: undefined entity
Location: chrome://browser/content/browser.xul
Line Number 2547, Column 17:

                <label id="extension" class="urlbar-display urlbar-display-extension" value="&urlbar.extension.label;"/>
----------------^


Expected results:

the entity definition in the .dtd file is missing:

--- en-GB/browser/chrome/browser/browser.dtd
+++ en-GB/browser/chrome/browser/browser.dtd
@@ -394,0 +395,2 @@
+<!-- LOCALIZATION NOTE (urlbar.extension.label): Used to indicate that a selected autocomplete entry is provided by an extension. -->
+<!ENTITY urlbar.extension.label       "Extension:">

Comment 1

[Mark Tyndall]

I can't reproduce this (tested on 64-bit Linux, downloaded from https://www.mozilla.org/en-GB/firefox/channel/desktop/ - the actual link used is https://download.mozilla.org/?product=firefox-52.0b9-SSL&os=linux64&lang=en-GB ).

RayV, can you try starting in safe mode (run

firefox -safe-mode

from a terminal) and see if it still fails.

I've set this to block bug 1343053 (Ian, please remove if that's not the case).

Comment 2

[RayV]

Sorry, I should have made it clear I'm building from the mozilla-release repo - I posted this with bug 1343887.

The build from the link you provided does run OK, because its chrome/en-GB/locale/browser/browser.dtd does have those two entries at lines:

884 <!-- LOCALIZATION NOTE (urlbar.extension.label): Used to indicate that a selected autocomplete entry is provided by an extension. -->
885 <!ENTITY urlbar.extension.label       "Extension:">

whereas the browser.dtd file I'm using in my build comes via a pull/update on the previously cloned repo at
https://hg.mozilla.org/releases/l10n/mozilla-release/en-GB/

where the .dtd file actually available at
https://hg.mozilla.org/releases/l10n/mozilla-release/en-GB/raw-file/tip/browser/chrome/browser/browser.dtd

doesn't have those two lines either at lines 395/6 or 884/5.


The reason I patched them at lines 395/6 was because the diff between
https://hg.mozilla.org/releases/l10n/mozilla-release/en-GB/raw-file/tip/browser/chrome/browser/browser.dtd
and
https://hg.mozilla.org/releases/mozilla-release/raw-file/tip/browser/locales/en-US/chrome/browser/browser.dtd

puts them there.

Comment 3

[Mark Tyndall]

I'm afraid I can't help you - there's some build magic which occurs and pulls in appropriate missing strings, but I don't know where it lives or how it works.

https://l10n.mozilla.org/shipping/dashboard?locale=en-GB shows the dashboard we use; you can see there's 0 errors and 0 warnings for fx (Firefox)

I'm moving this back to the untriaged component, since I don't know where it does live.

Comment 4

[YF (Yang)]

https://hg.mozilla.org/releases/l10n/mozilla-release/en-GB/file/tip/browser/chrome/browser/browser.dtd are branch	THUNDERBIRD4580_2017030515_RELBRANCH.

https://hg.mozilla.org/releases/l10n/mozilla-release/en-GB/file/default/browser/chrome/browser/browser.dtd are "Ian Neal - Bug 1324885 - Update en-GB for Gecko 51".

Comment 5

[Francesco Lodolo [:flod]]

This is not a bug in Localization Infrastructure and Tools, I would suggest to identify the issue instead of moving this bug around some more times. Let's also mark bug 1337550 as a dupe of this one, since the cause is likely the same.

You don't explain how you build Firefox, but something is wrong in your setup. When a localization is missing string, or contains errors, strings are added automatically from en-US at build time. This is clearly not happening for you.

Our documentation is far from good when it comes to building localized builds, you can start from here though
https://developer.mozilla.org/en-US/docs/Mozilla/Creating_a_language_pack

As it stands, this likely a WORKSFORME.

Comment 9

[Francesco Lodolo [:flod]]

Sorry for the noise but I'm trying to make sense of these reports. 

You have a problem setting up the build system on your machine to use en-GB localization, that's not a bug in the en-GB localization itself. 

I hope the instructions above help you figuring out how to setup your system, and that would help with comm-central (I wouldn't be so sure about chatzilla…).

Comment 10

[RayV]

(In reply to Francesco Lodolo [:flod] from comment #5)
> This is not a bug in Localization Infrastructure and Tools, I would suggest
> to identify the issue instead of moving this bug around some more times.
> Let's also mark bug 1337550 as a dupe of this one, since the cause is likely
> the same.
> 
> You don't explain how you build Firefox, but something is wrong in your
> setup. When a localization is missing string, or contains errors, strings
> are added automatically from en-US at build time. This is clearly not
> happening for you.
> 
> Our documentation is far from good when it comes to building localized
> builds, you can start from here though
> https://developer.mozilla.org/en-US/docs/Mozilla/Creating_a_language_pack
> 
> As it stands, this likely a WORKSFORME.

Thank you, this is the response I needed.

"When a localization is missing string, or contains errors, strings are added automatically from en-US at build time."
explains, for example:

[1] why the containers.* files had been used in their en-US versions in the en-GB localization [Color: hadn't been replaced with Colour:],

[2] why <!ENTITY urlbar.extension.label       "Extension:">
    and <!ENTITY simplifyPage.accesskey "i">
    had been added to the end of the file, and not placed at the corresponding lines from the en-US file,

[3] why bug 1343053 had been marked as "No longer depends on: 1343890" - because there is no localization required on that string,

and makes my comment 3 to Bug 1343053 irrelevant - although not entirely pointless as I suspect it did bring you into the fray with this response judging by the timing of your posts.

"You don't explain how you build Firefox, but something is wrong in your setup."

My build method is detailed at http://ray-v.tk/building-firefox-seamonkey-thunderbird-releases-using-mercurial-sources.html and if you have the time and inclination, I'd welcome any comments. I update it for each release, so there are a lot of comments on localization for this release which hopefully I'll now be able to eventually remove.

I've had a look at 'Creating_a_language_pack', and think the key to my issue, as you've mentioned, is:
"If you now preview the contents of the mergdir, you'll see that it contains the files which in your localization were missing some entities. All other files will be taken from en-US directly."

This will fill in the missing strings, but not localized - sort of half way there. I get the impression I'll be able to build a localization directory that I'll be able to slot into my build method, but I'll have to work on that.

I guess the reason I've not had these issues before is that the en-GB localization for a specific release has been updated and ready to use on release date, whereas for 52.0, it's pending.

Comment 11

[Francesco Lodolo [:flod]]

(In reply to RayV from comment #10)
> and makes my comment 3 to Bug 1343053 irrelevant - although not entirely
> pointless as I suspect it did bring you into the fray with this response
> judging by the timing of your posts.

Indeed. I'm responsible for coordinating Firefox localization, so I monitor bugs in the Mozilla Localizations component.

> My build method is detailed at
> http://ray-v.tk/building-firefox-seamonkey-thunderbird-releases-using-
> mercurial-sources.html and if you have the time and inclination, I'd welcome
> any comments. I update it for each release, so there are a lot of comments
> on localization for this release which hopefully I'll now be able to
> eventually remove.

Sadly that would require a better understanding of the build system on my side, and I'm clearly lacking there.

> I guess the reason I've not had these issues before is that the en-GB
> localization for a specific release has been updated and ready to use on
> release date, whereas for 52.0, it's pending.

Yes, normally Ian manages to keep up with the trains, unfortunately he didn't for this cycle.

Given the last comments, I'm going to close this bug as WORKSFORME. And, again, sorry for the poor documentation (and tools…) regarding building localized versions of our products.