293736 - Firefox l10n build script for MacOSX en-GB tries to move en.lproj to en.lproj and fails

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Mark Tyndall]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.8b) Gecko/20050217
Build Identifier: n/a

See tinderbox url above.

The build script moves/renames the file "en.lproj" to [ab].lproj.
When it tries this on the en-GB build, ab == en and so the script
is trying to rename en.lproj to en.lproj.  (Thanks to MMx for describing this on
#l10n).

Reproducible: Always

Steps to Reproduce:
0. See tinderbox results of automated builds for Mac trunk Fx.

Comment 1

[Martin Creutziger [:MMx]]

The makefile to blame is in /browser/locales, checking if Thunderbird l10n is
affected, too

Comment 2

[Martin Creutziger [:MMx]]

Does Thunderbird l10n also use /browser/locales/Makefile.in?
I can't find an equivalent to
http://lxr.mozilla.org/mozilla/source/browser/locales/Makefile.in#192 in /mail

Furthermore, the renaming scheme is not good. It always renames to ab.lproj,
even for locales that _need_ the region identifier, or did I misunderstand the code?
I would suggest using the code that is used for the app, in ab_CD form. (no
further extensions though, like dialects or things like "ja_JP_mac") Otherwise,
Languages like Chinese will break. 

Comment 3

[Benjamin Smedberg]

The problem with using en_US.lproj / en_GB.lproj is that the mac does not
recognize them and fallback gracefully: "U.S. English" is not in the default
international list for English Mac OS X, while "English" is. I'm certainly
willing to try other naming schemes, but I tend to think that the en-GB build
ought to be using en.lproj, not en_GB.lproj.

Comment 4

[Martin Creutziger [:MMx]]

yes, convinced. I dug a little deeper into the Apple docs and found this:
http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFLocales/Articles/CFLocaleConcepts.html#//apple_ref/doc/uid/20002240-164446-BCIGEEJE

If I understand "locale hirarchies" right, it is save for us to only provide a
two/three letter code for the language ("For language designations, Mac OS X
supports both ISO 639-1 and ISO 639-2 conventions.") and no region at all. Mac
OS X should select the region according to user preferences then.

Comment 5

[Martin Creutziger [:MMx]]

Attachment: proposed patch for /browser/locales/Makefile.in

proposed patch to test whether we have $(AB) == en here - not trying to rename
en.lproj in that case.
I will run a build with that patch later to see if it works as expected.

Comment 6

[Zibi Braniecki [:zbraniecki][:gandalf]]

Comment on attachment 183482 [details] [diff] [review]
proposed patch for /browser/locales/Makefile.in

-ifeq (en,$(AB))
-ifneq (en,$(AB))

Comment 7

[Martin Creutziger [:MMx]]

Attachment: updated patch, this time the right check

sorry, got a little confused there %-(

Comment 8

[Zibi Braniecki [:zbraniecki][:gandalf]]

Comment on attachment 183483 [details] [diff] [review]
updated patch, this time the right check

looks good

Comment 9

[Zibi Braniecki [:zbraniecki][:gandalf]]

Comment on attachment 183483 [details] [diff] [review]
updated patch, this time the right check

umm, sorry for spam

Comment 10

[Martin Creutziger [:MMx]]

Attachment: new patch, fixing bustage

I tested the patch and found out that the "ifneq ... endif" block that I
introduced should not be indented. Fixed that and now it works as expected.

Comment 11

[Martin Creutziger [:MMx]]

Comment on attachment 183533 [details] [diff] [review]
new patch, fixing bustage

a short explanation: 
This patch is needed to turn the en-GB Mac-tinderbox green (or anything but
red) - so it would be great if it could go in soon.

Comment 12

[Mike Shaver (:shaver emeritus)]

Comment on attachment 183533 [details] [diff] [review]
new patch, fixing bustage

a=shaver.

Comment 13

[Benjamin Smedberg]

Checked in on trunk.