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

How to Implement Web fonts for a specific language for a specific locale #427

Closed
miminari opened this issue Apr 8, 2024 · 3 comments · Fixed by WordPress/wporg-mu-plugins#630
Labels
i18n Translations, RTL issues

Comments

@miminari
Copy link
Member

miminari commented Apr 8, 2024

related #266

Regarding design coordination with Japanese members, we would like to implement Japanese web fonts, as we cannot reproduce them with the fonts currently used on the site.

We need "Noto Serif JP" ( https://fonts.google.com/noto/specimen/Noto+Serif+JP ) weights 400, 600 (regular, semibold),
but, you know, Japanese font data is huge so that we might need the subset data.
If we can, I believe it's better way to use the dynamic subsetting.

Then, I would like to discuss with you what methods are realistic and possible.

I don't think Google's dynamic subsetting (or API) is available.
So, as for Japanese only, since Noto Serif JP has subset data prepared by individuals, I'm thinking of possibility using that as an alternative.
https://github.com/ixkaito/NotoSerifJP-subset

Thanks!

mentioned @nukaga , @t-hamano

@renintw
Copy link
Contributor

renintw commented Apr 8, 2024

We do have the font-subsetting mechanism in wporg-mu-plugins, but I wonder whether that's the best place to add a specific font for a locale.
@ryelle What did we usually do for a case like this? Does it make sense to use the font manager to add a font? This likely doesn't include dynamic loading, though.

@ryelle ryelle added the i18n Translations, RTL issues label Apr 8, 2024
@ryelle
Copy link
Contributor

ryelle commented Apr 8, 2024

I'm inclined to try adding this font to wporg-mu-plugins, since the Rosetta sites are .org sites, and this would keep the way we use fonts consistent.

We don't have dynamic subsetting available, and I'm not sure about re-subsetting the fonts— they seem packaged this way intentionally (the font-subset script would need to be updated to support CJK, too).

@miminari How is the font subset you've suggested different from what's on google? I assume it still needs to include the kanji character data, do you know how it's able to reduce the size so much?

@miminari
Copy link
Member Author

miminari commented Apr 9, 2024

@ryelle Hi! At first, this subset was created by @ixkaito, who is also a WordPress contributor. He may be able to explain it more correctly, so I will try to mention him.

I understand that Japanese includes many characters that are not often used in daily life, so the subset excludes them (they are categorized as JIS Level 1 Kanji, JIS Level 2 Kanji... It is up to the 4th, I believe).

Now that Google's API offers a similar, more lightweight method (not dynamic), I suggest using this library as an alternative when Google's way is unavailable in some projects, like now.

He may suggest a better way again, but this is what I know now.
(He is super busy right now so he may not reply.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
i18n Translations, RTL issues
3 participants