Closed Bug 776905 Opened 12 years ago Closed 12 years ago

Use complete Open Sans Light font for eastern-Europe languages

Categories

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

Product:
www.mozilla.org
Component:
L10N
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
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.
I'm not sure what's the smarter way of including it only for some locales.

Steven, Craig: What's your take on this?
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.
I prefer option A, with fonts-*. That way it would be easy to implement and only 2 more css files for us.

Anthony?
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?
Whiteboard: [sb-sprint-1]
Assignee: nobody → anthony
Whiteboard: [sb-sprint-1] → [sb-sprint-1] u=user c=L10N p=2
Whiteboard: [sb-sprint-1] u=user c=L10N p=2 → [sb-sprint-2] u=user c=L10N p=2
Another site with similar problem https://mozillians.org/pl/group/356-aviarypl
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.
Whiteboard: [sb-sprint-2] u=user c=L10N p=2 → [sb-sprint-3] u=user c=L10N p=2
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
Assignee: anthony → nobody
Component: General → L10N
Apologies, when i moved these i must have set the default assignee. I will fix on all of these.
Assignee: nobody → anthony
Target Milestone: --- → Future
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!
+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.
Similar bug about new SUMO design: Bug 785707
mozillians is also affected, actually I think all mozilla websites should use a font hosted in a single location on mozilla.org
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.
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.
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?
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).
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.
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?
Craig & Steven:

Can you let me know the correct value for the Access-Control-Allow-Origin header?

I can then follow up with IT.
(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.
Depends on: 790806
Blocks: 770362
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)
Steven... assigning this to you as you filed the pull request.

He who pulls owns... or something like that.
Assignee: anthony → steven
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
This is in production.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
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
(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.
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.