implement i18n package

[Jonghakseo]

* Please fill in the required items.

Priority*

• High: This PR needs to be merged first for other tasks.
• Middle: This PR should be merged quickly to prevent conflicts due to common changes. (default)
• Low: This PR does not affect other tasks, so it can be merged later.

Purpose of the PR*

Add I18n Package for internationalize in chrome extension

Changes*

Add I18n Package

The i18n package has two main functions.

First, it offers the t(translate) function, ensuring strong type safety and ease of development for managing multiple languages.

The t function behaves exactly the same as chrome.i18n.getMessage in production. However, it is implemented as a dev-only function to allow developers to see quick results without reloading the extension.

This ensures that features like HMR work as expected while also providing strong type safety by inferring the key values of the messages entered in message.json.

Secondly, developers do not need to manually update the utility functions for type inference whenever adding or removing languages. Through the generate-i18n.mjs file, simply creating or deleting folders and new JSON files is sufficient to prepare support for new languages.

Add Usage into NewTab.tsx

const NewTab = () => {
  //...
  console.log(t('hello', 'World')); // Hello, World ('World' is a substitution)

  return (
    <div>
      <header>
        {/*...*/}
        <Button onClick={exampleThemeStorage.toggle} theme={theme}>
          {t('toggleTheme')} // Toggle Theme
        </Button>
      </header>
    </div>
  );
};

How to check the feature

2024-07-27.11.28.03.mov

Reference

https://developer.chrome.com/docs/extensions/reference/api/i18n
https://developer.chrome.com/docs/extensions/how-to/ui/localization-message-formats#placeholders

[PatrykKuniczak]

1. pnpm script for generating, should be located in the root(I think good idea is create a pointing script, which run this nested(from i18n) script in root), like other scripts, because until now we was using only root package.json and magic happened in the subfolders :)
   I think this should work on the same way.
2. There's no function to change language in real time, i mean by user(switching between languages).
3. Move all 'build.' and 'generate ...' file into 'builders' folder(maybe it should be inside lib?)

After all it's amazing, because it works in all pages, if you want to implement it without turborepo/modules pattern, it's tricky to work properly in background because i was implementing it on legacy version on my project ;)

[PatrykKuniczak]

Suggested change

	${locales.map((locale) => ` case '${locale}':
	const {message} = await import('../locales/${locale}/messages.json').join("\n")
	if (message) {
	return message
	}else {
	throw new Error('Unsupported locale');
	}

That's pseudocode, what do you think about this?
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import

I think it's better to use dynamic import for that because of so many languages we have.
I know it's build file, but anyway, it could be smaller, each language is next switch case.
With my approach it's almost one liner.
If sb want to use 30 languages, have 30 cases and 30 imports.

[Jonghakseo]

When we use dynamic import, we have the constraint that the function must be called asynchronously.

However, the problem you suggest is reasonable and I'll have to think about it.

I'm currently maintaining a product in my company that supports 15 different languages, and each language file is about 500kB in size, so obviously the issue of optimizing for multiple languages and dynamic importing becomes very important at this scale.

But what if it's a Chrome extension, not a webpage, and the issue only occurs during the development phase...?
I guess it doesn't really matter. 🤔

[PatrykKuniczak]

It depends of the extension complexity, as you say.
This solution is good, but if you have better idea, try to implement it, sth more generic.

[PatrykKuniczak]

I looking for that, and my thoughts about it have destroyed xD

I think substitusion is placeholders.

PLS create more examples and explanation in README 🔥

[PatrykKuniczak]

OO there's some example, but as i type above, this should be also in README 😸

[Jonghakseo]

I thought I documented it well enough in the README.md in the i18n package, but what do you think?

[PatrykKuniczak]

I think, if you implement 'placeholder' filed in json, there's no need to create more clarification, but no it's a little tricky to use it 😆

[Jonghakseo]

1. pnpm script for generating, should be located in the root(I think good idea is create a pointing script, which run this nested(from i18n) script in root), like other scripts, because until now we was using only root package.json and magic happened in the subfolders :)
   I think this should work on the same way.
2. There's no function to change language in real time, i mean by user(switching between languages).
3. Move all 'build.' and 'generate ...' file into 'builders' folder(maybe it should be inside lib?)

1. I agree :)
2. The ability to change the language in real-time is not something that the Chrome extension's multilingual capabilities provide. There are already many great multilingual libraries that provide the ability to change the language at runtime. What we're focusing on here is a bit of support for how multilingualism is handled in Chrome extensions.
3. OK :)

After all it's amazing, because it works in all pages, if you want to implement it without turborepo/modules pattern, it's tricky to work properly in background because i was implementing it on legacy version on my project ;)

I didn't test the behavior in the background! I'll check the behavior, and it's true that it does rely on the behavior of Turborepo (more precisely on the watch function).

I thought it would be a good way to do it with less effort :)

[PatrykKuniczak]

@Jonghakseo It's working good in background in this version :)

2. Yeah, that's true, but i think it could be good feature, because users don't need to download other package only for switching language.

I was implementing language switching on my project some times ago.
https://github.com/PatrykKuniczak/YT_Notifier/blob/main/react-app/utils/hooks/use-language-switch.ts
https://github.com/PatrykKuniczak/YT_Notifier/blob/main/react-app/src/pages/popup/components/language-selector.tsx

I think if it will be build in, this could be good to our users, let's think about it a little 😸

[Jonghakseo]

1. pnpm script for generating, should be located in the root(I think good idea is create a pointing script, which run this nested(from i18n) script in root), like other scripts, because until now we was using only root package.json and magic happened in the subfolders :)
   I think this should work on the same way.
2. There's no function to change language in real time, i mean by user(switching between languages).
3. Move all 'build.' and 'generate ...' file into 'builders' folder(maybe it should be inside lib?)

1. I agree :)
2. The ability to change the language in real-time is not something that the Chrome extension's multilingual capabilities provide. There are already many great multilingual libraries that provide the ability to change the language at runtime. What we're focusing on here is a bit of support for how multilingualism is handled in Chrome extensions.
3. OK :)

After all it's amazing, because it works in all pages, if you want to implement it without turborepo/modules pattern, it's tricky to work properly in background because i was implementing it on legacy version on my project ;)

I didn't test the behavior in the background! I'll check the behavior, and it's true that it does rely on the behavior of Turborepo (more precisely on the watch function).

I thought it would be a good way to do it with less effort :)

I've been thinking about it again,

1. In my user experience, the only thing that will run commands related to the i18n package in the top-level path is `genenrate-i8n', which is already included in the build and ready commands, so I don't think there is any need to run it separately in the top-level path! 😄

2. There are a lot of things to think about for implementation... First of all, the multilingual capabilities of the Chrome extension are determined by the browser's language setting. If I change the language I want to use at runtime, I have to change to an implementation that doesn't rely on chrome.i18n API. Does that defeat the purpose of providing the convenience of using the chrome.i18n API? I'm not sure. 🫠

3. I've tried moving the build.~ and generate.~ files to builders or into libs, but it feels like unnecessary encapsulation that's hard to understand.

[PatrykKuniczak]

@Jonghakseo

1. Yeah, right
2. Yeaaah, that's true, i was thinking about users which want to change language for e.g 'english', but then they can change language for entire browser, and respectly plugin also have english. That's a point 😄
3. Ok, if it's complicating, that's ok to leave it in that shape.

[PatrykKuniczak]

@Jonghakseo Now users can define 'placeholder' prop in json?
Because i don't see any new examples.

[Jonghakseo]

I added example on README.md :)

252277e

[Jonghakseo]

@PatrykKuniczak I'm gonna merge this for now, and enahnce the documentation!