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

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Philip Chee]

+++ 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.

Comment 1

[Thomasy]

Attachment: bug1185270_rev1.patch

Porting the patch according to bug 1089363.

Comment 2

[Thomasy]

Attachment: The dialog affected by this bug

Comment 3

[Thomasy]

Attachment: The dialog after applying the patch

Comment 4

[Thomasy]

Attachment: The menu item for the bug testing

Comment 5

[Edmund Wong (:ewong)]

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 6

[Mike Hommey [:glandium]]

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.

Comment 7

[Thomasy]

(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).

Comment 8

[Thomasy]

(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

[othree (MozTW)]

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.

Comment 10

[Philip Chee]

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

Comment 11

[Edmund Wong (: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 12

[Edmund Wong (:ewong)]

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.

Comment 13

[Philip Chee]

http://hg.mozilla.org/comm-central/rev/9087de97bc72