Closed Bug 172444 Opened 22 years ago Closed 19 years ago

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

Categories

(Core :: Internationalization, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: amyy, Assigned: smontagu)

Details

(Keywords: intl, l12y)

Attachments

(3 files)

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.
Attached image screen shot for detail
Ressign to Naoki for now, please reassign if needed.
Assignee: yokoyama → nhotta
Keywords: intl
QA Contact: ruixu → ylong
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...
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).
hi. nhottanscp@yahoo.co.jp

Is attachment 131001 [details] [diff] [review] have any problem?
Why is this patch left here?
This correction is required also of Thunderbird.
nominating for the 1.0 mac release
Flags: blocking-aviary1.0mac?
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.
I'm using English (default) build, and making an empty Japanese.lproj
folder solves this problem.
see also Bug 166685 in Camino.
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.
(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?
> 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.
(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.
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.
Assignee: nhottanscp → bsmedberg
Status: NEW → ASSIGNED
Attachment #162034 - Flags: review?(mmx_bugzilla)
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.
Attachment #162034 - Flags: review?(mmx_bugzilla) → review-
Flags: blocking-aviary1.0mac?
This got fixed a while back.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
harunga, I marked this as fixed because something very much like the attached
patch was checked in.
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
Benjamin, if you talk about only Firefox, it seems to me this bug
should be marked as wontfix.
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
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.
*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.
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?
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...

The checkin is probably the fix for Bug 257463 on Firefox.
So I think this bug in Core product should be marked as wontfix.
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.
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).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee: benjamin → jasonb
Status: REOPENED → NEW
Component: Internationalization → Build Config
Product: Core → Mozilla Application Suite
Summary: [mach-o] Dialogs don't follow the OS locale language UI → [mach-o][seamonkey] Dialogs don't follow the OS locale language UI
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.
Assignee: jasonb → nobody
QA Contact: amyy → build-config
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.)
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.
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?
Product: Mozilla Application Suite → Core
Summary: [mach-o][seamonkey] Dialogs don't follow the OS locale language UI → [mach-o] Dialogs don't follow the OS locale language UI
Assignee: nobody → smontagu
Component: Build Config → Internationalization
QA Contact: build-config → amyy
I'm also leaning toward (1), but it would for sure be confusing to users.. 
Keywords: l12y
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
(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. 
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.
Status: NEW → RESOLVED
Closed: 20 years ago19 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: