484838 - global/history/history.properties is unused and should be removed

Status: RESOLVED FIXED

(Toolkit :: Places, defect)

Description

[Alexander L. Slovesnik]

from https://bugzilla.mozilla.org/show_bug.cgi?id=484252#c3:
> FWIW, some of these strings also present in
> http://mxr.mozilla.org/mozilla-central/source/toolkit/locales/en-US/chrome/global/history/history.properties

mxr teels me that file is completely unused, in such a case it should be
removed

Comment 1

[Alexander L. Slovesnik]

Attachment: Patch [Checkin: Comment 2]

Comment 2

[Serge Gautherie (:sgautherie)]

Comment on attachment 368938 [details] [diff] [review]
Patch
[Checkin: Comment 2]


http://hg.mozilla.org/mozilla-central/rev/f3bfeb5de776

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 368938 [details] [diff] [review]
Patch
[Checkin: Comment 2]

Axel can correct me if I'm wrong, but I don't think the reduced-workload benefits of landing this on the branch outweigh the coordination difficulties.

Comment 4

[Serge Gautherie (:sgautherie)]

(I thought Axel was interested in string removals.)

Comment 5

[Marco Bonardo [:mak]]

Axel said me we could probably do this after b4 release, so please ask him directly.

Comment 6

[Axel Hecht [:Pike]]

After B4, it might be a good idea.

Which means that it's probably a bad idea to request approval now. We'll need to revisit this once B4 is out of the door.

Comment 7

[Ria Klaassen (not reading all bugmail)]

Attachment: screenshot history submenus extension

Could this patch have broken the history submenus extension?

Comment 8

[:Gavin Sharp [email: [e-mail]]]

Probably... the extension author will have to work around this in his extension, though. It's not too hard for him to include the strings himself, or change to use chrome://browser/locale/places/places.properties .

Comment 9

[Zibi Braniecki [:zbraniecki][:gandalf]]

Gavin: bug 485685

Comment 10

[Axel Hecht [:Pike]]

So I guess we shouldn't take this fix on 1.9.1, just for extension compat reasons?

Comment 11

[:Gavin Sharp [email: [e-mail]]]

Yeah, seems like we should just leave this in on trunk and forget about it for branch.

Comment 12

[Jason Sonnenschein]

Hi.  I'm the maintainer of history submenus.  I was hoping you could help a bit with generating new code.  I'd rather not just put strings in the extension for English.  Using the strings in firefox lets me internationalize the extension rather easily.

I changed the xul override file to have a different stringbundle as suggested above:

<stringbundle id="daynames" src="chrome://browser/locale/places/places.properties"/>

but that doesn't fix anything (at least not with ffx 3.0.6).

The code that's using these strings is:

var daynames=document.getElementById("daynames");
daystring[0]=daynames.getString("finduri-AgeInDays-is-0");
daystring[1]=daynames.getString("finduri-AgeInDays-is-1");
daystring[i]=daynames.getFormattedString("finduri-AgeInDays-is",[i]);

I unzipped some jar files from Firefox 3.1b2 and found that these strings are only in locale/en-US/places (in the English version of the browser).

Any suggestions as to what I'm doing wrong and how to re-code?

Thanks in advance for any help

Comment 13

[:Gavin Sharp [email: [e-mail]]]

Those strings are also found in chrome://places/locale/places.properties , which hasn't been removed. You always use MXR to find what you need:

http://mxr.mozilla.org/mozilla-central/search?string=finduri-AgeInDays-is-0
to find the bundle, and then:
http://mxr.mozilla.org/mozilla-central/search?string=places.properties
to find its chrome URL.

Comment 14

[Jason Sonnenschein]

Thanks for the help, Gavin