Closed Bug 551156 (en-CA) Opened 14 years ago Closed 6 years ago

[en-CA] New localization: English, Canada

Categories

(Mozilla Localizations :: Registration & Management, defect)

Product:
Mozilla Localizations
Component:
Registration & Management
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1457906

People

(Reporter: kev, Unassigned)

References

Details

(Keywords: productization) 

I'd like to create an en-CA locale for Canada, with Canadian-specific translations (which are a mix of en-US and en-GB) and search/product features. The US and GB builds are ok, but do not address the differences that exist between Canada and those countries, particularly around default services and the spell-checkers.

To that end, I'd like to create an en-CA team for Firefox (and Fennec/Mobile) as well as Thunderbird to start.

Thanks much, and let me know if there's additional info required.

Kev Needham
Summary: Create en-CA locale for English Canada → [en-CA] Create locale for English Canada
I'll resolve this as incomplete for now just to do some new locale registration bug queue management.  Rather than leaving this open, we'll get it off our list and can reopen later when we have resolved the open issues of doing localized variants of languages like English vs. something like a partner build from en-GB (or -US) for Canadian users with customized productization elements.  Lots of other interesting web tech and IT stuff we need to explore, too.  Cool?  (By the way, added Gen for posterity, since he is pushing this idea, too.)
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
Reopening. I see an en-ZA, and see no reason why en-CA can't be accepted as a regionalization at this point. I'd also like to push fr-CA, but need to find some folks who can help.
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
This locale registration bug is being resolved as INCOMPLETE because it has not been updated since before the final Firefox 10esr release on 2013-01-08. It is assumed that there has not been any progress in developing the desired localization since that time.

If you feel this bug has been closed in error, please reopen it and provide a status update for your locale.

In addition, please be sure to follow the guidelines listed on the wiki for creating a new localization:

https://wiki.mozilla.org/L10n:Starting_a_localization

[Mass change filter: l10n-new-incomplete-fx10esr]
Status: REOPENED → RESOLVED
Closed: 14 years ago → 11 years ago
OS: Mac OS X → All
Hardware: x86 → All
Resolution: --- → INCOMPLETE
I felt this bug was closed in error, but I don't think I'm going to take no for an answer this time around. Canada is not England. Canada is not the United States (although we may be its hat).

I am happy to start contributing if I know there is a reasonable chance of acceptance. To date, there has been reluctance to accept an en-CA locale, but there are linguistic and service differences in the country, and it'd be great if we could use it to solicit help for fr-CA as well down the line.

If the effort gets put into completing en-CA, will it be accepted?
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Status: REOPENED → NEW
Summary: [en-CA] Create locale for English Canada → [en-CA] New localization: English (Canada)
Summary: [en-CA] New localization: English (Canada) → [en-CA] New localization: English, Canada
Status: NEW → UNCONFIRMED
Ever confirmed: false
There's interest in an en-CA for Fennec, if there's a community for it, we should start with a focus on that.

See also bug 882315.

I'm hoping for energy from the community in Canada here to do an actual localization, we'll not be able to succeed with a minimal-effort thing. Saying that because there's a few proposals to do that.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I am happy to be community on this. Goodness knows I've moaned about it enough, and I can guilt some of my fellow canucks into lending a hand I am sure.
Looks like it's another year.
Count me in if there're need.
Bug 1160002 has a request to let people from Canada, Australia and New Zealand download the en-GB build. I'm using the en-GB build in Toronto, so I understand what the reporter means.

I know en-GB and en-CA/AU/NZ are slightly different but reusing en-GB might be safe for most strings.

A more important issue is the search engines; people may want to see local sites like Yahoo.ca, Amazon.ca or eBay.ca instead of the en-GB equivalents. How Mozilla l10n is handling search engines and other in-product services?
See Also: → 1160002
For now, search engines are tied to the localization used. But I know that mconnor wants to change that.
I mentioned this in my Tweet today: the current Nightly builds have the new tab page with geo-targeted top sites and Pocket recommendations. Here in Canada, I see Amazon.ca in the top sites list. But we don't have the built-in search provider. For a consistent UX, It would be nice to provide the en-CA locale with relevant search engines. I'm willing to maintain the l10n if no one else does, but the problem is MoCo probably doesn't have search engine contracts in the Canadian market yet. So, maybe the first step is finding an active biz dev person who can handle it?
Keywords: productization
Jeff, do you know the biz dev folks who are handling search stuff?
(In reply to Kohei Yoshino [:kohei] from comment #12)
> Jeff, do you know the biz dev folks who are handling search stuff?

You can start with Mike Kaply. Technically, we have the ability to override search plugins in a region without actually shipping the locale (we're already doing it for Canada), but that's not something built to ship a completely different set of searchplugins.

As a side note: I'd be against enabling a locale just for the search engines and without a community behind.
(In reply to Francesco Lodolo [:flod] from comment #13)
> You can start with Mike Kaply. Technically, we have the ability to override
> search plugins in a region without actually shipping the locale (we're
> already doing it for Canada), but that's not something built to ship a
> completely different set of searchplugins.

Hmm, it this actually happening? When I use the Amazon search provider, it takes me to Amazon.com, not Amazon.ca. Google, Yahoo, Bing, DuckDuckGo are apparently detecting our IP address to serve the best results, so it's not a big deal. Amazon should be fixed at least.

> As a side note: I'd be against enabling a locale just for the search engines
> and without a community behind.

Agree.
We'd probably need a plugin for amazon.ca in browser/locales/searchplugins and add it as experimental-hidden to some locales in browser/locales/search/list.json, but I have no idea how that's actually switched on, and if I've guessed OK.

en-US and fr are popular, en-GB is already single-digit % in CA.
Hi all! First off, I don't think an en-CA localization is a priority right now.  If there was an easy way to do sub-localizations (i.e. some sort of build system that's basically "use the en-GB strings except for those specific changes") maybe it'd be fun.

On partner integrations, better support for CA is on my list.  Now that Yahoo is more geo-aware, it's really just Amazon right now.

There isn't a bug yet, but there's a set of geo-based optimizations for Amazon already on my radar, including for Canada.  I hope to get that into 57.
(In reply to Mike Connor [:mconnor] from comment #16)
> There isn't a bug yet, but there's a set of geo-based optimizations for
> Amazon already on my radar, including for Canada.  I hope to get that into
> 57.

Sounds great. Yes, the l10n itself isn't a priority. Most Canadians probably don't care about the difference between color and colour or whatever. But the Amazon search engine affects their UX as well as Mozilla revenue.
(In reply to Kohei Yoshino [:kohei] from comment #17)
> Most Canadians probably don't care about the difference between color and colour or whatever. 

You have no idea how much we care aboot it...
I know because I live in Toronto (I stick with en-CA when I write site compatibility notes [1] or whatever), but UI-wise, there are only a few differences and those are obscure. So people don't care about it. That's why this bug is open for 8 years (actually 11 years since Bug 345039 is filed), right?

[1] https://www.fxsitecompat.com/
I will help.
Count me in too.
I have no particular interest in string alternatives, but I do care about .ca search choices, domain completion, etc.  I'd like to see us improve that, particularly in Firefox for iOS.
Adding here the information I wrote on Slack.

a) Community
We need someone to take a leadership role. It would be useful to regroup and figure out who's interested in helping, within the Canadian employees, but also in the larger community of Mozillians.

b) How we do this
Firefox is big, and comes with some baggage: Activity Stream, Screenshots, and some less obvious (mozilla.org). I would say about 30k strings. That's a lot of read, copy or correct, submit. 

Should en-CA start from scratch, or from another locale and then correct? If the latter, en-US or en-GB?

(In reply to Nick Alexander :nalexander from comment #22)
> I have no particular interest in string alternatives, but I do care about
> .ca search choices, domain completion, etc.  I'd like to see us improve
> that, particularly in Firefox for iOS.

You can't have that without a full localization. And to have that, someone needs to localize en-CA.
Alias: en-CA
I think we should use en-GB, with Canadian search configurations. There's some complexity in terms of other locales with Canadian search engines, but that's something I'm committed to solving.

I don't know if there's a way to selectively fork, as in use en-GB with a limited subset of overrides.
(In reply to Mike Connor [:mconnor] from comment #24)
> I don't know if there's a way to selectively fork, as in use en-GB with a
> limited subset of overrides.

No. We can bootstrap using en-GB as a start, but then it would be a stand-alone locale, and someone needs to maintain it. Missing strings would fall back to en-US, until we have Fluent and better multilingual support, then we can fall back to something else (e.g. en-GB).

At this point though, I can't help thinking that most people actually want customized settings for Canada (search, domain autocomplete, etc.) more than an actual localization? And that would be a completely different bug.
Personally, I'm more interested in the correct spellings than the search preferences.
Looks like there's already a Canadian English dictionary. (I didn't know that, was using a UK dict) 
https://addons.mozilla.org/firefox/addon/canadian-english-dictionary/
I assume "spelling" refers to how messages are spelled in the UI itself.

Give me a few days to regroup on some technical details, and I'll update the bug (likely early next week).
I've filed bug 1457906 to track adding en-CA to Firefox and mozilla.org. Even if counterintuive, I'll dupe this one to the new tracker.

@chelsea and @catlee
Can you create an account on Pontoon? 
https://pontoon.mozilla.org/

Once we have the hg repository, I'll need to set up searchplugins, and add the locale to builds, so it will take a few more days before we have nightlies. We should be able to ride the trains with 62 to Beta and Release.

Note that we'll use en-GB content to initialize both the hg repo and mozilla.org
Status: NEW → RESOLVED
Closed: 11 years ago → 6 years ago
Resolution: --- → DUPLICATE
(In reply to Francesco Lodolo [:flod] from comment #30)
> I've filed bug 1457906 to track adding en-CA to Firefox and mozilla.org.
> Even if counterintuive, I'll dupe this one to the new tracker.
> 
> @chelsea and @catlee
> Can you create an account on Pontoon? 
> https://pontoon.mozilla.org/
> 
> Once we have the hg repository, I'll need to set up searchplugins, and add
> the locale to builds, so it will take a few more days before we have
> nightlies. We should be able to ride the trains with 62 to Beta and Release.
> 
> Note that we'll use en-GB content to initialize both the hg repo and
> mozilla.org

This is really cool!  I've created a Pontoon account as well.  It's fancy!
You need to log in before you can comment on or make changes to this bug.