"Download-Save or Open" Dialog do not show App name with localized name [OS X]

NEW
Unassigned

Status

()

Firefox
File Handling
11 years ago
2 years ago

People

(Reporter: NicolasWeb, Unassigned)

Tracking

unspecified
All
Mac OS X
Points:
---
Bug Flags:
wanted1.9.0.x +

Firefox Tracking Flags

(blocking2.0 -)

Details

Attachments

(2 attachments)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; fr; rv:1.9b2) Gecko/2007121014 Firefox/3.0b2
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; fr; rv:1.9b2) Gecko/2007121014 Firefox/3.0b2

With the first option/radio button "open with" the names showed in the list-control are the english names.

This happens with apple app, should be checked for others

Reproducible: Always

Steps to Reproduce:
1.Try to download a file not natively supported by Fx by clicking on a link
2.
3.
Actual Results:  
English name

Expected Results:  
Official localized names for all app,
 - Apple official localized names (ex: "Preview" should be in FR "Aperçu")
 - other "vendors" official localized names
(Reporter)

Comment 1

11 years ago
Created attachment 295513 [details]
Actual Dialog
(Reporter)

Updated

11 years ago
Version: unspecified → Trunk
Component: Download Manager → File Handling
Product: Firefox → Core
QA Contact: download.manager → file-handling
Created attachment 296627 [details]
Applications prefpane screenshot

This bug is visible in the Applications prefpane too.

The attached screenshot comes from a french nightly on my french macbook.
In the application picker the application name is localized and once you have selected the "Apercu" application, it appears in the Applications prefpane as "Preview".
Nominating for blocking1.9 as this looks really bad.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9?

Comment 4

11 years ago
Is this a regression?
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
(Reporter)

Comment 5

10 years ago
That's a regression from Fx 1 or Fx 1.5 (I remember this has worked)
Flags: tracking1.9+ → blocking1.9+
Is this something we could take in a dot release, right after final?
If this is a priority, I can take a look. In that case, I would like to ask for few hints:
- what piece of code handles the labels (what is suspected)
- how to test this in trunk build where localizations are missing

Comment 8

10 years ago
This is not a regression from Fx 2, I just tried the French version of 2.0.0.12 and the same problem appears there. We collect the name of the app from the OS, presumably we're skipping a step where we go from the internal name to its localized name, using the System Preferences setting. I'm inclined to say dot release, given that it's been this way for awhile. To answer Honza's second question, this should be debuggable in a trunk build, because external app names are not affected by browser localization.
-'ing based on Comment #8.  wanted1.9.0.x+.

Thanks, Stan.
Flags: wanted1.9.0.x+
Flags: blocking1.9-
Flags: blocking1.9+
Priority: P2 → --
(Reporter)

Updated

10 years ago
Flags: wanted1.9.1?
(Reporter)

Comment 10

8 years ago
Maybe should block bug 565517 too
Blocks: 565518
(Reporter)

Comment 11

8 years ago
Can someone confirm this on intel too ?
blocking2.0: --- → ?
Please don't add random issues to the papercut metabugs, that's not why they exist. The paper cut set of bugs is supposed to be a manageable, prioritized list, not a way to get your pet peeve bug fixed.
No longer blocks: 565518
(Reporter)

Comment 13

8 years ago
Sorry Limi, Have I missunderstood paper cut and polish ? :-S
(I'm learning bugzilla and try to help the most I can, but sometimes I make
mistakes... :-S)

For this one, I don't understand why it's not a pepercut one as it is a small thing to fix and really anoying ? Can you teach me, so I won't make the same mistake again please ?

Updated

8 years ago
blocking2.0: ? → -
(Reporter)

Comment 14

3 years ago
This bug still exists with Fx 35 and OSX 10.10.1

is there something to do to help this being fixed ? (ping someone ?)
Hardware: PowerPC → All
André, Steven, who would be the right person to move this forward (possibly someone to volunteer to mentor if this can be marked as a good first bug)?
Flags: needinfo?(smichaud)
Flags: needinfo?(areinald)

Comment 16

3 years ago
If application's plist is set up correctly, this should return the localized Application name as a NSString:

NSString *localizedAppName = [[NSBundle mainBundle] localizedStringForKey:CFBundleDisplayName value:nil table:nil];
if (localizedAppName == nil) {
  localizedAppName = *currentName*;
}

If it returns nil, we can use the currently obtained name. And file a bug to fix the plist.
Flags: needinfo?(areinald)
The dialog where the "wrong" (non-localized) application name appears is a native dialog -- one over which we have no direct control.  So this bug will be difficult to fix, and maybe impossible.  Furthermore, it will probably require somebody who has at least some skills at reverse-engineering the OS.

I'm not going to have time for this anytime soon.  And quite frankly I don't consider this bug particularly urgent -- so it's difficult to suggest other people on which responsibility for this can be foisted :-)

If I were going to work on this (and like I said, I'm almost certainly *not*), I'd start by comparing Firefox's behavior with that of other localized apps.  If even Safari has this behavior, then it's straightforwardly an Apple bug and needs to be reported to them.  If Chrome doesn't have this bug, then someone should look at Chromium code to see how they invoke this native dialog (if they do), and see how we might be able to change own own behavior.

It may turn out that the crucial factor isn't how we invoke the dialog, but something about how our app bundle is set up.  For example bug 1089363 turned up a case where using zh_TW.lproj instead of zh.proj worked around a similar problem on Yosemite.
Flags: needinfo?(smichaud)

Comment 18

3 years ago
After some thought, I realize this is a normal Mac app behavior (display localized app name) that we want, and it's probably taken care of by the OS if the plist is filled correctly, which may not be the case. Not sure but this is a good first check to make.
(In reply to Steven Michaud from comment #17)
> The dialog where the "wrong" (non-localized) application name appears is a
> native dialog

Looks like there was a slight misunderstanding here. The native dialogs are correctly localized. It's the application names displayed inside the Firefox UI that aren't localized.

The front-end code uses nsILocalFileMac.bundleDisplayName to get that name.

This getter is implemented at http://mxr.mozilla.org/mozilla-central/source/xpcom/io/nsLocalFileUnix.cpp#2629 and given what it's doing (string manipulation on the file name), I'm not surprised it's not returning a localized name.

Is there an easy way to adapt the code suggested by André in comment 16 so that it could fit in this method?
Oops, sorry.  Yes I did misunderstand, and the dialog this bug is concerned with is a Firefox dialog (not a native one).  In fact you can display that dialog by clicking on attachment 295513 [details].  Sorry for the confusion :-(

But I'm still horribly busy, and won't have time for this bug anytime soon.  Even just digging in enough to understand what's going wrong will take more time than I currently have.

Remind me again in a couple of weeks.  Things may be better then.
André told me there may be relevant information on this documentation page: https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFBundleRef/index.html

Hopefully this will help if someone wants to start hacking on this :-).

Updated

2 years ago
Component: File Handling → File Handling
Product: Core → Firefox
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.