Metro firefox requires updated search provider tiles for non-US providers

RESOLVED INCOMPLETE

Status

defect
RESOLVED INCOMPLETE
6 years ago
2 years ago

People

(Reporter: manuela.muntean, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [defect] p=0)

Attachments

(1 attachment)

- on Win 8 64-bit, with the latest Italian Nightly build (build ID: 20131212030202) installed from ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/12/2013-12-12-03-02-02-mozilla-central-l10n/

1. Launch Metro mode
2. Perform a search in the URL bar

ER: the icons for Amazon and Yahoo search providers should look like the ones from this .zip file: https://bugzilla.mozilla.org/attachment.cgi?id=788411 
AR: the icons for Amazon and Yahoo search providers look like this: https://bugzilla.mozilla.org/attachment.cgi?id=8345269
Whiteboard: [triage]
The search icons need to be localized. See bug 895520
(In reply to Rodrigo Silveira [:rsilveira] from comment #1)
> The search icons need to be localized. See bug 895520

By comparison, what I'm seeing in this bug, which is https://bug903284.bugzilla.mozilla.org/attachment.cgi?id=8345269 has same icons for Google, Wikipedia and Bing, as shown in bug 895520, here: https://bugzilla.mozilla.org/attachment.cgi?id=8341062. So, only the icon for Yahoo! is different. (if we take into consideration only these 4 search providers)
That's the new Yahoo icon as per bug 936198.
Whiteboard: [triage] → [beta28]
I guess we need to localize some xml to get this working right? Rodrigo, can you detail which files and maybe flod can help us get this set up right for localizers?
All locales use the same .xml file from en-US for Google and Bing (locale redirection is server side). Bug 939834 took care of using googlemetrofx.xml and bingmetrofx.xml in metrolist.txt whenever a specific locale was using Google or Bing on desktop.

Yahoo, Wikipedia and all other searchplugins are locale specific. Since the searchplugin icon is not "broken" on Metro, I honestly don't expect all locales to create "metrofx" versions of their searchplugins, because it would be quite a bloodbath. These changes are part of productization and subject to specific approval.

This obviously unless there's a specific request from some partners widely used (e.g. Yahoo or Wikipedia) to have different tracking parameters. In this case the sooner I know the better, since I already need to fix Yahoo's hi-dpi icon in this cycle.
Posted image smallicons.png
Is there something we need to do to get these icons displaying right in localized builds, or is this something localizers need to address?
I don't have an answer honestly. Who's going to create all 74x74px versions of the images? I definitely can't, and I raised the problem in bug 895520.

Just to have a glimpse at the complexity 
http://l10n.mozilla-community.org/~flod/p12n/images/?channel=trunk#metro

To make things worse, desktop uses 16px icons, not 32px like mobile.

We can decide to fix Wikipedia and Yahoo (they're used in en-US), maybe Amazon and eBay (need icons), but that doesn't really fix the problem with all other searchplugins.
(In reply to Francesco Lodolo [:flod] from comment #7)
> I don't have an answer honestly. Who's going to create all 74x74px versions
> of the images? I definitely can't, and I raised the problem in bug 895520.
> 
> Just to have a glimpse at the complexity 
> http://l10n.mozilla-community.org/~flod/p12n/images/?channel=trunk#metro
> 
> To make things worse, desktop uses 16px icons, not 32px like mobile.
> 
> We can decide to fix Wikipedia and Yahoo (they're used in en-US), maybe
> Amazon and eBay (need icons), but that doesn't really fix the problem with
> all other searchplugins.

I think the right answer is we need to add the larger icons for every provider just like we do for mobile. :/ cc'ing Karen, maybe she can help find the resources for this / make a call.
Flags: needinfo?(krudnitski)
Summary: Defect - different icons for Amazon and Yahoo search providers on Italian Nightly build → Different icons for Amazon and Yahoo search providers on Italian Nightly build
Whiteboard: [beta28] → [defect] [beta28] p=0
Just so I'm clear - the scaling of the icons isn't working showing well since ultimately, we want larger icon sizes.

I do work with BD who works with the major search providers to get the assets we need, so I suppose I just need the actual dimensions (and which providers are affected).

Where I'm not clear is whether this is a Yahoo-specific request and that the others are scaling ok? Or for the 4 'default' providers we're shipping in Metro, we want 74x74 sized icons?

And is 74x74 the correct size we need for optimal presentation? 

Thanks, Karen
Flags: needinfo?(krudnitski)
mconnor is handling the updating of the 74x74 images, see bug 951465.
Whiteboard: [defect] [beta28] p=0 → [beta28] [defect] p=0
Does this get any easier if we make design changes to use 64x64? This seems like a much more common size, and we can down-scale 128x128 or 265x256px icons nicely, so those sizes would also work.
From triage, we've decided we can't wait on this.

Current list of tiles available to metrofx:

http://l10n.mozilla-community.org/~flod/p12n/images/?channel=trunk#metro
Assignee: nobody → mconnor
OS: Windows 8 → Windows 8.1
Summary: Different icons for Amazon and Yahoo search providers on Italian Nightly build → Metro firefox requires updated search provider tiles for non-US providers
Whiteboard: [beta28] [defect] p=0 → [defect] p=0
Blocks: metrobacklog
No longer blocks: metrov1backlog
What about all other locales? We're talking about 80 or so locales to fix, not just Italian.
(In reply to Francesco Lodolo [:flod] from comment #13)
> What about all other locales? We're talking about 80 or so locales to fix,
> not just Italian.

Yes, they all need updated tiles.
So... clarifying question: when are you saying this needs to be done?
(In reply to Mike Connor [:mconnor] from comment #15)
> So... clarifying question: when are you saying this needs to be done?

Well we currently display the smaller 16x16 icons in place of the larger images. So we have a fallback in place. I think what we need to do is get this on the radar and as we update these images, make sure we request the higher resolution versions as we go. At some point we went through this for android.. not sure what kind of priority we set on that work, but I'd say this is similar.

Note a few of our US specific tiles were filed under bug 951465 from some reason. There's also a discussion there on what the appropriate size is.
Depends on: 951465
(In reply to Jim Mathies [:jimm] from comment #12)
> From triage, we've decided we can't wait on this.
> 
> Current list of tiles available to metrofx:
> 
> http://l10n.mozilla-community.org/~flod/p12n/images/?channel=trunk#metro

We "can't wait" as in.. we *won't block* on this bug for rollout with 28.
I think we can probably fix some big locales in beta next cycle (e.g. de, fr, ru, es-ES, it), provided that I understand which parameters are needed for some partners (Yahoo, eBay), and who will create these images (if I have to do that, I need specifications and directions).

Most locales will be fixed in aurora, so shipped with Fx 29.
Are we shipping Ebay in the Metro side?  I don't see it currently, so I'm not sure we should do it in localized builds.  We need to get a set of guidelines together for what we do/don't include.
An important note here, metro firefox is not desktop firefox as far as any search agreements we have are concerned. So for example our predefined search plugins don't use desktop search contract codes in them. It's important we avoid doing that for other providers we have contracts with.

http://mxr.mozilla.org/mozilla-central/source/browser/locales/en-US/searchplugins/

^ Note that we have different plugins based on the browser we build.

I'm not sure who keeps track of these agreements or how we setup search plugins in localized builds. flod, can you share any details?
I personally don't keep track of them, my point of reference is usually Joanne (now CCed).

I kind of remember seeing around Metro params specific for Yahoo Metro though (Karen?)
(In reply to Mike Connor [:mconnor] from comment #19)
> Are we shipping Ebay in the Metro side?  I don't see it currently, so I'm
> not sure we should do it in localized builds.  We need to get a set of
> guidelines together for what we do/don't include.

Based on the initial discussion we had with Metro team, l10n builds should be free to ship the search engines they want. I don't think it's reasonable to force a set of searchplugins relevant for en-US to other locales.

Having said that, all productization changes require specific approval from l10n-drivers, so for the first wave we decided to ship the same searchplugins desktop is shipping for that locale, using Metro versions where available (i.e. Google, Bing).
(In reply to Francesco Lodolo [:flod] from comment #21)
> I kind of remember seeing around Metro params specific for Yahoo Metro
> though (Karen?)

I think this is covered by bug 942024 in which we're still waiting on an answer.
Depends on: 942024
(In reply to Francesco Lodolo [:flod] from comment #22)
> Based on the initial discussion we had with Metro team, l10n builds should
> be free to ship the search engines they want. I don't think it's reasonable
> to force a set of searchplugins relevant for en-US to other locales.

I wasn't involved in those discussions, but let's set some expectations: localizers are not likely to get a blank cheque here.  I know we've been relatively laissez-faire about that concept for a few years, but we've already talked about the need to start cleaning this up, for desktop as well.  This isn't just about financial implications, but also about the desire to ensure we're providing a consistent experience.  I'll follow up with the right people to see where those discussions have ended up.
(In reply to Mike Connor [:mconnor] from comment #24)
> I wasn't involved in those discussions, but let's set some expectations:
> localizers are not likely to get a blank cheque here.  I know we've been
> relatively laissez-faire about that concept for a few years, but we've
> already talked about the need to start cleaning this up, for desktop as
> well.

I believe these terms don't describe correctly the current situation. Every single change to searchplugins and protocol handlers has been discussed and approved by l10n-drivers at some point, IMO the "clean up" was needed mainly because en-US fixed things without considering l10n a blocker, or having a strategy for l10n at all.

I agree that this discussion should happen elsewhere though, and involve all stakeholders.
Assignee: mconnor → nobody
Mass close of bugs in obsolete product https://bugzilla.mozilla.org/show_bug.cgi?id=1350354
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.