Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

misc(build): publish dedicated lh-i18n module #10415

Closed
wants to merge 9 commits into from
Closed

Conversation

paulirish
Copy link
Member

@paulirish paulirish commented Mar 3, 2020

connor did most of this in #10148. 😁

The API of the module isn't documented persay, but you can follow it pretty easily from i18n-module.js. Here it is:

image

0.0.1 is already published: https://www.npmjs.com/package/lh-i18n and reflects current lighthouse master.

cc @vidorteg ... wdyt?

  • we can rename the global. currently it's window.Lighthouse.i18n. How would you like it?
  • do you need .d.ts files? I can generate those.

@paulirish paulirish requested a review from a team as a code owner March 3, 2020 12:06
@paulirish paulirish requested review from brendankenny and removed request for a team March 3, 2020 12:06
@paulirish paulirish changed the title publish dedicated lh-i18n module misc(build): publish dedicated lh-i18n module Mar 3, 2020
@@ -442,6 +442,17 @@ message I18n {

// The message holding all formatted strings
RendererFormattedStrings renderer_formatted_strings = 1;

message MessagePath {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove changes.

@connorjclark
Copy link
Collaborator

I may of misunderstood the purpose of this PR. Is this just to show @vidorteg or do you want this to land?

@connorjclark
Copy link
Collaborator

connorjclark commented Mar 4, 2020

We'll probably also want to publish the collection script in the same package (https://docs.google.com/document/d/1L6TkT2-42MMQ72ZSBMFwUaq7M6mDgA2X0x8oHHKaV_U/edit?ts=5d945064#heading=h.eat4lelgbel alludes to this)

@paulirish
Copy link
Member Author

paulirish commented Mar 4, 2020 via email

*/
'use strict';

const browserify = require('browserify');
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe minify it too?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

won't CDT minify?

Copy link
Collaborator

@connorjclark connorjclark Mar 5, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

afaiu security reviewers won't like rolling minified code to chromium

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good point I was thinking that any other customers could benefit from the reduced size, but it may be harder to get approval.


module.exports = {
swapLocale: require('./swap-locale.js'),
...require('./i18n.js'),
Copy link

@vidorteg vidorteg Mar 5, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We took a similar approach for our prototype:

  • grabbing the file, bundling it with browserify and importing it.

But hit a couple a blockers inside i18n.js that required some changes. @christychen126 did a nice work cleaning the library and leaving it in a "minimal required" state, @paulirish and @connorjclark what would be the best way for us to share this with the Lighthouse team (setting a PR with some changes, design document)?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What were the blockers? can just start w/ sharing the branch, details on what the issue was (problems with bundling, or using it?)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we are creating a CL in the devtools repo that shows the changes we did to the library and how we are consuming it. We will also be adding CDT so that the three teams can agree on the details. @christychen126 will post once it is ready.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The link to the CL: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2090459
Any comments and feedback are appreciated!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks, this was useful. i left a comment there

@brendankenny
Copy link
Member

brendankenny commented Mar 9, 2020

@paulirish @vidorteg @christychen126 is there a public interface that we're wanting to commit to? It seems like we don't want to expose/guarantee everything in the screenshot in the top PR comment. That would be a great place to start reviewing.

(https://docs.google.com/document/d/1L6TkT2-42MMQ72ZSBMFwUaq7M6mDgA2X0x8oHHKaV_U/edit?ts=5d945064# has some of it but it's broken up into a few places and not clear that usages listed are exhaustive)

We have a few lingering i18n issues to fix (e.g. #9269) and it would be good to make sure any changes we would need to make wouldn't be externally observable/disruptive.

@christyycchen
Copy link

We'll probably also want to publish the collection script in the same package (https://docs.google.com/document/d/1L6TkT2-42MMQ72ZSBMFwUaq7M6mDgA2X0x8oHHKaV_U/edit?ts=5d945064#heading=h.eat4lelgbel alludes to this)

Hey @connorjclark, we are okay with not having this in the i18n library, since other customer might want the localizability that i18n provides, but not necessary the localization that requires collection scripts. We also did some customization on collectStrings.js and bake-ctc-to-lhl.js to make those work with DevTools, I will put up a CL soon to show what we changed and would appreciate any feedback then :) /cc @vidorteg

@christyycchen
Copy link

@paulirish @vidorteg @christychen126 is there a public interface that we're wanting to commit to? It seems like we don't want to expose/guarantee everything in the screenshot in the top PR comment. That would be a great place to start reviewing.

(https://docs.google.com/document/d/1L6TkT2-42MMQ72ZSBMFwUaq7M6mDgA2X0x8oHHKaV_U/edit?ts=5d945064# has some of it but it's broken up into a few places and not clear that usages listed are exhaustive)

We have a few lingering i18n issues to fix (e.g. #9269) and it would be good to make sure any changes we would need to make wouldn't be externally observable/disruptive.

Hey @brendankenny, we are still testing and refining how the DevTools consumes i18n library. We will follow up with a draft CL that migrates one module in DevTools to use the i18n library which will make the exhaustive usages clearer! Thank you. cc/ @vidorteg

@brendankenny
Copy link
Member

I think this one is chilling, @paulirish?

@connorjclark
Copy link
Collaborator

@paulirish paulirish marked this pull request as draft April 16, 2020 06:49
@vidorteg
Copy link

vidorteg commented Jul 6, 2020

With help of the Lighthouse team , Chromium Devtools ingested a standalone version of i18n:
2119671: front_end/third_party review for i18n.js | https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2119671

Thank for all your help and patience answering our questions Lighthouse Team!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants