Bug 195630

Created attachment 364428 [details] Patch

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?

(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"

(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).

(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.

Comment on attachment 364428 [details] Patch r=me, nice enhancement.

Created attachment 364444 [details] Patch

Comment on attachment 364444 [details] Patch Clearing flags on attachment: 364444 Committed r242829: <https://trac.webkit.org/changeset/242829>

All reviewed patches have been landed. Closing bug.

<rdar://problem/48824542>

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.

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

(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.