Closed
Bug 776905
Opened 13 years ago
Closed 12 years ago
Use complete Open Sans Light font for eastern-Europe languages
Categories
(www.mozilla.org :: L10N, defect)
www.mozilla.org
L10N
Tracking
(Not tracked)
VERIFIED
FIXED
Future
People
(Reporter: pascalc, Assigned: sgarrity)
References
Details
(Whiteboard: [sb-sprint-3] u=user c=L10N p=2)
The variant of Open Sans Light we use on the site only contains characters for western European languages (English, French, Spanish German...).
Eastern European languages such as Polish, Russian, Czech, Slovak, Slovenian... get letters with a mix of Open Sans Light and the default sans-serif font on their computer.
ex:
http://www.mozilla.org/pl/firefox/14.0.1/whatsnew
For that same page we did an exception for Russian which does include the full Open Sans Light font:
http://www.mozilla.org/ru/firefox/14.0.1/whatsnew
(https://github.com/mozilla/bedrock/pull/263/files)
In the short term, I'd like this font to be defined in the base CSS for a set of Eastern European locales, which should solve the display problem for these locales.
That means including a separate font in the base css for all pages for a list of locales (as we did for Russian on the whatsnew page) and removing the specific Russian rule on the whatsnew page.
Comment 2•13 years ago
|
||
I'm not sure what's the smarter way of including it only for some locales.
Steven, Craig: What's your take on this?
Assignee | ||
Comment 4•13 years ago
|
||
I'm not sure, the only options I can imagine would be:
A. Pull the @font-face calls into a stand-alone CSS file (which means an additional HTTP request) and have the template pull a locale-specific version of this fonts CSS file (fonts-ru.css, fonts-pl.ru, etc., or even fonts-western.css, fonts-eastern.css, etc.).
B. Do something dynamic on the server-side where a single URL serves a different font file depending on headers of the requesting client.
Comment 5•13 years ago
|
||
I prefer option A, with fonts-*. That way it would be easy to implement and only 2 more css files for us.
Anthony?
Comment 6•13 years ago
|
||
Actually, I just remembered that font-face supports a unicode-range and that could save us. Sadly, Firefox does not support this attribute… bug 475891
To keep in my mind: Non international ~20KB each, International ~60KB each.
Option A:
We could include the font-face inline to save one HTTP request. We should test this to see if such an implementation downloads only one font (intl) or two (non-intl + intl). And in different browsers.
Option B:
That's not how our L10N system works. If someone sends en-US headers but is visiting the /pl/ website, we should serve the intl version of the font. That could be implemented too.
Option C:
We could serve all users the intl version. That's suboptimal but easy to implement.
Pascal, Milos: In any case, we'll need a list of locales that should receive the intl version of the font. Can you provide this?
Updated•13 years ago
|
Whiteboard: [sb-sprint-1]
Updated•13 years ago
|
Assignee: nobody → anthony
Whiteboard: [sb-sprint-1] → [sb-sprint-1] u=user c=L10N p=2
Updated•13 years ago
|
Whiteboard: [sb-sprint-1] u=user c=L10N p=2 → [sb-sprint-2] u=user c=L10N p=2
Comment 8•13 years ago
|
||
Another site with similar problem https://mozillians.org/pl/group/356-aviarypl
Comment 9•13 years ago
|
||
I think we should proceed with option B. serving the correct font based on URL. I like this approach as we are not sending data that is not needed. I would want to be careful here, we want to make sure language specific features are centralized as much as possible, maybe completely outside the templates.
However if for some reason this is not practical, I think as a (quite good) backup we should go with option C serve the complete font to all users. 60kb is indeed larger, however it is one request and is cached.
Updated•12 years ago
|
Whiteboard: [sb-sprint-2] u=user c=L10N p=2 → [sb-sprint-3] u=user c=L10N p=2
Updated•12 years ago
|
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
Updated•12 years ago
|
Assignee: anthony → nobody
Component: General → L10N
Comment 10•12 years ago
|
||
Apologies, when i moved these i must have set the default assignee. I will fix on all of these.
Assignee: nobody → anthony
Updated•12 years ago
|
Target Milestone: --- → Future
Comment 11•12 years ago
|
||
Hey all,
This resurfaced again in the form of questions/concerns at Mozcamp EU, so I think we should get a fix in place.
So the page designs aren't broken for our European communities, could we go ahead and remove any usage of the stripped down Open Sans and use the larger full map default until a filtering solution is built?
If we could get that done it'd be great to see that change go live asap.
Thanks!
Reporter | ||
Comment 12•12 years ago
|
||
+1 on using the full font for now so as to be able to serve our pages in all languages without worrying about the end result.
Comment 13•12 years ago
|
||
Similar bug about new SUMO design: Bug 785707
Reporter | ||
Comment 14•12 years ago
|
||
mozillians is also affected, actually I think all mozilla websites should use a font hosted in a single location on mozilla.org
Comment 15•12 years ago
|
||
Some of this is also tied to Tabzilla. The copy of the font that Tabzilla references is subsetted for western languages. Depending on where its tabzilla.css appears in the cascade order, Tabzilla's definition of the "Open Sans" font-family name may be the one in use when that name appears elsewhere on your site, even if you've referenced the unsubsetted font on your own style sheet. You may be using the western subset from Tabzilla when the page is rendered, whether you like it or not.
One workaround is to define a different family name, but then you end up downloading multiple font files; one for Tabzilla, one for the rest of the site. That's an even heavier hit than one unsubsetted font. It would be better if Tabzilla referenced the same, canonical, unsubsetted version of the font. We'll probably have to do that anyway to make Tabzilla properly localizable.
Reporter | ||
Comment 16•12 years ago
|
||
tabzilla is hosted on the old PHP site for mozilla.org, there are plans to move tabzilla to the new python version of the site which would use the full open sans font. Even if we keep tabzilla for while on the php site, we can still updated the font it references to support all locales, that seems indeed to me a better approach than downloading the font twice.
Comment 17•12 years ago
|
||
OK here's my recommendation based on the above.
1. Use full open sans font on bedrock
2. Use full open sans font in tabzilla
3. Reference exaxt same font files in tabzilla and bedrock
The full files should reside in bedrock (/media/fonts) and we will reference these in tabzilla both now & in the future when tabzilla moves to bedrock.
If we reference the same files the browser (AFAIK) would not double load the fonts. For other sites, yeah its up to them to make sure they do not override our full font with a subset.
Any disagreements to the above?
Reporter | ||
Comment 18•12 years ago
|
||
this proposal sounds good to me, we should also make sure that all mozilla sites use the font hosted on mozilla.org (mozillians.org for example also has that same font problem).
Comment 19•12 years ago
|
||
We'll need to make sure the bedrock servers are sending the right Access-Control-Allow-Origin header so the font can be loaded by other domains. We've run into that before, and as of a few months ago bedrock wasn't sending the header but the PHP site was. The bedrock servers may have been updated since then but we'll have to be sure to test it when we change Tabzilla.
Assignee | ||
Comment 20•12 years ago
|
||
Here's a pull request replacing the open-sans font with the full character set version:
https://github.com/mozilla/bedrock/pull/356
(In reply to Craig Cook (:craigcook) from comment #19)
> We'll need to make sure the bedrock servers are sending the right
> Access-Control-Allow-Origin header so the font can be loaded by other
> domains.
Right you are, sir. Anyone know where/how that is managed? .htaccess?
Comment 21•12 years ago
|
||
Craig & Steven:
Can you let me know the correct value for the Access-Control-Allow-Origin header?
I can then follow up with IT.
Comment 22•12 years ago
|
||
(In reply to Ben (:bensternthal) from comment #21)
> Can you let me know the correct value for the Access-Control-Allow-Origin
> header?
The headers are managed in either Apache's config or in htaccess. See https://developer.mozilla.org/en-US/docs/HTTP_access_control
The value can be a wildcard (*) that will allow files to be fetched from any domain, or it can be a comma-separated list of allowed domains. We'd have lots of domains to list, and I'm not sure if subdomains have to be listed separately (and we've got dozens of subdomains) so the wildcard would probably be the easiest.
But I believe there could be security issues with a global wildcard for the whole server. I think we should be able to send the header for specific file types, or maybe only for the fonts directory and not for the entire site. But now I'm at the limit of my knowledge so I could be wrong, and I'll happily defer to someone who knows what they're talking about.
Comment 23•12 years ago
|
||
Commits pushed to master at https://github.com/mozilla/bedrock
https://github.com/mozilla/bedrock/commit/efcb8adf860e9c58ea665b4f9f14dc658040094f
Use full-character set version of Open Sans font (Bug 776905)
https://github.com/mozilla/bedrock/commit/a8fb332e75a34b01269f6dd32330a5d7c05787de
Merge pull request #356 from sgarrity/bug-776905-fonts
Use full-character set version of Open Sans font (Bug 776905)
Comment 24•12 years ago
|
||
Steven... assigning this to you as you filed the pull request.
He who pulls owns... or something like that.
Assignee: anthony → steven
Comment 25•12 years ago
|
||
Removed the dependency here on Access-Control-Allow-Origin, that should be a blocker for tabzilla but not for this specific task.
Feel free to kick this out the door when you are comfortable with it.
No longer depends on: 790806
Assignee | ||
Comment 26•12 years ago
|
||
This is in production.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment 27•12 years ago
|
||
Verified on prod.
Full fonts being loaded (looked at filesize in firebug)
Confirmed no wonky characters appearing on pascals test page
http://www.mozilla.org/pl/firefox/14.0.1/whatsnew
Thanks all for the effort.
Status: RESOLVED → VERIFIED
Comment 28•12 years ago
|
||
(In reply to Ben (:bensternthal) from comment #25)
> Removed the dependency here on Access-Control-Allow-Origin, that should be a
> blocker for tabzilla but not for this specific task.
Is there a bug for this? Can we allow *.mozilla.org at least? We want to use the fonts on SUMO like right now or ASAP.
Comment 29•12 years ago
|
||
Ricky -> we are tracking this here:
https://bugzilla.mozilla.org/show_bug.cgi?id=790806
I did not know you had an immediate need for this. I'll update that bug and add you as a cc.
You need to log in
before you can comment on or make changes to this bug.
Description
•