i18n: use IcuMessage objects instead of string IDs #10630

brendankenny · 2020-04-24T15:13:53Z

As discussed in #10614 and offline, this moves us to using objects for localizable strings. This has several advantages (listed in that issue) and it turns out few disadvantages.

Proposed object:

type IcuMessage = {
  /** The id locating this message in the locale message json files. */
  i18nId: string;
  /** The dynamic values, if any, to insert into the localized string. */
  values?: Record<string, string | number>;
  /** A formatted version of the string, usually as found in a file's `UIStrings` entry, used as backup. */
  formattedDefault: string,
};

Biggest change from the proposal is the formattedDefault which will always be there. This is basically what swap-locale already does (uses the string already in the LHR as backup if lighthouse has changed enough that the message ID no longer refers to a translated string anymore) but uses it for allowing serialization at any stage, as well as for the current UIStrings backup during development (allowing use of a string without having to run yarn update:sample-json after every edit).

The PR changes are a little spread out, but the substantial changes are in

i18n.js
i18n.d.ts
'swap-locale.js`
runner.js
details-renderer.js
audit.d.ts, audit-details.d.ts, lhr.d.ts
more or less in that order for significance of the changes.

brendankenny

I'm going to update the i18n README so if anyone reviewing would rather wait for that to be committed before looking, feel free to do so :)

brendankenny · 2020-04-24T15:14:59Z

lighthouse-cli/run.js

@@ -20,7 +20,7 @@ const assetSaver = require('../lighthouse-core/lib/asset-saver.js');

 const open = require('open');

-/** @typedef {import('../lighthouse-core/lib/lh-error.js')} LighthouseError */
+/** @typedef {Error & {code: string, friendlyMessage?: string}} ExitError */


wasn't worth pretending this was a LighthouseError since either it's a regular Error or we construct it as just an object down on line 224 :)

brendankenny · 2020-04-24T15:16:06Z

lighthouse-core/config/config.js

-   * @param {LH.Config.Json} config
-   * @return {Array<{id: string, title: string}>}
-   */
-  static getCategories(config) {


this is only used in two tests now and not any active code (maybe after the extension was removed?), so it seemed easier just to delete than to deal with localization

lighthouse-core/lib/i18n/swap-locale.js

brendankenny · 2020-04-24T15:22:37Z

lighthouse-core/report/html/renderer/details-renderer.js

+/** @typedef {LH.FormattedIcu<LH.Audit.Details.Opportunity>} OpportunityTable */
+/** @typedef {LH.FormattedIcu<LH.Audit.Details.OpportunityColumnHeading>} OpportunityTableHeading */
+/** @typedef {LH.FormattedIcu<LH.Audit.Details.Table>} Table */
+/** @typedef {LH.FormattedIcu<LH.Audit.Details.TableColumnHeading>} TableHeading */


This is my least favorite part of this change and I haven't come up with a nice solution yet. Unlike with Audit product/result, we don't have a good split on audit details (the same types are used in audits and in the LHR).

The types are all correct on the LHR, but if you want to refer to the type in isolation (and don't want to do LH.Result['audits'][number]['details']['whatever']['etc']['etc']) you need a reference to the type directly like this.

Other options:

we have some sort of audit details product/result split?

move these under LH.Result namespace?

move these under LH.Result namespace?

That seems reasonable but this works too.

brendankenny · 2020-04-24T15:23:22Z

lighthouse-core/runner.js

-      // i18n error strings
-      err.friendlyMessage = i18n.getFormatted(err.friendlyMessage, settings.locale);
+      // i18n LighthouseError strings.
+      if (err.friendlyMessage) {


turns out these aren't always LHErrors and we were often formatting undefined :)

paulirish · 2020-04-28T01:24:51Z

lighthouse-core/lib/i18n/i18n.js

 */
-function _formatIcuMessage(locale, icuMessageId, uiStringMessage, values = {}) {
+function _localizeIcuMessage(icuMessage, locale) {


i like the new split between _localizeIcuMessage and _formatMessage

paulirish · 2020-04-28T01:28:02Z

lighthouse-core/lib/i18n/i18n.js

- * generate the string ids.
- *
+ * Returns a function that generates `LH.IcuMessage` objects to localize the
+ * messages in `fileStrings` and the shared `i18n.UIStrings`.
 * @param {string} filename
 * @param {Record<string, string>} fileStrings
 */
 function createMessageInstanceIdFn(filename, fileStrings) {


can we rename this to createIcuMessageFn internally here.. we can still expose it in module.exports as the long name (for now)

can we rename this to createIcuMessageFn internally here.. we can still expose it in module.exports as the long name (for now)

should both names be exposed and we convert all Lighthouse audits over to using createIcuMessageFn?

lighthouse-core/lib/i18n/swap-locale.js

patrickhulce

so it was mostly s/string/string|IcuMessage/ in audits afterall :)

it does seem pretty smooth and the increased future flexibility seems like a good time to do it, very impressive 👍

patrickhulce · 2020-04-29T02:01:26Z

lighthouse-core/audits/byte-efficiency/render-blocking-resources.js

@@ -208,7 +208,7 @@ class RenderBlockingResources extends Audit {
  static async audit(artifacts, context) {
    const {results, wastedMs} = await RenderBlockingResources.computeResults(artifacts, context);

-    let displayValue = '';
+    let displayValue;


these are inferred correctly, right? in tsc playground it seems to work out out OK but some of the assertions we're removing later on in jsdoc makes me think some of them were necessary at one point in time for our checkJs setup...

https://www.typescriptlang.org/play/#code/DYUwLgBAZg9jDcAoRBLKEAUBZAhmAFgHQBOOAdgCYwC2GAlBAHwQAMhArAwN6IR-RwIAXghcAHgC4IARgA0EAJ5SATAF9E65AGMYZAM4xQhYDADmGWDEIAvOkA

these are inferred correctly, right?

yes, they haven't been necessary for a while. I don't remember when conditional initialization like this was added, but basically the CFG typing keeps getting better.

patrickhulce · 2020-04-29T02:04:27Z

lighthouse-core/config/config-helpers.js

+ * @param {unknown} value
+ * @return {value is string|LH.IcuMessage}
+ */
+function isStringOrIcuMessage(value) {


should this just live on i18n or you feel like it won't come up again?

should this just live on i18n or you feel like it won't come up again?

it seemed like just an internal helper fn for config (since the inline check was too long for the line and repeated 3x), so it's just scoped to the module, but I don't have strong feelings about keeping it locked away.

patrickhulce · 2020-04-29T02:05:27Z

lighthouse-core/lib/i18n/README.md

@@ -213,13 +213,15 @@ CTC is a name that is distinct and identifies this as the Chrome translation for

 # Appendix

+TODO(bckenny): update


is this TODO as part of this PR or later? :)

is this TODO as part of this PR or later? :)

part of this PR :) I'll try to figure out what I thought should be added

lighthouse-core/lib/i18n/i18n.js

patrickhulce · 2020-04-29T02:07:26Z

lighthouse-core/lib/i18n/i18n.js

 * @param {MessageFormat} messageFormatter
 * @param {Readonly<Record<string, string | number>>} values
+ * @param {string} icuMessage Used for clear error logging.


should we rename this param now that icuMessage means that object thing returned from a string we want localized

should we rename this param now that icuMessage means that object thing returned from a string we want localized

I'll use lhlMessage since it's in that format? Or should it be rawMessage or..something?

lighthouse-core/lib/i18n/i18n.js

patrickhulce · 2020-04-29T02:20:36Z

types/i18n.d.ts

+     * Heavy handed and requires more type checks, so prefer explicitly setting
+     * properties to include `LH.IcuMessage` over this helper if possible.
+     */
+    type Icu<T> = T extends IcuMessage ? T :


how do you feel about calling this UnformattedIcu or RawIcu or something?

it was a bit weird seeing this in usage until I came here to see it sitting in direct contrast to FormattedIcu

how do you feel about calling this UnformattedIcu or RawIcu or something?

it was a bit weird seeing this in usage until I came here to see it sitting in direct contrast to FormattedIcu

RawIcu sounds good to me since UnformattedIcu is a little visually confusable with FormattedIcu, but happy to bikeshed more now that it's been 5 months since this comment :)

patrickhulce · 2020-04-29T02:42:30Z

lighthouse-core/report/html/renderer/details-renderer.js

+/** @typedef {LH.FormattedIcu<LH.Audit.Details.Opportunity>} OpportunityTable */
+/** @typedef {LH.FormattedIcu<LH.Audit.Details.OpportunityColumnHeading>} OpportunityTableHeading */
+/** @typedef {LH.FormattedIcu<LH.Audit.Details.Table>} Table */
+/** @typedef {LH.FormattedIcu<LH.Audit.Details.TableColumnHeading>} TableHeading */


move these under LH.Result namespace?

That seems reasonable but this works too.

patrickhulce · 2020-04-29T02:45:44Z

lighthouse-core/test/lib/i18n/i18n-test.js

@@ -32,17 +32,20 @@ describe('i18n', () => {
  });

  describe('#createMessageInstanceIdFn', () => {
-    it('returns a string reference', () => {
+    it('returns a IcuMessage reference', () => {


Suggested change

it('returns a IcuMessage reference', () => {

it('returns an IcuMessage reference', () => {

patrickhulce · 2020-04-29T02:48:39Z

lighthouse-core/test/lib/i18n/swap-locale-test.js

@@ -52,6 +52,7 @@ describe('swap-locale', () => {
        redirects: {
          id: 'redirects',
          title: 'Avoid multiple page redirects',
+          doesntExist: 'A string that does not have localized versions',


should we add a different path to something that doesn't exist then? feels like this is a duplicate test of fakeaudit title otherwise

should we add a different path to something that doesn't exist then? feels like this is a duplicate test of fakeaudit title otherwise

clarified in a comment that it's slightly different due to the message key, but also added a separate test for paths to things that don't exist.

paulirish · 2020-05-04T21:59:37Z

TODO: add test for serializability ;)

brendankenny · 2020-04-24T21:16:27Z

lighthouse-core/audits/image-aspect-ratio.js

@@ -68,7 +68,7 @@ class ImageAspectRatio extends Audit {

    if (!Number.isFinite(actualAspectRatio) ||
      !Number.isFinite(displayedAspectRatio)) {
-      return new Error(str_(UIStrings.warningCompute, {url}));
+      return str_(UIStrings.warningCompute, {url});


we never use this as an Error, just a string container (the Error is returned and then if it passes instanceof Error, its message is pushed into a warnings array), so if replacing that string with an IcuMessage, might as well just use that as the whole return value in the error case :)

brendankenny

still TODO:

update i18n/readme.md, apparently
createIcuMessageFn question
serialization check

as mentioned in the meeting today, several more people have spent time with localization and audit-details, etc since this PR was opened, so feel free to weigh in on the design!

brendankenny · 2020-09-14T22:47:19Z

lighthouse-core/audits/byte-efficiency/render-blocking-resources.js

@@ -208,7 +208,7 @@ class RenderBlockingResources extends Audit {
  static async audit(artifacts, context) {
    const {results, wastedMs} = await RenderBlockingResources.computeResults(artifacts, context);

-    let displayValue = '';
+    let displayValue;


these are inferred correctly, right?

yes, they haven't been necessary for a while. I don't remember when conditional initialization like this was added, but basically the CFG typing keeps getting better.

brendankenny · 2020-09-14T23:05:47Z

lighthouse-core/config/config-helpers.js

+ * @param {unknown} value
+ * @return {value is string|LH.IcuMessage}
+ */
+function isStringOrIcuMessage(value) {


should this just live on i18n or you feel like it won't come up again?

it seemed like just an internal helper fn for config (since the inline check was too long for the line and repeated 3x), so it's just scoped to the module, but I don't have strong feelings about keeping it locked away.

brendankenny · 2020-09-14T23:06:30Z

lighthouse-core/lib/i18n/README.md

@@ -213,13 +213,15 @@ CTC is a name that is distinct and identifies this as the Chrome translation for

 # Appendix

+TODO(bckenny): update


is this TODO as part of this PR or later? :)

part of this PR :) I'll try to figure out what I thought should be added

lighthouse-core/lib/i18n/i18n.js

brendankenny · 2020-09-14T23:10:35Z

lighthouse-core/lib/i18n/i18n.js

 * @param {MessageFormat} messageFormatter
 * @param {Readonly<Record<string, string | number>>} values
+ * @param {string} icuMessage Used for clear error logging.


should we rename this param now that icuMessage means that object thing returned from a string we want localized

I'll use lhlMessage since it's in that format? Or should it be rawMessage or..something?

brendankenny · 2020-09-14T23:12:09Z

lighthouse-core/lib/i18n/i18n.js

- * generate the string ids.
- *
+ * Returns a function that generates `LH.IcuMessage` objects to localize the
+ * messages in `fileStrings` and the shared `i18n.UIStrings`.
 * @param {string} filename
 * @param {Record<string, string>} fileStrings
 */
 function createMessageInstanceIdFn(filename, fileStrings) {


can we rename this to createIcuMessageFn internally here.. we can still expose it in module.exports as the long name (for now)

should both names be exposed and we convert all Lighthouse audits over to using createIcuMessageFn?

brendankenny · 2020-09-14T23:16:11Z

types/i18n.d.ts

+     * Heavy handed and requires more type checks, so prefer explicitly setting
+     * properties to include `LH.IcuMessage` over this helper if possible.
+     */
+    type Icu<T> = T extends IcuMessage ? T :


how do you feel about calling this UnformattedIcu or RawIcu or something?

it was a bit weird seeing this in usage until I came here to see it sitting in direct contrast to FormattedIcu

RawIcu sounds good to me since UnformattedIcu is a little visually confusable with FormattedIcu, but happy to bikeshed more now that it's been 5 months since this comment :)

lighthouse-core/lib/i18n/i18n.js

patrickhulce

the bones still look great!

patrickhulce · 2020-09-16T14:56:21Z

types/audit.d.ts

@@ -66,23 +66,25 @@ declare global {
      wastedPercent?: number;
    }

+    // TODO: consider making some of the `string | IcuMessage` into just `IcuMessage` to require i18n.


is this the main reason we're doing string | IcuMessage manually here instead of using the RawIcu type?

is this the main reason we're doing string | IcuMessage manually here instead of using the RawIcu type?

Yeah, and the ergonomics are also just more straightforward to use, since RawIcu<> makes it an indirect step when using in vscode...you can't just see the type on the object, it'll look like LH.RawIcu<{text: string}> or LH.RawIcu<ProductBase> (and if you click through to ProductBase you would only see string), so it would only be when accessing the property directly that you would see the type.

(There's a comment on the RawIcu type that points to prefer making properties | LH.IcuMessage instead of using it for this reason)

I tried making more of these LH.IcuMessage only, and I think for every one of them there was some audit that was currently breaking the rules and had a string instead of a localized message, but that was in April, maybe it's better. There's also the question of if these types are just for us, or also for folks writing plugins/custom audits, and they might not want to bother with localization yet, so not allowing string would break them.

patrickhulce · 2020-09-16T14:57:31Z

lighthouse-core/test/audits/third-party-summary-test.js

@@ -69,7 +69,7 @@ describe('Third party summary', () => {
            {
              blockingTime: 0,
              transferSize: 8007,
-              url: expect.any(String),
+              url: expect.toBeDisplayString('Other resources'),


lighthouse-core/lib/i18n/i18n.js

brendankenny · 2020-09-16T17:09:47Z

lighthouse-core/test/runner-test.js

@@ -155,6 +156,63 @@ describe('Runner', () => {
        expect(runAuditSpy).toHaveBeenCalled();
      });
    });
+
+    it('serializes IcuMessages in gatherMode and is able to use them in auditMode', async () => {


kind of a monster sized test because it does a gatherMode run and an auditMode run, but I also didn't really want to split because it's annoying when tests have interdependencies, so 🤷

It might make sense to split the three -G, -A, and loadArtifacts components separately since we're asserting the exact shape of the artifacts already?

I would prioritize the e2e flow though like you did here anyway 🤷

brendankenny · 2020-09-16T17:12:14Z

lighthouse-core/test/runner-test.js

+      class WarningAndErrorGatherer extends Gatherer {
+        afterPass(passContext) {
+          const warning = str_(i18n.UIStrings.displayValueByteSavings, {wastedBytes: 2222});
+          passContext.LighthouseRunWarnings.push(warning);


lherrors have actually been serializing fine since #9397, it's other strings like runWarnings that have been causing the -G/-A problems (see #9269 (comment)), so this test checks both are working.

brendankenny · 2020-09-16T17:16:22Z

lighthouse-core/test/runner-test.js

+      expect(lhr.audits['dummy-audit']).toMatchObject({
+        scoreDisplayMode: 'error',
+        // eslint-disable-next-line max-len
+        errorMessage: 'Required WarningAndErrorGatherer gatherer encountered an error: UNSUPPORTED_OLD_CHROME',


should probably follow up this PR and make the automatic audit errors that come from artifact errors use friendlyMessage instead of just message (which is set to just the code), because a lot of context is lost here. Downside: error messages get a lot longer.

brendankenny · 2020-09-16T22:59:29Z

outstanding TODOs are complete, ready for review :)

brendankenny · 2020-09-17T00:39:36Z

@connorjclark smoke-devtools times out no matter how many times I run this (and it's rebased against latest). Any ideas?

lighthouse-core/lib/i18n/i18n.js

patrickhulce · 2020-09-17T15:09:04Z

lighthouse-core/test/runner-test.js

+        name: 'LHError',
+        code: 'UNSUPPORTED_OLD_CHROME',
+        // eslint-disable-next-line max-len
+        friendlyMessage: expect.toBeDisplayString(`This version of Chrome is too old to support 'VRML'. Use a newer version to see full results.`),


patrickhulce · 2020-09-17T15:11:26Z

lighthouse-core/test/runner-test.js

@@ -155,6 +156,63 @@ describe('Runner', () => {
        expect(runAuditSpy).toHaveBeenCalled();
      });
    });
+
+    it('serializes IcuMessages in gatherMode and is able to use them in auditMode', async () => {


It might make sense to split the three -G, -A, and loadArtifacts components separately since we're asserting the exact shape of the artifacts already?

I would prioritize the e2e flow though like you did here anyway 🤷

patrickhulce · 2020-09-17T15:16:03Z

Are there devtools changes required to make this work with the timeouts? Nothing immediately comes to mind, but definitely suspicious...

I love the direction this takes us! Much more self-contained and explicit about what's i18n'd and what's not 💯 👍

connorjclark · 2020-09-17T16:54:17Z

The recent changes in devtools broke Lighthouse in release and locally. I think they've reverted or fixed it since.

I don't think there's a way to clear the github action cache... you might need to add a nonce comment in the devtools.yml, to trigger a new cache.

brendankenny · 2020-09-17T17:32:06Z

hmm, it's the same key and commit that's passed on the latest commit on master, but caches are hard, so I'll try it :)

connorjclark · 2020-09-17T17:45:39Z

I ran it locally and got this error:

oddly, I don't even have pubads checked.

brendankenny · 2020-09-17T17:56:37Z

weird, but that's great, that really is something that needs to be updated. Any ideas on how we could pipe startup errors like that back to github actions instead of timing out?

edit: connor's on it in #11414 :)

brendankenny · 2020-09-17T18:56:50Z

OK:

moved isStringOrIcuMessage to i18n.js so config-helpers and config-plugin can use it
config-plugin now allows IcuMessage for the relevant config strings
added a config-plugin test with a localizable plugin
temporarily switched all the string | IcuMessage types to just IcuMessage and verified there aren't any other places that should account for IcuMessage but currently don't

Co-authored-by: Patrick Hulce <patrick.hulce@gmail.com>

connorjclark · 2020-09-17T21:24:57Z

lighthouse-core/test/chromium-web-tests/run-web-tests.sh

@@ -84,7 +84,7 @@ cp "$DEVTOOLS_PATH/test/webtests/http/tests/devtools/lighthouse/"*-expected.txt
 if [ ! $status -eq 0 ]; then
  # Print failure diffs to stdout.
  find "$LH_ROOT/.tmp/layout-test-results/retry_3" -name '*-diff.txt' -exec cat {} \;
-  echo "❌❌❌ webtests failed. to rebaseline run: yarn update:webtests ❌❌❌"
+  echo "❌❌❌ webtests failed. to rebaseline run: yarn update:test-devtools ❌❌❌"


connorjclark · 2020-09-17T21:26:52Z

...hromium-webtests/webtests/http/tests/devtools/lighthouse/lighthouse-emulate-run-expected.txt

@@ -25,5 +25,5 @@ ViewportDimensions: {
 }


-content-width: pass 
+content-width: pass undefined


audit.explanation is optional, so can be undefined :)

It was the empty string before...not sure that's better :)

seems like we should only put audit.explanation into the result when the audit is failing 🤔

can you add to the list? I also want to pull this into a fn in LighthouseTestRunner (also used in other tests)

patrickhulce · 2020-09-17T21:52:48Z

new changes LGTM too, so I'll let my review stand. Yay devtools tests for catching things at PR time 😃 🎉

brendankenny requested a review from a team as a code owner April 24, 2020 15:13

brendankenny requested review from exterkamp and removed request for a team April 24, 2020 15:13

googlebot added the cla: yes label Apr 24, 2020

brendankenny commented Apr 24, 2020

View reviewed changes

devtools-bot assigned exterkamp Apr 24, 2020

devtools-bot added the waiting4reviewer label Apr 24, 2020

paulirish reviewed Apr 28, 2020

View reviewed changes

brendankenny assigned patrickhulce Apr 28, 2020

paulirish requested a review from patrickhulce April 28, 2020 18:49

patrickhulce suggested changes Apr 29, 2020

View reviewed changes

patrickhulce added waiting4committer and removed waiting4reviewer labels Apr 29, 2020

paulirish mentioned this pull request May 4, 2020

core: serialize i18n instances for gather mode #10520

Closed

brendankenny mentioned this pull request Jun 24, 2020

core(is-on-https): add mixed-content resolution #10975

Merged

brendankenny commented Sep 14, 2020

View reviewed changes

brendankenny force-pushed the icuobjects branch from 8f6a4cc to 2fa2105 Compare September 14, 2020 20:27

vercel bot deployed to Preview September 14, 2020 20:28 View deployment

brendankenny force-pushed the icuobjects branch from 2fa2105 to 95c196f Compare September 14, 2020 20:50

vercel bot deployed to Preview September 14, 2020 20:50 View deployment

brendankenny commented Sep 14, 2020

View reviewed changes

brendankenny force-pushed the icuobjects branch from 95c196f to 051a8b6 Compare September 15, 2020 16:47

vercel bot deployed to Preview September 15, 2020 16:47 View deployment

patrickhulce reviewed Sep 16, 2020

View reviewed changes

vercel bot deployed to Preview September 16, 2020 16:59 View deployment

brendankenny commented Sep 16, 2020

View reviewed changes

vercel bot deployed to Preview September 16, 2020 22:57 View deployment

brendankenny removed the waiting4committer label Sep 16, 2020

brendankenny force-pushed the icuobjects branch from 48d0df3 to 4455f24 Compare September 17, 2020 00:03

vercel bot deployed to Preview September 17, 2020 00:03 View deployment

patrickhulce approved these changes Sep 17, 2020

View reviewed changes

connorjclark mentioned this pull request Sep 17, 2020

DevTools webtests improvements #11414

Closed

10 tasks

handle localized plugins

28d0e41

vercel bot deployed to Preview September 17, 2020 18:54 View deployment

review suggestion

9898a9f

Co-authored-by: Patrick Hulce <patrick.hulce@gmail.com>

vercel bot deployed to Preview September 17, 2020 18:58 View deployment

devtools expectations

f377a81

vercel bot deployed to Preview September 17, 2020 21:23 View deployment

connorjclark reviewed Sep 17, 2020

View reviewed changes

brendankenny merged commit 378a31f into master Sep 17, 2020

brendankenny deleted the icuobjects branch September 17, 2020 22:08

brendankenny mentioned this pull request Sep 24, 2020

core(driver): don't clear indexedb, websql, or localstorage before run #11438

Merged

This was referenced Oct 1, 2020

new_audit: third party facades #11290

Merged

new_audit: issues logged in the Issues panel in DevTools #11409

Merged

LigthouseRunWarnings are not completely deduplicated #11514

Closed

brendankenny mentioned this pull request Oct 27, 2020

LH throws error when running plugin globally googleads/publisher-ads-lighthouse-plugin#159

Closed

This was referenced Jan 12, 2021

proposal(i18n): drop global and local string refs into it; use local IcuMessage objs instead #10614

Closed

i18n strings in artifacts from -G throw errors when run through -A #9269

Closed

alexnj mentioned this pull request Aug 1, 2022

core(i18n): delete i18n.createMessageInstanceIdFn #14251

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

i18n: use IcuMessage objects instead of string IDs #10630

i18n: use IcuMessage objects instead of string IDs #10630

		@@ -213,13 +213,15 @@ CTC is a name that is distinct and identifies this as the Chrome translation for

		# Appendix

		TODO(bckenny): update

	it('returns a IcuMessage reference', () => {
	it('returns an IcuMessage reference', () => {

i18n: use IcuMessage objects instead of string IDs #10630

i18n: use IcuMessage objects instead of string IDs #10630

Conversation

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment