172444 - [mach-o] Dialogs don't follow the OS locale language UI

Status: RESOLVED WONTFIX

(Core :: Internationalization, defect)

Description

[Yuying Long]

Build: 10-03-07 mach-o build on Mac 10.1.5

When open any dialog that will has the text label following by the OS language
locale UI.  E.g. File | Open, File | Save As, Print ...etc.  You will find all
the texts are displayed as English, I expected it should following the OS locale
language.  A screen shot will be followed to show the problem. 

Note: with mozilla 10-03 trunk or branch build, the labels are in OS locale
language.

Comment 1

[Yuying Long]

Attachment: screen shot for detail

Comment 2

[Yuying Long]

Ressign to Naoki for now, please reassign if needed.

Comment 3

[HARUNAGA Hirotoshi]

If you copy English.lproj to Japanese.lproj in Mozilla.app:Contents:Resources,
the labels will be in Japanese.
2003021103/MacOS 10.2.3-JA.
I don't know this is a right workaound...

Comment 4

[HARUNAGA Hirotoshi]

Attachment: patch for Mozilla-MachO and MF

Please make additional 14 lang *.lproj folders (empty) like as
Mozilla 1.3a Carbon, Safari 1.0 (v.85) and Mac IE 5.2.3.
This change will also fix the problem that Japanese characters are
displayed as square in Java applet (probably Bug 151239).

Comment 5

[Takanori MATSUURA]

hi. [e-mail]

Is attachment 131001 [details] [diff] [review] have any problem?
Why is this patch left here?

Comment 6

[Hiro]

This correction is required also of Thunderbird.

Comment 7

[Scott MacGregor]

nominating for the 1.0 mac release

Comment 8

[Benjamin Smedberg]

Does this occur with an English build or a localized build? I would expect that
in an English Firefox/Thunderbird the dialogs would be in English, and in a
Japanese Firefox they would be in Japanese. See bug 257463

I don't think that attachment 131001 [details] [diff] [review] is correct, because it does not copy the
InfoPlist.strings file.

Comment 9

[HARUNAGA Hirotoshi]

I'm using English (default) build, and making an empty Japanese.lproj
folder solves this problem.

Comment 10

[HARUNAGA Hirotoshi]

see also Bug 166685 in Camino.

Comment 11

[Benjamin Smedberg]

I don't understand why this is a bug. If you are using an English build, you
should expect English mac dialogs. If you are you using a Japanese build and get
English dialogs, *that* is a bug.

Comment 12

[Takanori MATSUURA]

(In reply to comment #8)
> I don't think that attachment 131001 [details] [diff] [review] is correct, because it does not copy the
> InfoPlist.strings file.

Do you think InfoPlist.strings in English.proj have any useful information?
It contains only
   /* Localized versions of Info.plist keys */

  CFBundleName = "Firefox";
  NSHumanReadableCopyright = "Copyright � 1998-2004 Contributors.";

I think these are not to need to be translated.
Are these strings very very useful?
And must these strings be translated?

Comment 13

[Benjamin Smedberg]

> I think these are not to need to be translated.
> Are these strings very very useful?

They do not need to be translated. They are useful/required because they inform
the OS how to display various menus and tooltips. We can just copy that file.

Comment 14

[Hiro]

(In reply to comment #13)
> > I think these are not to need to be translated.
> > Are these strings very very useful?
> 
> They do not need to be translated. They are useful/required because they inform
> the OS how to display various menus and tooltips. We can just copy that file.

No!!
build localized by the option can be made from Firefox / Thunderbird.(bug252941,
etc.)

When creating Localization build, there is the necessity of also fix(ing) this
problem.

Comment 15

[Benjamin Smedberg]

crot0: we *know* the problem; but files only need to be *moved*, they don't need
to be *localized*. So this does not affect the l10n freeze. It will get fixed
for ffox 1.0.

Comment 16

[Benjamin Smedberg]

Attachment: rename English.lproj ab.lproj

Comment 17

[Martin Creutziger [:MMx]]

Comment on attachment 162034 [details] [diff] [review]
rename English.lproj ab.lproj

The patch does not work right. It creates a directory "de.lproj", and copies
"English.lproj" inside of it. Problem is:

line 51 is:
+	rsync -a --exclude CVS
$(topsrcdir)/browser/app/macbuild/Contents/Resources/English.lproj
$(DIST)/$(APP_NAME).app/Contents/Resources/$(AB).lproj

should be:
+	rsync -a --exclude CVS
$(topsrcdir)/browser/app/macbuild/Contents/Resources/English.lproj/
$(DIST)/$(APP_NAME).app/Contents/Resources/$(AB).lproj

same problem in line 82:
+	rsync -a --exclude CVS
$(srcdir)/macbuild/Contents/Resources/English.lproj
$(DIST)/$(APP_NAME).app/Contents/Resources/$(AB).lproj

should be:
+	rsync -a --exclude CVS
$(srcdir)/macbuild/Contents/Resources/English.lproj/
$(DIST)/$(APP_NAME).app/Contents/Resources/$(AB).lproj

(trailing "/") 
After that, is seems to work. Only the target "installers-ab-CD" does not work
as expected yet.

bsmedberg, please attach a new patch.

Comment 18

[Benjamin Smedberg]

This got fixed a while back.

Comment 19

[HARUNAGA Hirotoshi]

Benjamin Smedberg: please teach us why you marked this as fixed.
it seems to me that nothing has been changed on Core product.
reopening for the moment.

Comment 20

[Benjamin Smedberg]

harunga, I marked this as fixed because something very much like the attached
patch was checked in.

Comment 21

[HARUNAGA Hirotoshi]

Benjamin, if you talk about only Firefox, it seems to me this bug
should be marked as wontfix.

Comment 22

[Jason Bassford]

Unless you can specifically identify the bug / patch that fixed this (if this
really was fixed for Core and not just Firefox) then the resolution is still
incorrect.

-> WORKSFORME

Comment 23

[Benjamin Smedberg]

Jason, please do not second-guess my bug resolutions. I already stated the
checkin that fixed this bug, and it is very close the patch attached here. Yes,
the checkin was not made to the "core" code, but that is not important to the
resolution.

Comment 24

[Jason Bassford]

I don't see a comment around the time that you closed this bug indicating what
fixed it.  Only that some bug was checked in that looked "very much like" the
attached patch.  You need to be more specific.  Please supply the bug number
that you're talking about for QA purposes.  Otherwise it IS policy that if you
can't identify something it's WORKSFORME and not FIXED.

Comment 25

[Benjamin Smedberg]

*This* is the bug that was checked in. There is no other bug, and I never said
there was. Stop your pedantic nonsense and move on.

Comment 26

[Jason Bassford]

Benjamin: The only patch attached to this bug that got reviewed got a "-"
meaning that it didn't get approval for checkin.  The rejection happened on
October 14th of last year.

You said "I marked this as fixed because something very much like the attached
patch was checked in."

What was checked in, and where did the approval for that come from?  If it
wasn't checked in as a patch to a different bug, then what are you referring to?

Comment 27

[Jason Bassford]

Benjamin:  At the risk of, in your words, being even more pendentically
nonsensical, if you don't respond to comment 26 I'm going to reopen this bug
again tomorrow.

If it was some code that you checked into this bug the problem, given that there
is no review / approval for it, it could also be that you don't require that?  I
know that's true of some components / component owners...

Comment 28

[HARUNAGA Hirotoshi]

The checkin is probably the fix for Bug 257463 on Firefox.
So I think this bug in Core product should be marked as wontfix.

Comment 29

[Jason Bassford]

Okay, so here's the big question.  Does the bug, as originally reported, still
exist under Seamonkey and MacOS?  If it doesn't, then it's clearly been fixed by
something (it's possible it was bug 257463) - althought that still doesn't clear
up what the actual resolution should be unless we can clearly identify what
fixed it.  If it *does* then this hasn't been fixed at all and definitely does
need to be reopened.

I don't have a Macintosh so I can't test this.

Comment 30

[Jason Bassford]

Okay.  Reopening this bug.

Benjamin: Do not mark this as FIXED again unless -

a) You know that the problem reported in this bug has now been corrected under
Seamonkey (not Firefox) under MacOS X.

b) You can point to a specific bug (or patch from a specific bug) that fixed it.

c) If you did check in some code, you need to explain where your review /
approval for it came from (and if you don't need approval to check anything in
here, then mention that too).

Comment 31

[Jason Bassford]

Benjamin just removed himself from the CC list for this bug. Fair enough.  But
he assigned it to me. <grin> I'm putting this back to the default component owner.

Comment 32

[Jason Bassford]

People - does this bug still exist or not?  Since I don't have a Mac I can't tell.

If nobody replies that, yes, it does still exist in the next 48 hours, I'm going
to resolve this as WORKSFORME.  (Which should have been the original resolution
weeks ago.)

Comment 33

[Benjamin Smedberg]

Jason, if you don't have a mac, you shouldn't have gotten involved with this bug
in the first place, and you definitely shouldn't mark it WORKSFORME.

Comment 34

[cls]

Ok, since neither of you has bothered to test the fix, please keep your hands
off the resolution button, mmm'kay?

I just tested nightly builds for SeaMonkey/latest-trunk, FireFox/latest-trunk &
FireFox/latest-aviary1.0.1.  None of the builds have the fix.  Creating an empty
Spanish.lproj directory (as pointed out in comment #4) fixes the problem.

My limited understanding of the problem is that where we are using system
dialogs (e.g., Open File...) , the user should be able to expect the application
to display the correct OS locale languange.  For the non-native dialogs (e.g
preferences), the user will have to get a localized build.

Our choices seem to be:
1) Do nothing, mark this wontfix and only support localization in special builds
2) Create the empty dirs (per attachment #131001 [details] [diff] [review]) and support localization for
native dialogs by default

I'm leaning towards (1) as it's sets a more consistent l10n story.  How is this
handled on other platforms where native dialogs are used?

Comment 35

[Jungshik Shin]

I'm also leaning toward (1), but it would for sure be confusing to users.. 

Comment 36

[Benjamin Smedberg]

Hold on, is this bug about making the apple menu match the rest of the Firefox
application, or match the operating system native language? The correct behavior
for Firefox is for the apple menu and other OS dialogs to match the localized
version of the Firefox that you have installed. If seamonkey wants to do
something different, that's fine.

> I just tested nightly builds for SeaMonkey/latest-trunk, FireFox/latest-trunk &
> FireFox/latest-aviary1.0.1.  None of the builds have the fix.  Creating an empty
> Spanish.lproj directory (as pointed out in comment #4) fixes the problem.

Chris, this is not true. Firefox ship en.lproj in English builds, and de.lproj
on German builds, etc. See
http://lxr.mozilla.org/mozilla/source/browser/app/Makefile.in#303

Comment 37

[Jungshik Shin]

(In reply to comment #36)
> Hold on, is this bug about making the apple menu match the rest of the Firefox
> application, or match the operating system native language? 

 As reported in comment #0, I guess it's the latter.

> The correct behavior
> for Firefox is for the apple menu and other OS dialogs to match the localized
> version of the Firefox that you have installed.

  That's what Chris' #1 option is as I understand it. So, this should be
resolved as 'wontfix'. (btw, ignore my comment ('... be confusing'))
 
> > I just tested nightly builds for SeaMonkey/latest-trunk, FireFox/latest-trunk &
> > FireFox/latest-aviary1.0.1.  None of the builds have the fix.  Creating an empty
> > Spanish.lproj directory (as pointed out in comment #4) fixes the problem.
> 
> Chris, this is not true. Firefox ship en.lproj in English builds, and de.lproj
> on German builds, etc. See
> http://lxr.mozilla.org/mozilla/source/browser/app/Makefile.in#303

 I think what he meant is that with English version installed, the OS-level
language setting (in his test case, Spanish) doesn't affect the native menu. 

Comment 38

[cls]

It sounds like there were 2 distinct problems:
1) Native dialogs in the builds do not follow the OS native language
2) Firefox localized builds were still using English for native dialogs

It sounds like the second problem was fixed by the mystery checkin but the first
problem, which is what I tested, still remains.

It isn't clear from the original bug report which problem was originally being
reported (though the summary leans towards the first problem) and attachment
#131001 [details] [diff] [review] would have fixed both problems.  But I think we have a minor consensus
that mixing locales isn't what we want to do so I'm marking this wontfix.