Closed Bug 754287 Opened 12 years ago Closed 12 years ago

Open Sans fonts in Sandstone theme does not cover non-English locales

Categories

(www.mozilla.org :: General, defect)

defect
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: pascalc, Assigned: sgarrity)

References

Details

(Whiteboard: r=105512 b=trunk)

The translation of the partners page exposes the bug that we only have ascii letters in our Open Sans @fontface rule:
https://www-dev.allizom.org/b/fr/apps/partners/

We need the font to cover more languages (latin extended and cyrillic at least).

Thanks
A non-subsetted version of the font (with all available characters) is available, but significantly larger. The file sizes vary with variant and format, but a typical example would be the Open Sans Light EOT format:

English subset: 20Kb
All characters: 108Kb

Pascal, do you think we should just use the non-subsetted font for everyone (simpler, but a download-size hit for everyone), or try to serve a different font based on locale?
I think we should vary per locale, a first step could be to serve the English only subset for en-US and the full set for locales, this would allow to add a per locale logic to the code. Then we can refine with sets of locales (for example western european locales wouldn't need to have cyrillic or arabic sets included).
Note that this is hindering localization of new pages on mozilla.org since all new pages use this font and we need to push at least new pt-BR pages in June, it would be good to have that bug fixed as soon as possible. Thanks
Severity: normal → critical
Pascal, I've got a non-subsetted version of the Open Sans font files in a github branch:

https://github.com/sgarrity/bedrock/compare/bug-754287-opensans

Any suggestions on how to implement the locale detection / varying?
On the php site, I would just create arrays with locales and in the template include different fonts depending on the page's locale. I don't understand enough Python (and even less the django/paydoh/bedrock stack) to give technical suggestions though, so I would say that the implementation details are in your and the webdev team hands, sorry.
Pascal, I've updated this branch with the MacRoman subset of characters from Font Squirrel (http://www.fontsquirrel.com/fonts/open-sans). Can you confirm that this gives you what you need?:

https://github.com/sgarrity/bedrock/compare/bug-754287-opensans
Steven, is it possible to test your branch without doing a full reinstall from your github branch?
(In reply to Pascal Chevrel:pascalc from comment #7)
> Steven, is it possible to test your branch without doing a full reinstall
> from your github branch?

It might easiest to just drop in the fonts in your local copy. I've put them in a zip here: http://labs.silverorange.com/files/mozilla/fonts.zip

They go in /media/fonts/
Thanks Steven, I tried Spanish, Portuguese and French pages with these updated fonts and they all display correctly now. I think we should keep this bug open because we have many locales to test (especially those using cyrilluc or Asian scripts), but this is no longer blocking our apps/partners page localization for June.
No longer blocks: 752692
The western languages subset is now in Master and will go into production with the next push (probably tomorrow).
Also updated the Open Sans font in the PHP site in trunk (r105512).
Whiteboard: r=105512 b=trunk
Pascal can you verify if fixed. The last two comments have this in production (im resolving, reopen if still an issue.)
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
This is no longer a blocker for most languages (particularily for Spanish and Portuguese for which we have a special focus), I have a separate bug open to cover eastern European languages (bug 776905) in which we will use the solution mentioned in this bug in comment #2, the two bugs are similar but let's keep this one closed yes
Status: RESOLVED → VERIFIED
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.