Do we want to do this?  Extension strings is pretty tiny, and IIRC, grd files have some inherent overhead (in terms of compile time, and maybe even binary size?).  What's the main motivation here?

For settings the motivation was to cleanly separate the old Options strings from the new MD strings, such that we can easily delete the old stuff when that time comes. Does MD Extensions re-use strings from old Extensions?

Also regarding performance, my expectation was the opposite. Touching a string residing in generated_resources.grd has to rebuild the entire grit target for that file, where as touching a smaller file would rebuild a much smaller target, making Extensions development faster. Is that not the case?

Extensions reuses a handful of old strings (semi-educated guess - between 10% and 30%) from the old page.

Re performance and the like, +Lei, who has much more experience here than I do, and will be much more helpful. :)

Another slight concern is that we'd potentially need to shard these again based on Chrome vs Chromium; is that correctly handled in settings grd files?

Where are we moving strings from, and what's the proposed destination(s) ?

Settings strings are distributed across three files,
 - settings_chromium_strings.grdp holds Chromium only strings, included at [1]
 - settings_google_chrome_strings.grdp, Chrome only strings, included at [2]
 - settings_strings.grdp common strings, included at [3]

[1] https://cs.chromium.org/chromium/src/chrome/app/chromium_strings.grd?l=126
[2] https://cs.chromium.org/chromium/src/chrome/app/google_chrome_strings.grd?l=128
[3] https://cs.chromium.org/chromium/src/chrome/app/generated_resources.grd?type=cs&l=192.

The question is whether it would be OK to follow a similar approach for MD Extensions (see comment#2 and #3 on why Settings follows that approach AFAIK). Per my understanding currently all of Extensions page's strings are within generated_resources.grdp.

Would it be a reasonable compromise to put chrome://extensions strings in the same file as other settings strings?  I assume we don't have two files (one for Chrome, one for Chromium) for each settings, bookmarks, history, downloads, etc?

(though, if there is a performance/compile time/binary size *win* by splitting these up, then the more the merrier!)

Would this approach work?

1) Move MD Extensions strings from generated_resources.grd into md_extensions_strings.grdp.
2) Move non-MD only Extensions strings generated_resources.grd into extensions_strings.grdp.
3) Leave the shared strings in generated_resources.grd.
4) When non-MD Extensions gets deleted, delete extensions_strings.grdp, and move the shared strings in (3) into md_extensions_strings.grdp.

Please note the .grd / .grdp difference. There's been several mixups of the two in this discussion so far.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bdb5508af594cd0eba912fd2d46cfae0ae8a881e

commit bdb5508af594cd0eba912fd2d46cfae0ae8a881e
Author: dpapad <dpapad@chromium.org>
Date: Mon Jul 10 23:36:30 2017

MD Extensions: Move MD only strings to their own grdp file.

BUG= 739964 

Review-Url: https://codereview.chromium.org/2975713002
Cr-Commit-Position: refs/heads/master@{#485445}

[modify] https://crrev.com/bdb5508af594cd0eba912fd2d46cfae0ae8a881e/chrome/app/generated_resources.grd
[add] https://crrev.com/bdb5508af594cd0eba912fd2d46cfae0ae8a881e/chrome/app/md_extensions_strings.grdp

Closing this bug, since the proposed file has been added to https://cs.chromium.org/chromium/src/chrome/app/md_extensions_strings.grdp. Further cleanups (like moving all chrome://extensions related strings to that file), can be enabled once the old chrome://extensions UI is deleted.