Closed Bug 991543 Opened 11 years ago Closed 11 years ago

[tracking] (desktop) Update localized search plugins with resultdomain

Categories

(Firefox :: Search, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 31

People

(Reporter: mak, Assigned: flod)

References

Details

(Whiteboard: p=0 s=it-32c-31a-30b.1 [qa!])

the en-us plugins are already updated, though localized ones are not. resultdomain is the root domain of the search engine, for www.google.com it's google.com, for search.creativecommons.org it's creativecommons.org... It's the domain we will complete in the awesomebar to drive the user to the search engine provider main page.
Can you elaborate a bit on the change – i.e. what happens if we don't update the localized searchplugins, involves only Firefox or also Fennec – and the timeline? Because we're talking about hundreds of searchplugins/file, and it's really painful doing changes there (and it would be the third time in 12 months, with a fourth almost ready for Yahoo…).
Make request explicit with NI
Flags: needinfo?(mak77)
(In reply to Marco Bonardo [:mak] from comment #0) > the en-us plugins are already updated, though localized ones are not. > resultdomain is the root domain of the search engine, for www.google.com > it's google.com, for search.creativecommons.org it's creativecommons.org... > It's the domain we will complete in the awesomebar to drive the user to the > search engine provider main page. we are building a new autocomplete search that will match against those strings, not providing a resultDomain means we will try to use the host, that in some cases will match properly, in other cases it will match wrongly (for example "s" will match "search.creative.commons.org" while it would be expected "c" to match "creativecommons.org"). For the most common cases like google or bing it should work regardless since they don't use "special" search subdomains, so let's say it's not something that will break the world. Regarding a timeframe for the change, I think in v32 we may enable that component in Nightly.
Flags: needinfo?(mak77)
Luckily Google and Bing are not a problem, since locales rely on en-US versions. I'll need to review Yahoo as part of bug 994141, so I'll fix that too. I'm wondering about cases like zh-TW http://transvision.mozfr.org/productization/?locale=zh-TW&product=browser They have a bunch of *.yahoo.com searchplugins, so my guess is that the autocomplete will produce more results.
Assignee: nobody → francesco.lodolo
Depends on: 994248
Last question (I think): is this something that targets only desktop or mobile too? I didn't see landings for the latter so far.
Flags: needinfo?(mak77)
only desktop afaik
Flags: needinfo?(mak77)
(In reply to Francesco Lodolo [:flod] from comment #4) > I'm wondering about cases like zh-TW > http://transvision.mozfr.org/productization/?locale=zh-TW&product=browser > > They have a bunch of *.yahoo.com searchplugins, so my guess is that the > autocomplete will produce more results. interesting question, we may have to tweak matching for those, or just suggest the main search page and then from there users can go anywhere. The idea is to make easier to reach the search engines from the awesomebar, I don't think the design went so deep to allow searching for sub-sections of the engines. the problem here is what users should type to reach these different sub-engines, typing y will clearly match yahoo, the generic search page.
Flags: needinfo?(clarkbw)
Flags: firefox-backlog?
(In reply to Marco Bonardo [:mak] from comment #7) > (In reply to Francesco Lodolo [:flod] from comment #4) > > I'm wondering about cases like zh-TW > > http://transvision.mozfr.org/productization/?locale=zh-TW&product=browser > > > > They have a bunch of *.yahoo.com searchplugins, so my guess is that the > > autocomplete will produce more results. > > interesting question, we may have to tweak matching for those, or just > suggest the main search page and then from there users can go anywhere. The > idea is to make easier to reach the search engines from the awesomebar, I > don't think the design went so deep to allow searching for sub-sections of > the engines. > the problem here is what users should type to reach these different > sub-engines, typing y will clearly match yahoo, the generic search page. Indeed the intention wasn't to have lots of sub domains however I can see how both ways have merit. For simplicity I would think we'd want to just offer the top level and allow people to create history from that point but I'm open to the alternate view here.
Flags: needinfo?(clarkbw)
Flags: firefox-backlog? → firefox-backlog+
Whiteboard: p=0
Summary: Update localized search plugins with resultdomain → (desktop) Update localized search plugins with resultdomain
I'll be using this bug as a tracker for changes, probably good to move the discussion about subdomains into a different one? Flood incoming.
Summary: (desktop) Update localized search plugins with resultdomain → [tracking] (desktop) Update localized search plugins with resultdomain
Double checked l10n-central and mozilla-aurora, this should be done.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 31
Whiteboard: p=0 → p=0 s=IT-32C-31A-30B.1
Marco, do you need QA testing for this as part of the iteration? Is there adequate automated coverage for these changes?
Flags: needinfo?(mak77)
Whiteboard: p=0 s=IT-32C-31A-30B.1 → p=0 s=IT-32C-31A-30B.1 [qa+]
Otilia, can you please assign this to someone for testing, pending Marco's feedback? Thanks.
Flags: needinfo?(otilia.anica)
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #19) > Marco, do you need QA testing for this as part of the iteration? Is there > adequate automated coverage for these changes? Well, I'm not sure how to test these changes, apart going through all of the changes and check they are sane. There's no UI exposed for this yet.
Flags: needinfo?(mak77)
(In reply to Marco Bonardo [:mak] from comment #21) > There's no UI exposed for this yet. Is there any chance these changes could regress existing search functionality in l10n builds?
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #22) > (In reply to Marco Bonardo [:mak] from comment #21) > > There's no UI exposed for this yet. > > Is there any chance these changes could regress existing search > functionality in l10n builds? Yes, if I messed up something. Considering the change was scripted in most of the case (like 99%), it should be decently safe. I have some scripts running that warns me if a .xml is invalid, but that's pretty much all I have. Anyway, I'm going to send an email out to dev-l10n explaining that I completed this fix and to double check that everything works as expected.
Thanks Francesco, we'll do a manual sanity check against a random selection of locales as well.
Whiteboard: p=0 s=IT-32C-31A-30B.1 [qa+] → p=0 s=it-32c-31a-30b.2 [qa+]
Whiteboard: p=0 s=it-32c-31a-30b.2 [qa+] → p=0 s=it-32c-31a-30b.1 [qa+]
Flags: needinfo?(otilia.anica)
QA Contact: bogdan.maris
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #24) > Thanks Francesco, we'll do a manual sanity check against a random selection > of locales as well. We verified that the following locales have the affected search plugins updated with the associated "resultdomain" parameter value and spot-checked search on each of them, using Aurora 31 2014-05-12: fr, es-ES, de, ru, pt-BR, it, th, ja, zh-CN, ko, af, sv-SE, fi, bn-IN, es-MX, ar, he, da, pl, tr, hi-IN, zh-TW, id, kn, fa. We tracked our tests in this etherpad [1] and covered the following platforms: Windows 7 64-bit, Windows 8.1 64-bit, Mac OS X 10.9.2 and Ubuntu 13.04 32bit. Is there anything else we should look at here? [1] https://etherpad.mozilla.org/31-a2-l10s-RD
Status: RESOLVED → VERIFIED
Whiteboard: p=0 s=it-32c-31a-30b.1 [qa+] → p=0 s=it-32c-31a-30b.1 [qa!]
You need to log in before you can comment on or make changes to this bug.