Closed Bug 459889 Opened 14 years ago Closed 14 years ago
[lv] Firefox 3 protocol handler setup for Latvian
Protocol handlers are a new feature in Firefox 3 that allows links like mailto:email@example.com to be handled by a webmail application. In order to do that, the site needs to support a special API described on http://developer.mozilla.org/en/docs/Web-based_protocol_handlers. For en-US, we're currently shipping with GMail and Yahoo! Mail for mailto: and 30boxes for webcal: urls, and we're on a ongoing evangelism effort to add more. ms live mail are coming up shortly. For Latvian, we'd like to do that, too. First, the localization team and Stas (Stas Malolepszy) will look at the market for the language and come up with a good candidates. Raivis, we'll need your input on this, the guidelines for making recommendations are on http://wiki.mozilla.org/Firefox_web_services_guidelines. Following that is a reach out by the evangelism team to try to get the vendor to support protocol handlers. Once that happens, Axel will take over in reviewing the actual implementation, which will need to change the gecko.handlerService.* entries in lv/browser/chrome/browser-region/region.properties. Please don't make changes to that file without getting a positive review by Axel or somebody else appointed by Stas/Sethb on a patch for that change upfront.
mailto: handler for inbox.lv mail system would be useful for Latvians as it is very popular email service in Latvia. Everybode else uses Gmail, Yahoo or Russian mail.ru As for the calendar handler I do not know any popular Latvian calendar service. We use Google or some other global service.
I'll send an email to inbox.lv to ask if they support the mailto URLs (I found this email address support%inbox.lv here http://help.inbox.lv/index.php?keyword=contacts). As for mail.ru: we can add it as well, if you think that's a good idea. They're already in the Russian builds <http://mxr.mozilla.org/l10n-central/source/ru/browser/chrome/browser-region/region.properties#20> so there shouldn't be any technical problems. So for mailto the list would be (please correct the ordering if you wish): * inbox.lv * mail.ru * yahoo * gmail Regarding webcal: I don't think Google Calendar currently supports webcal urls (Pike, can you correct me please if I'm wrong?). We can go with the en-US defaults: 30boxes.
Yeah, google calendar isn't supporting protocol handlers yet.
yes I think we can add mail.ru as an option. and en-US default seems ok for calendar Is there anything I can / have to do now? If so let me know.
I'll first contact inbox.lv and then we'll work together on the patch :) Thanks for asking.
I got a reply from inbox.lv on Nov 19. Jevgenijs Kuznecovs wrote that inbox.lv would make changes required to implement the feature and that they would e-mail us in a week or two, once they're done. Thanks, Raivis, for reaching out to them.
Since inbox.lv will be ready in a week or two, we should include mail.ru for 3.0.5 now. The freeze is happening this Friday, Nov 28. Raivis, would you mind preparing a patch adding mail.ru?
I have added mail.ru as a protocol handler. I left google mail and yahoo mail as they are. When inbox.lv will be compliant to the necessery specifications we could replace yahoo mail with inbox.lv as I don't think that yahoo mail is that popular in Latvia and 3 options is enaugh or the more the best? what is policy on this?
Comment on attachment 350118 [details] [diff] [review] Including mail.ru as a mailto: protocol handler Thanks for the patch. Sadly, protocol handlers are a bit trickier, you still need to increase the value of gecko.handlerService.defaultHandlersVersion. Create a new patch for that, please? As for replacing yahoo with inbox.lv later, yeah, that should be possible.
Attachment #350118 - Flags: review-
Regarding the patch - what Axel said. Regarding your question: I would suggest keeping Yahoo. Alexa lists it as 10th most popular site in Latvia, so chances are this handler is useful to some users. In any case, we should make the call now, when lv is still in beta: AFAIK, it's not possible to remove a handler from an already created profile, so if we de-beta with Yahoo in, and then decide to remove it, some users will still have it, and others -- not. Axel, can you confirm this? To sum up: adding inbox.lv is easy, replacing yahoo with it -- might be hard. >diff -r 0379ee3b0b8a browser/chrome/browser-region/region.properties > gecko.handlerService.schemes.mailto.1.name=Googlemail I noticed that you used "Googlemail" here. AFAICT, this name only applies to UK and DE. Is there a reason for using it for Latvia? If not, can you please change it to "Gmail"? A new patch would be nice :) Thanks!
I think that removing should work fine, that's only a problem for search engines. But that's merely the technical argument.
PS: Later would likely not be later in the 3.0.x cycle, but we'd make that change for 3.1. IMHO
Submitting new fixed version of the patch I think that we can leave yadoo as a forth mail handler then.
Comment on attachment 350152 [details] [diff] [review] Updated version of the patch r/a=me. Please land this on both hg and cvs with a check-in comment referencing this bug and my approval/review. Something like "bug 459889, adding mail.ru to protocol handlers, naming gmail gmail, r,firstname.lastname@example.org" would be good. Please add the fixed220.127.116.11 keyword to the bug when landing in cvs, and change that to the verified18.104.22.168 keyword when the fix is verified on a 3.0.5pre build from ftp. Thanks.
I saw this landing on hg, marking FIXED. Technical nit, it's a good idea to land things that should have a real check-in comment separately from other changes, in your hg landing, you had about:rights and region.properties in one chunk. When someone looks at the history of about:rights, that'd be confusing. Nothing bad or to undo, but just to make that note. You can specify directories and files to check-in when doing hg ci, so working around that isn't a real problem. There's no need to actually push them separately, too. Just ci the one file, ci the other, each with a comment that's telling others what happened, and then do a single push.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.