Closed Bug 380287 Opened 17 years ago Closed 6 years ago

Change Locale name from 'pa-IN' to pa

Categories

(Mozilla Localizations :: pa-IN / Punjabi, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: amanpreet.alam, Assigned: amanpreet.alam)

References

Details

want to update Mozilla team about Unicode's bug, which
mention that Punjabi with 'Gurmukhi' Script is Default locale
and it can use 
'pa'
instead of pa-IN .

Ref:
http://www.unicode.org/cldr/bugs/locale-bugs?findid=1300

"1. pa (containing data appropriate for pa-Guru-IN)"

So, I request to update locale 'pa' from 'pa-IN'


it is more logically
Following is structure for selection of language (please update if anything wrong)

-----------------------
                    pa                                  (Stage 1) //Punjabi = pa-IN (default)(unicode bug _above)
                  /    \
               /          \
        pa-arb     pa-gur                 (Stage 2) //2 different Script (Shahmukhi/Gurmukhi)
            |                 |
        pa-PK       pa-IN                    (Stage 3)     //Region  based, India/Pakistan 
-----------------------

for user end, if default Environment  is 'pa' (like user from UK/US 
would not like to use India as default Region),
so, Mozilla applications should have selection with those instead
of use of pa_IN forcefully.

2) All major OpenSource Software use Punjabi as 'pa'
Gnome:http://l10n.gnome.org/languages/pa/gnome-2-20
KDE:http://i18n.kde.org/team-infos.php?teamcode=pa

and linux system itself use only following PATH for Punjabi locale:
------
[aalam@alamPunjabi ~]$ cat /usr/share/locale/pa
pa/  paa/ pag/ pal/ pam/ pap/ pau
------
only "pa", no pa_IN or pa_PK

any one have any update?
can we do this sometime?
To list the dependencies we have in the eco-system:

Extensions

For extension l10n, does this change have any impact on extension compatibility. I think that the locale comparison code should cover this fine, but it might be worth doing a test drive. Is there an extension that's localized in Punjabi that we could use to test?

Websites

We have "pa-IN" in profile data like bookmarks, so for at least some part of our websites, we need to figure out a way to have the two locale codes running in parallel. That probably affects mozilla.com, fxfeeds.mozilla.com, support.mozilla.org. Others?

Firefox product

In particular software update. Major update should then port pa-IN users over to pa. Not sure what we should test, and what we can test.
Now that Pike has the dependencies are lined up, I will be discussing with Mozilla build/release about how to change to pa from pa-IN and will report back soon. (copying joduinn)

-sethb
urgh... Our automation is based on the assumption that the hg repo name is same ast the locale name. The entire hg repo is called "pa-IN", to match the locale name and I've no idea how easy/hard that is to rename the hg repo to match "pa". 

If this change is *needed*, I guess we can investigate renaming the repo or deleting/recreating the pa-IN repo.
(In reply to comment #6)
> urgh... Our automation is based on the assumption that the hg repo name is same
> ast the locale name. The entire hg repo is called "pa-IN", to match the locale
> name and I've no idea how easy/hard that is to rename the hg repo to match
> "pa". 
> 
> If this change is *needed*, I guess we can investigate renaming the repo or
> deleting/recreating the pa-IN repo.

It's very easy to rename an Hg repo. Just file a bug with IT, and it can be done.
(In reply to comment #7)
> It's very easy to rename an Hg repo. Just file a bug with IT, and it can be
> done.

Who files this bug?  I'll file it unless there is some other issue not discussed.
The repo rename is the smallest thing here.

John, we need to get major updates from pa-IN to pa, is that possible? What does it take to fix that, test that, etc?
If we decide to do this, the following steps will need to happen:

1) rename the l10n "pa-IN" mercurial repo to "pa"

2) change the shipped-locales and l10n-changesets to include the newly renamed
locale "pa"; to be done as part of l10n handoff for FF3.1beta2.

3) RelEng would *not* be able to provide updates from FF3.next "pa-IN" installs
to FF3.next "pa". Note that we *do* ship "pa-IN" in FF3.1beta1, so this would
not get updated to FF3.1beta2 or later.

4) RelEng would have to special-case handle doing major update from FF3.0
"pa-IN" to FF3.1 "pa". QA would have to special-case testing of this.


Mechanically, this is the scope of the ToDo items we can think of. Given the
other things on our plate, I ask again is this change truly *needed*?
(In reply to comment #10)
> If we decide to do this, the following steps will need to happen:
> 
> 1) rename the l10n "pa-IN" mercurial repo to "pa"
> 
> 2) change the shipped-locales and l10n-changesets to include the newly renamed
> locale "pa"; to be done as part of l10n handoff for FF3.1beta2.
> 
> 3) RelEng would *not* be able to provide updates from FF3.next "pa-IN" installs
> to FF3.next "pa". Note that we *do* ship "pa-IN" in FF3.1beta1, so this would
> not get updated to FF3.1beta2 or later.
> 
> 4) RelEng would have to special-case handle doing major update from FF3.0
> "pa-IN" to FF3.1 "pa". QA would have to special-case testing of this.

5) Also, http://www.mozilla.com/en-US/firefox/all.html will need to be updated to handle both "pa" for FF3.1 *and* "pa-IN" for previous supported releases.
 


> Mechanically, this is the scope of the ToDo items we can think of. Given the
> other things on our plate, I ask again is this change truly *needed*?
(In reply to comment #10)
> 3) RelEng would *not* be able to provide updates from FF3.next "pa-IN" installs
> to FF3.next "pa". Note that we *do* ship "pa-IN" in FF3.1beta1, so this would
> not get updated to FF3.1beta2 or later.
 
> 4) RelEng would have to special-case handle doing major update from FF3.0
> "pa-IN" to FF3.1 "pa". QA would have to special-case testing of this.

Pardon the confusion, isn't this a possible fix for the problem in point 3?  In point 3, you mention that FF3.1beta1 would not get updated to FF3.1beta2 "or later".  But here, you mention that RelEng could "special-case handle" the major update.  Sounds pretty ugly to do that, but doesn't it update people to the new "pa" locale code?
Seth, the issue is that our update tools don't have any concept of mapping changes in locale names, so we have to reach in and make manual changes. We're OK to do that for a relatively small number of major updates, but it's not viable to do it for every 3.1 release that follows b1. What we didn't realize earlier, is that we could do the manual changes for 3.1b1 pa-IN -> 3.1b2 pa too. Anyone who doesn't use b1 for a while would go 3.1b1 pa-IN -> 3.1b2 pa -> 3.1<latest> pa.
Thanks, Nick.  That's helpful.  We should probably avoid the less viable solution and go with what seems like a winner for the pa community and for RelEng.

The user base for Punjabi is relatively small when compared to other localizations of Firefox.  I wonder if we were to do this change, combined with some evangelism by our localizer (Amanpreet, who filed the bug) and the Punjabi Open Source Team (http://www.satluj.org/), we could make this change and get our users to either manually update to 3.1<latest> pa or do the "special-case" update where users don't use b1 for a while and then go 3.1b1 pa-IN -> 3.1b2 pa -> 3.1<latest> pa. Perhaps outreach and evangelism is the best way to promote this change.  Does that seem reasonable? 

Amanpreet, do you have any thoughts about doing outreach or Nick's idea above?
Seth, 
Manual Update is not bad idea if we have users who download and use FF directly from mozilla site, but worry about various linux distributions, how does those update for 3.1b2 pa? (may it is not our problem, but if you have some words to say, that would be helpful)

Surely Punjabi users would be happy with change and have no problem to manual update one time
Linux distributions generally provide updates through their own channels - dunno how they would handle a locale name change. You'd have to ask the maintainers of their Firefox packages.

If the number of 3.1b1 pa-IN users is small, and PR would reach them, then it's probably OK to not provide an update thru the app. We can do the manual hackery if you want though.
Chofmann, can you provide any numbers for users of pa-IN FF 3.1 b1?  My guess is that the users community size is quite small.  Let's wait to see what data we can find and then make a recommendation.

Amanpreet, do you have a sense of the size of your Punjabi user community?  We will see what we can find out on our side.
For the most part it looks like we have about 100 Active Daily users for pa-IN.  There is a strange couple of days just recently where we had a huge spike.   aug 21,22...   Can anyone think of what might have caused this?  Holiday or any other event?  I could have just been an error in our reporting system...

Here is the data for those two days and the last 15.

2008-08-21	7,004
2008-08-22	533
...
2008-10-01	110
2008-10-02	94
2008-10-03	115
2008-10-04	99
2008-10-05	93
2008-10-06	107
2008-10-07	106
2008-10-08	114
2008-10-09	96
2008-10-10	119
2008-10-11	99
2008-10-12	102
2008-10-13	117
2008-10-14	113
2008-10-15	119

I'd suggest that if we are going to do anything we just flip all the pa-IN naming changes to pa and do only one or none major update migrations, then just try to reach the small set of users with some messaging around download and install the new pa localization...   That sounds like the plan that involves just one time efforts, and eliminates anything that would be continuing work.
Chofmann:

Just to confirm, you suggest we change and do evangelism.  Amanpreet, what do you think of this strategy?
 
Also, regarding the Linux distributions, Amanapreet, can you follow Nick's recommendation and ask the maintainers of the Firefox packages?

Asking users to do a manual update one time doesn't seem too bad.  Do we know how attentive they are to news/blogs/outreach.  Does it seem like we will be able to get to them?
Seth,
I also hope to finish in single action. 
I am able to following Linux Distribution (major one) through respective bugzilla if we
changed and need to track those.

Most of time, for Punjabi community, we share mailing list and provide
all update (Major/minor) for Firefox to that list. Hope that it is not bad 
way to send message to Punjabi people about firefox.
Thank you Amanpreet.  Then, I suggest we make the change to "pa" from "pa-IN" and Amanpreet can work on communicating to his constituency that the users need to do a manual update once the change has been made.  I will also use my blog to announce the change and will ask our Indic localizers who write blogs to make the announcement.
The FF3.1beta2 code freeze is only a couple of weeks away. 

If this is something you want to do this before FF3.1beta2, we should nominate  this bug for beta blocker status, and quickly file dependent bugs for each of the steps listed in comment#11.
anybody has update regarding this pls?
Amanpreet:
It's getting late in the development cycle for Firefox 3.1.  We missed the chance to make this change for FF 3.1 beta 2.  Sincere apologies for that.

Can we make this change after we release Firefox 3.1?  We can start Firefox 3.2 with an new pa repository at that point and begin the communication for the entire release cycle.  Let me know if this sounds good to you.
ok, it will be good to work on it entire cycle. it will helpful for minimize bug count.
Thanks
Note to self (not to forget): if we change the locale name, we will have to create a new redirect under http://fxfeeds.mozilla.com/pa/firefox/headlines.xml (and keep the old one at http://fxfeeds.mozilla.com/pa-IN/firefox/headlines.xml for older profiles).
Just reminder Team,
Firefox 3.5 is almost out. Can we start work for this bug soon.
Thanks
joduinn and nthomas:  can we work on renaming the pa-IN repo to pa?  Now seems to be as good as time as any, since Amanapreet will have a full cycle to get his users to manually update to "Firefox.next".

There are lots of good suggestions in this bug thread.  Comment #10 seems to be a plan that was suggested.
Can't think of any reason to not go ahead with renaming
  http://hg.mozilla.org/l10n-central/pa-IN/
now. Please ask Axel to land the matching change to
  http://hg.mozilla.org/mozilla-central/file/tip/browser/locales/all-locales
so that nightlies still happen. shipped-locales and l10n-changesets will take care of themselves when we get to a release, and major updates we can handle when we get there. 

Don't forget comment #26. What about mozilla.com and other web properties ?
Aman, according to wikipedia there are various Punjabi dialects and it seems to be a majoritary language in Pakistan. Does removing the -IN part would not cause confusion for them in case we have a Punjabi-Pakistan version in the future?

http://en.wikipedia.org/wiki/Punjabi_language#Dialects:_linguistic_classification
Pascal, Those Dialects has no difference to written form (except Pakistani Punjabi). 'pa' is not making confusion because it (pa) is Only for pa-IN,

in future, for Punjabi-Pakistani, we have to use 'pa-PK', 'pa@arb' only 
as suggested by Unicode, we can't use 'pa' anyway and need to follow other
systems.

if you check reference below wiki pages, not a single page written in 
Pakistani Punjabi.

No reason to put region, while more (Punjabi Computer) users (presently) are outside India region (Canada, Australia, UK).
(In reply to comment #31)
> in future, for Punjabi-Pakistani, we have to use 'pa-PK', 'pa@arb' only 
> as suggested by Unicode, we can't use 'pa' anyway and need to follow other
> systems.

So, just to clarify, if a Punjabi-Pakistani translation team ever appeared and requested an official localization, we would have to list it as pa-PK.  You're suggesting that *every* other user of a Punjabi version would use your "pa" version?  Thanks for answering.  We wouldn't want to make any significant infrastructure changes if we someday had to change it back to pa-IN.  Thanks for the ongoing help.
Technically, I read this as if we're actually moving towards specifying the script either way. That'd be pa-Guru for Gurmukhi script here, AFAICT. For a potential Pakistani side, it'd probably be pa-Arab, as there don't seem to be any ISO_15924 codes for variants of Arabic script.
(In reply to comment #32)
> (In reply to comment #31)
> > in future, for Punjabi-Pakistani, we have to use 'pa-PK', 'pa@arb' only 
> > as suggested by Unicode, we can't use 'pa' anyway and need to follow other
> > systems.
> 
> So, just to clarify, if a Punjabi-Pakistani translation team ever appeared and
> requested an official localization, we would have to list it as pa-PK.  You're
> suggesting that *every* other user of a Punjabi version would use your "pa"
> 
yes 'pa' is default other than 'pa-pk'
can we proceed further?
hope plan is not dropped...
it is making problem on linux with *-IN, where used as *_IN (not directly related). all locales having *-IN has No localization from last 2 Months

Bug: https://bugzilla.redhat.com/show_bug.cgi?id=559960
The redhat bug is a problem that's based in a customization of Firefox in their distribution. That's really not something we need to work around.

I'd like to make this one depend on bug 525494, where we intend to add additional flexibility and power to our locale code handling, and will likely do a flock of changes to better reflect reality in our locale codes.
Depends on: 525494
See Also: → 1026307
I'm going to close this bug, given how much time has passed.

Changing an existing locale code in our system is challenging to say the least. This year we're going to invest resources in improving the whole multilingual experience on Firefox, hopefully at that point bugs like this one will become easier to fix.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INCOMPLETE
See Also: → 1872962
See Also: 1872962
You need to log in before you can comment on or make changes to this bug.