If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[yosemite][SeaMonkey] Simplified Chinese shows up in Traditional Chinese mode when saving an image.

RESOLVED FIXED in seamonkey2.40

Status

SeaMonkey
Build Config
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: Philip Chee, Assigned: Thomasy)

Tracking

Trunk
seamonkey2.40
x86
Mac OS X

SeaMonkey Tracking Flags

(seamonkey2.38? affected, seamonkey2.39? affected, seamonkey2.40+ fixed)

Details

(URL)

Attachments

(4 attachments)

(Reporter)

Description

2 years ago
+++ This bug was initially created as a clone of Bug #1089363 +++

(From Bug 1089363 comment #47)
> Created attachment 8548547 [details]
> Thunderbird may be affected by this bug
> 
> I wonder if Thunderbird is affected by this bug?
> The attachment is the menu from Thunderbird. It shows the simplified Chinese.
> If it is affected, we need to open a new one.
https://bug1089363.bugzilla.mozilla.org/attachment.cgi?id=8548547

(From Bug 1089363 comment #0)
> Created attachment 8511644 [details]
> Screenshot https://bug1089363.bugzilla.mozilla.org/attachment.cgi?id=8511644
> 
> The language was in Traditional Chinese, but when the user look at an image,
> right-clicked and chose "Save as", some fields in the dialog were in
> Simplified Chinese.
(Assignee)

Updated

2 years ago
Assignee: installer → nobody
Component: Installer → Build Config
(Assignee)

Comment 1

2 years ago
Created attachment 8645377 [details] [diff] [review]
bug1185270_rev1.patch

Porting the patch according to bug 1089363.
Assignee: nobody → thomas
Attachment #8645377 - Flags: review?(mh+mozilla)
Attachment #8645377 - Flags: review?(Pidgeot18)
(Assignee)

Comment 2

2 years ago
Created attachment 8645378 [details]
The dialog affected by this bug
(Assignee)

Comment 3

2 years ago
Created attachment 8645379 [details]
The dialog after applying the patch
(Assignee)

Comment 4

2 years ago
Created attachment 8645380 [details]
The menu item for the bug testing

Comment 5

2 years ago
Comment on attachment 8645377 [details] [diff] [review]
bug1185270_rev1.patch

Review of attachment 8645377 [details] [diff] [review]:
-----------------------------------------------------------------

I just feel it would be better if we just used the full AB_CD.  That would definitely remove the collisions with using the first word.  (Just my $0.02...)

::: suite/app/Makefile.in
@@ +118,5 @@
> +LPROJ_ROOT := $(subst -,_,$(AB_CD))
> +else
> +LPROJ_ROOT := $(firstword $(subst -, ,$(AB_CD)))
> +endif
> +LPROJ := Contents/Resources/$(LPROJ_ROOT).lproj

With my limited understanding of this,  I'm not exactly sure this might be a good idea; namely because this catches zh-TW vs. zh-CN, but there are a host of other locales that are similar by the first word. i.e es-ES and es-AR.  It could potentially be cumbersome if we need to do a whole series of if thens.

@@ +127,5 @@
>  tools:: $(PROGRAM)
>  	mkdir -p $(DIST)/$(MOZ_MACBUNDLE_NAME)/Contents/MacOS
>  	rsync -a --exclude CVS --exclude "*.in" $(srcdir)/macbuild/Contents $(DIST)/$(MOZ_MACBUNDLE_NAME) --exclude English.lproj
> +	mkdir -p $(DIST)/$(MOZ_MACBUNDLE_NAME)/$(LPROJ)
> +	rsync -a --exclude CVS --exclude "*.in" $(srcdir)/macbuild/Contents/Resources/English.lproj/ $(DIST)/$(MOZ_MACBUNDLE_NAME)/$(LPROJ)

I'm wondering if we should just do the full AB_CD?  Limiting by the first word could be problematic (as we see for this bug).
Comment on attachment 8645377 [details] [diff] [review]
bug1185270_rev1.patch

Review of attachment 8645377 [details] [diff] [review]:
-----------------------------------------------------------------

If you're just transposing the changes from m-c to c-c, you don't need a review from me.
Attachment #8645377 - Flags: review?(mh+mozilla)
(Assignee)

Comment 7

2 years ago
(According to Bug 1089363 comment #55)

> Yes, it may be more correct to use the language_region.lproj naming
> convention for *all* our localizations.  And doing so may fix other
> bugs (including ones that haven't yet been reported).  But, since
> we're dealing with a black box, we don't know what other, possibly
> undesireable behavior changes may happen when we start using the
> language_region.lproj naming convention.

For my limited understanding, this may be a temporal hack for zh-TW.

(In reply to Edmund Wong (:ewong) from comment #5)
> Comment on attachment 8645377 [details] [diff] [review]
> bug1185270_rev1.patch
> 
> Review of attachment 8645377 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> I just feel it would be better if we just used the full AB_CD.  That would
> definitely remove the collisions with using the first word.  (Just my
> $0.02...)
> 
> ::: suite/app/Makefile.in
> @@ +118,5 @@
> > +LPROJ_ROOT := $(subst -,_,$(AB_CD))
> > +else
> > +LPROJ_ROOT := $(firstword $(subst -, ,$(AB_CD)))
> > +endif
> > +LPROJ := Contents/Resources/$(LPROJ_ROOT).lproj
> 
> With my limited understanding of this,  I'm not exactly sure this might be a
> good idea; namely because this catches zh-TW vs. zh-CN, but there are a host
> of other locales that are similar by the first word. i.e es-ES and es-AR. 
> It could potentially be cumbersome if we need to do a whole series of if
> thens.
> 
> @@ +127,5 @@
> >  tools:: $(PROGRAM)
> >  	mkdir -p $(DIST)/$(MOZ_MACBUNDLE_NAME)/Contents/MacOS
> >  	rsync -a --exclude CVS --exclude "*.in" $(srcdir)/macbuild/Contents $(DIST)/$(MOZ_MACBUNDLE_NAME) --exclude English.lproj
> > +	mkdir -p $(DIST)/$(MOZ_MACBUNDLE_NAME)/$(LPROJ)
> > +	rsync -a --exclude CVS --exclude "*.in" $(srcdir)/macbuild/Contents/Resources/English.lproj/ $(DIST)/$(MOZ_MACBUNDLE_NAME)/$(LPROJ)
> 
> I'm wondering if we should just do the full AB_CD?  Limiting by the first
> word could be problematic (as we see for this bug).
(Assignee)

Comment 8

2 years ago
(In reply to Edmund Wong (:ewong) from comment #5)
> Comment on attachment 8645377 [details] [diff] [review]
> bug1185270_rev1.patch
> 
> Review of attachment 8645377 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> I just feel it would be better if we just used the full AB_CD.  That would
> definitely remove the collisions with using the first word.  (Just my
> $0.02...)
> 
> ::: suite/app/Makefile.in
> @@ +118,5 @@
> > +LPROJ_ROOT := $(subst -,_,$(AB_CD))
> > +else
> > +LPROJ_ROOT := $(firstword $(subst -, ,$(AB_CD)))
> > +endif
> > +LPROJ := Contents/Resources/$(LPROJ_ROOT).lproj
> 
> With my limited understanding of this,  I'm not exactly sure this might be a
> good idea; namely because this catches zh-TW vs. zh-CN, but there are a host
> of other locales that are similar by the first word. i.e es-ES and es-AR. 
> It could potentially be cumbersome if we need to do a whole series of if
> thens.

According to the test in Bug 1089363 comment #31 and Bug 1089363 comment #32, we just confine this bug to the zh_TW case.
 
> 
> @@ +127,5 @@
> >  tools:: $(PROGRAM)
> >  	mkdir -p $(DIST)/$(MOZ_MACBUNDLE_NAME)/Contents/MacOS
> >  	rsync -a --exclude CVS --exclude "*.in" $(srcdir)/macbuild/Contents $(DIST)/$(MOZ_MACBUNDLE_NAME) --exclude English.lproj
> > +	mkdir -p $(DIST)/$(MOZ_MACBUNDLE_NAME)/$(LPROJ)
> > +	rsync -a --exclude CVS --exclude "*.in" $(srcdir)/macbuild/Contents/Resources/English.lproj/ $(DIST)/$(MOZ_MACBUNDLE_NAME)/$(LPROJ)
> 
> I'm wondering if we should just do the full AB_CD?  Limiting by the first
> word could be problematic (as we see for this bug).

I didn't go through the entire history of this bug. According to Bug 1089363 comment #55, in brief full AB_CD may be a better solution but we only have a very limited amount of time we can devote to fixing this bug.

Comment 9

2 years ago
Current solution is only for zh_TW.
Should also work for other locales.
But I think the point is try not to affect other languages.
Because we don't have enough resource to verify all other locales.

Most people who use Traditional Chinese feels very uncomfortable when seeing Simplified Chinese.
So there is a huge need to fix this issue at zh_TW locale.
(Reporter)

Comment 10

2 years ago
Comment on attachment 8645377 [details] [diff] [review]
bug1185270_rev1.patch

I'm going to ask Edmund Wong to review this patch since he understands Traditional Chinese
Attachment #8645377 - Flags: review?(Pidgeot18) → review?(ewong)
(In reply to Philip Chee from comment #10)
> Comment on attachment 8645377 [details] [diff] [review]
> bug1185270_rev1.patch
> 
> I'm going to ask Edmund Wong to review this patch since he understands
> Traditional Chinese

I don't have an OSX64 machine to test this patch.  I think the closest would
be stefan; but then again, since this is a build config patch, I'm
more likely to suggest a build config peer...  at the moment, jcranmer's
probably the right person to review it.
Comment on attachment 8645377 [details] [diff] [review]
bug1185270_rev1.patch

Even though I did mention about my concerns, I suppose this patch'll work for zh-TW and zh-CN.
Attachment #8645377 - Flags: review?(ewong) → review+
(Assignee)

Updated

2 years ago
Keywords: checkin-needed
(Reporter)

Comment 13

2 years ago
http://hg.mozilla.org/comm-central/rev/9087de97bc72
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox42: affected → ---
status-seamonkey2.38: --- → affected
status-seamonkey2.39: --- → affected
status-seamonkey2.40: --- → fixed
tracking-seamonkey2.38: --- → ?
tracking-seamonkey2.39: --- → ?
tracking-seamonkey2.40: --- → +
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.40
You need to log in before you can comment on or make changes to this bug.