Files
react-native-devtools-frontend/scripts
Krishna Govind 897c867a07 Revert "DevTools: Added GRD/GRDP files for all localizable strings in the DevTools."
This reverts commit 2f05fdbf2ab3458b4b3a3f2a86f908a3a7d04f79.

Reason for revert: Breaks chrome translation, crbug 966547

Original change's description:
> DevTools: Added GRD/GRDP files for all localizable strings in the DevTools.
> 
> This change includes...
> * A main GRD file for the DevTools (front_end/langpacks/devtools_ui_strings.grd)
> * GRDP files organized by subfolder
> * A node script that keeps the GRD/GRDP files in sync with the keys in the DevTools frontend
> * A git cl presubmit --upload check that runs the node script
> 
> Note: Subsequent changes will add a build step to generate a .pak file that contains these DevTools strings. You can read about the overall approach here (https://bugs.chromium.org/p/chromium/issues/detail?id=941561).
> 
> 
> Details of this design:
> ======================
> We followed a similar pattern used by WebUI where strings are encoded in GRIT GRD/P files, which are used by a localization service to perform translations. They are also consumed in the build step to generate a .pak file, which is loaded by the browser's resource system.
> 
> Chromium documentation:
> * https://www.chromium.org/developers/tools-we-use-in-chromium/grit/grit-users-guide
> * https://www.chromium.org/developers/design-documents/ui-localization
> 
> Frontend strings:
> -----------------
> These are the localizable strings that are displayed to the user.
> 
> GRDP <message> strings:
> -----------------------
> Each frontend string has a corresponding <message> entry in a GRDP file. These entries are what the localization service will use to perform localizations. It's also the input to the GRIT compiler, which generates a .pak file, which is loaded by the browser's resource_bundle system.
> 
> GRDP <messsage> placeholders:
> ----------------------------
> Frontend strings use placeholders, which are used to substitute in values at runtime.
> For example,
> 'This string has %s two placeholder %.2f.'
> 
> Since the order of the string may change in a different language, we need to encode the order of the placeholders. As such, in the GRDP file you'll find %s replaced with $[1-9].
> 
> For example,
> 'This string has <ph name="ph1">$1s</ph> two placeholder <ph name="ph2">$2.2f</ph>.'
> 
> Also, note that the precision and type of the placeholder is maintained (i.e. .2f).
> 
> Detecting changes:
> -----------------
> The check_localizable_resources.js script performs the following check and generates an error if there are any changes that need to be made to a GRDP file.
> 
> 1. Parses the frontend strings and hashes them.
> 2. Reads the messages from the GRDP files and hashes them.
> 3. Uses a difference between these two sets to report which strings need to be added and/or removed from GRDP files.
> 
> Optionally, the user can specify --autofix and it will automatically update the appropriate GRDP files.
> 
> Presubmit check:
> ---------------
> Running git cl presubmit --upload will run the check_localizable_resources.js script with the --autofix argument.
> 
> If there are any changes, they reported to the user like this.
> 
> ** Presubmit ERRORS **
> Error: Found changes to localizable DevTools strings.
> DevTools localizable resources checker has updated the appropriate grdp file(s).
> Manually write a description for any new <message> entries.
> Use git status to see what has changed.
> 
> BUG=941561
> 
> Change-Id: I5ac1656a037a6aaffeb4f64b103c4daec28be39a
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1613921
> Reviewed-by: Joel Einbinder <einbinder@chromium.org>
> Reviewed-by: Alexei Filippov <alph@chromium.org>
> Commit-Queue: Lorne Mitchell <lomitch@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#662371}

TBR=alph@chromium.org,einbinder@chromium.org,exterkamp@chromium.org,jeffish@microsoft.com,lomitch@microsoft.com

Change-Id: Ic4ca7d000d10b2bc61b585198469ca30f051dc62
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 941561
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1627943
Reviewed-by: Krishna Govind <govind@chromium.org>
Commit-Queue: Krishna Govind <govind@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#662798}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: ceb872b6f6a02d707783563a225c77bb0c62170a
2019-05-23 20:33:45 +00:00
..

DevTools Scripts

Development workflow scripts

These are scripts that can be useful to run independently as you're working on Chrome DevTools front-end.

The newer scripts such as for testing and hosted mode are written in Node.js, which has become the standard toolchain for web apps. The older scripts such as building (e.g. bundling and minifying) are written in Python, which has first-class support in Chromium's infrastructure.

Overview

Folders

  • build - Python package for generating DevTools debug and release mode
  • chrome_debug_launcher - automagically finds Chrome Canary and launches it with debugging flags (e.g. remote debugging port)
  • closure - see section on Closure Compiler below
  • gulp - experimental build process written in node.js & gulp to remove the dependency on Chromium-specific build tools (i.e. gn and ninja)
  • hosted_mode - run DevTools on a localhost development server
  • jsdoc_validator - enforces the use of Closure type annotations
  • local_node - installs a local runtime of node.js

Python Scripts

  • convert_svg_images_to_png.py - manually run when adding svg images
  • compile_frontend.py - runs closure compiler to do static type analysis
    • Note: the compiled outputs are not actually used to run DevTools
  • lint_javascript.py - run eslint
  • optimize_png_images.py - manually run when adding png images

Node.js scripts

The easiest way to run the node.js scripts is to use npm run which displays all the commands. For more information on the specific npm run commands, take a look at the primary devtools front-end readme (../readme.md).

Closure

DevTools manually rolls the closure compiler to ./closure. If you manually roll closure compiler, you will need to re-generate the closure_runner (in ./closure) and jsdoc_validator custom jars using the python scripts in their respective directory.