Web Inspector: Sources: allow image collections to be filtered by type

• Component: Web Inspector
• Status: RESOLVED FIXED

[Devin Rousso]

<https://bugs.webkit.org/show_bug.cgi?id=145906#c8>

[Devin Rousso]

Created attachment 364428 [details]
Patch

[Matt Baker]

Comment on attachment 364428 [details]
Patch

Could we avoid creating UIStrings for extensions? Extensions aren't localizable, and are commonly shown in both all uppercase/all lowercase, so I don't think we need to map "web" to "WebP", for example.

Instead of updating the hidden state of ScopeBarItems as resources change, could we rebuild the bar based on the available resources?

[Matt Baker]

(In reply to Matt Baker from comment #2)
> Comment on attachment 364428 [details]
> Patch
> 
> Could we avoid creating UIStrings for extensions? Extensions aren't
> localizable, and are commonly shown in both all uppercase/all lowercase, so
> I don't think we need to map "web" to "WebP", for example.

"webp" to "WebP"

[Devin Rousso]

(In reply to Matt Baker from comment #2)

> Could we avoid creating UIStrings for extensions? Extensions aren't localizable, and are commonly shown in both all uppercase/all lowercase, so I don't think we need to map "web" to "WebP", for example.
I would tend to agree, but @rniwa pointed out to me a few weeks ago that it's still necessary to make things like this a localized string so that languages that rarely (if ever) use English (like Japanese) would be able to transliterate.  In this case "WebP" isn't referring to the file extension, but rather the MIME "type", such as how 
JPG" holds both *.jpg and *.jpeg.

> Instead of updating the hidden state of ScopeBarItems as resources change, could we rebuild the bar based on the available resources?
I chose the hidden state approach because it was less of a major change given the current capabilities of `WI.ScopeBar`.  If we wanted to rebuild the bar, we'd need to support the ability to set a new list of `WI.ScopeBarItem`, which is probably harder to do considering that this is a `WI.NavigationItem` subclass (e.g. we'd have to update the `WI.ContentView`'s list of `navigationItems`, and fire an event to re-render).

[Matt Baker]

(In reply to Devin Rousso from comment #4)
> (In reply to Matt Baker from comment #2)
> 
> > Could we avoid creating UIStrings for extensions? Extensions aren't localizable, and are commonly shown in both all uppercase/all lowercase, so I don't think we need to map "web" to "WebP", for example.
> I would tend to agree, but @rniwa pointed out to me a few weeks ago that
> it's still necessary to make things like this a localized string so that
> languages that rarely (if ever) use English (like Japanese) would be able to
> transliterate.  In this case "WebP" isn't referring to the file extension,
> but rather the MIME "type", such as how 
> JPG" holds both *.jpg and *.jpeg.

To the last point, if this is a list of "types" rather than extensions, should we use JPEG instead of JPG? After all, when going the other direction WI.mimeTypeForFileExtension maps "jpg" and "jpeg" to "image/jpeg". I'll leave it up to you.

> > Instead of updating the hidden state of ScopeBarItems as resources change, could we rebuild the bar based on the available resources?
> I chose the hidden state approach because it was less of a major change
> given the current capabilities of `WI.ScopeBar`.  If we wanted to rebuild
> the bar, we'd need to support the ability to set a new list of
> `WI.ScopeBarItem`, which is probably harder to do considering that this is a
> `WI.NavigationItem` subclass (e.g. we'd have to update the
> `WI.ContentView`'s list of `navigationItems`, and fire an event to
> re-render).

In the interest of treading lightly, that makes sense. It would still be nice to build the list of extensions/ScopeBarItems dynamically, so it isn't possible to skip an image type. Since the list looks like it was based on the mappings in WI.mimeTypeForFileExtension, I think it's fine.

[Matt Baker]

Comment on attachment 364428 [details]
Patch

r=me, nice enhancement.

[Devin Rousso]

Created attachment 364444 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 364444 [details]
Patch

Clearing flags on attachment: 364444

Committed r242829: <https://trac.webkit.org/changeset/242829>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/48824542>

[Joseph Pecoraro]

Comment on attachment 364444 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=364444&action=review

> Source/WebInspectorUI/Localizations/en.lproj/localizedStrings.js:729
> +localizedStrings["PDF"] = "PDF";
> +localizedStrings["PNG"] = "PNG";

Is there any reason these file extensions should be localized? These seem like the perfect thing to not localize.

[Matt Baker]

Comment on attachment 364444 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=364444&action=review

>> Source/WebInspectorUI/Localizations/en.lproj/localizedStrings.js:729
>> +localizedStrings["PNG"] = "PNG";
> 
> Is there any reason these file extensions should be localized? These seem like the perfect thing to not localize.

See Devin's comment regarding this: https://bugs.webkit.org/show_bug.cgi?id=195630#c4

[Joseph Pecoraro]

(In reply to Matt Baker from comment #12)
> Comment on attachment 364444 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=364444&action=review
> 
> >> Source/WebInspectorUI/Localizations/en.lproj/localizedStrings.js:729
> >> +localizedStrings["PNG"] = "PNG";
> > 
> > Is there any reason these file extensions should be localized? These seem like the perfect thing to not localize.
> 
> See Devin's comment regarding this:
> https://bugs.webkit.org/show_bug.cgi?id=195630#c4

Okay, sounds good.