> It seems that per-language font specifications need not be implemented wholesale, but could be instituted one language at a time.

That's correct. CSS provides enough means to implement per-language styles including custom fonts that will we downloaded on the fly (via '@font-face') and all modern (this is the keyword) browsers seem to provide adequate support for these features.

I've heard that font substitution add-ons exist for both Firefox and Chrome browsers though I've never used them.

> Could you please confirm that if I filter the viewed languages, the download time would be affected only by the viewed languages ?

I haven't investigated this question that close, but, according to some reports (sorry, I haven't an URL at hand), Firefox and Chrome browsers won't download any font defined in CSS via '@font-face' unless they found a reference to it (explicitly via 'style' attribute or implicitly or via 'class' attribute) inside the page HTML code. That is, if you filter all unnecessary languages, the fonts for them won't be downloaded either. On the other hand, according to the same reports, other browsers, IE in particular, seem to download all fonts defined in CSS no matter if they used on the page or not.

> How can the CSS "guess" what language it's processing ?

This is possible via 'lang' attribute. Tatoeba already has information about the sentence language so each sentence may be provided with appropriate 'lang' attribute. There's also 'lang' selector in CSS so it's possible to select and set different styles for different languages.

---- About fonts on Tatoeba ----

From my personal experience, there's still no ultimate solution for multilingual sites that would provide an acceptable level of usability while staying lightweight and effective. That is, any solution we can invent at the moment will be a compromise solution somehow or other. I see several approaches and each of them has its own pros and contras.
1) Remove all 'font-family' specifications from Tatoeba CSS files.
Extremely straightforward solution. The whole site will be displayed using default proportional font specified in browser configuration. This may cause a disruption of Tatoeba visual design depending on particular font selection. To decrease the impact of this it's possible to work out a set of recommendations for Tatoeba users about their browsers customization, font getting and installing processes, etc. We also can count that many users already have their browsers and OSes optimized for different languages though it may seem like catching at a straw.
2) Use only 'serif' and 'sans-serif' in 'font-family' specifications.
This solution is almost the same as the one above but allows to use different typesets and potentially more design style friendly.
3) Use the most “Web safe” fonts, such as Arial / Helvetica for sans-serif and Times New Roman / Times for sans providing fallbacks to sans-serif and serif typesets accordingly.
This solution allows to count on particular font's look and feel but the result will be highly dependent on user OS type and localization since different versions of fonts may have different number of character sets and glyphs supported. But, apparently, for many localizations this solution will degenerate to the one above.
4) Implement 'lang' property support in CSS and provide different font-family for different languages. For the most complex/exotic cases provide optimized fonts via '@font-face' CSS directive.
Maybe the most elegant solution but requires a good deal of work that will include reworking Tatoeba engine, collecting information about best practices in font selection for different languages, investigating the font availability in different OSes and localizations, getting and optimizing free national fonts, etc. Another drawback is that usage of custom fonts may dramatically increase page download time.

I suspect that the truth is somewhere in the middle but hope my considerations will help. :-)

Thanks for pointing out, sysko! I suspected that something is wrong :-)
Unfortunately, it seems that there's no separate HTML entity for Narrow No-Break Space so we have to use its HTML code instead ( ) and pray that browser display it right.
I've updated the test page.
http://jplangtools.com/tatoeba/thinspace.html

> You are using justified text, aren't you?

ummm, nope, no justified alignment is used. English example just contains different type of spaces. :-)

Calibri seems to look nice though I prefer Arial.
I've added Calibri to the page. (maybe it worth writing some script that changes fonts on the fly since the page gets too long. :-))

Will this test page help?
http://jplangtools.com/tatoeba/fonts.html

> Can you tell if Tatoeba's thinspaces are really thinspaces or the narrow-no-break-spaces they really ought to be?

Absolutely not. To tell the truth, I don't really care if some space is thin or not-so-thin or if some dash is long or not-so-long. It doesn't prevent me from understanding the sentence. :-)

Isn't it strange? :-)

This is the page that demonstrates Uyghur sentence rendered using different fonts:
http://jplangtools.com/tatoeba/national.html
UKIJ fonts are being uploaded via CSS on the fly and the other fonts are those the OS contains. There are also "sans" and "sans-serif" lines included so one can see what font his browser actually uses to display those typesets.

Charis SIL font is really great but it's too big in size to be downloaded on-the-fly via CSS. So one have to install it manually and this may be a problem.

As for my Chrome on Windows 7, Hebrew sentences looks like this:
http://dl.dropbox.com/u/42772287/Hebrew.png
The same is with Arabic.
What a mess! :-)

Nice page, by the way!
I've made a test page based on it.
http://jplangtools.com/tatoeba/spaces.html

> It would also be nice to right-align languages that are read right-to-left, but that's probably asking for too much, eh?

Actually, in Gecko-based browsers (Firefox, Seamonkey, etc.) RTL sentences are displayed right-aligned. But it seems this doesn't work for Chrome for some reason.

It's possible that a localization of particular OS version also matters. And, possibly, the service packs installed, too.

hmmm... actually, W3C did its best at providing various types of HTML entities (see http://www.w3schools.com/tags/ref_symbols.asp ) but all that stuff is more for the coders, not for the end users. Older operating systems seems to have limited support for Unicode and, unfortunately, W3C can't help it.

Browsers running on Windows 7 OS seem to work like a charm. My Dolphin brobser (WebKit based) that runs on my Adndroid 4 device displays 1,2 and 4 lines correctly, too.

Now I clearly see that the problem is more complex than it seemed. We have to take into account not only the browser type but also the operating system type and version.
The most universal solution is to use HTML entities instead of Unicode symbols. The problem is that this requires on the fly conversion inside the Tatoeba engine.

Please take a look at this test page:
http://jplangtools.com/tatoeba/thinspace.html
What do you see in your browsers?

You're absolutely right. But we can't and we shouldn't rely upon browser font configuration, neither default not user made. Default configurations may be not optimal (read "ugly") and a user may have no idea how to change it (and, actually, many if not the most of users just don't suspect that font configuration exists). That is, talking about Tatoeba, it's necessary to determine what font family is best to display this or that alphabet and explicitly instruct browsers through CSS to use it.