↓ Twitter is updated more often, so read it! ↓

Esperanto as the brower’s main language

2008 August 27 2048

A few days ago, I wrote at work a script which collected information useful to the developers when troubleshooting a customer’s experience on one of our sites. This script checked things such as browser version, operating system, Java existence and version, Flash existence and version, Javascript support, and CSS support. All of this information is either sent via the HTTP request headers or is determinable through interaction with the customer, asking if they can see any No items which should show Yes if the item is installed, enabled, and working.

One item I decided to include for the hell of it was language, through the HTTP request Accept-Language header. Tired of seeing the standard en-us displayed every time I loaded it, I decided to add Esperanto to the fore of the header. I did this by adding it in Firefox’s language options chooser in the Content option panel.

Lo and behold, the language code eo appeared before en-us on my script and I was happy. It was the end of the day, though, so I shutdown shortly thereafter and went home.

The next day, I was startled when the two sites I almost always open first, Google and Meebo, displayed text to me in Esperanto! I had totally forgotten that I had altered my Accept-Language header.

I haven’t changed it back. “Why?” a perplexed reader may ask. I continue to use Esperanto as my main browser language for a few reasons.

  1. Immersion. When a site appears in Esperanto, I’m forced to translate. I don’t let myself change it unless I am in a rush. So far, I have not changed it.
  2. Internationalization. I fancy myself a proponent of software i18n and l10n, so it is educational to me to see how other sites have performed their i18n. I assume that most use either gettext or defines, wherein every string is set in a file with a series of global constants.
  3. Obscurity. It keeps people off of my computer :-)

So, in there interests of determining the penetration of Esperanto as an internationalized and automatically-detected language for the web, I’ve compiled a list of sites which I often visit that have Esperanto strings shown when visiting with a browser which specifies that Esperanto is the preferred language.

  • Google (just search, from what I’ve seen)
  • Meebo (still missing a few strings, though)
  • Twitter (largely untranslated, though)

Some sites surprisingly lacked Esperanto internalization, but it’s not a problem: Esperanto was never meant to be anyone’s first language!

Some readers may be surprised that Wikipedia is omitted from these lists. Wikipedia does not internationalize its main page because all of the languages are listed as a links to the main page (cxefpagxo) of the language’s subdomain itself.

I’m neither surprised nor miffed that there number of sites that do have it are so few. As I stated previously, Esperanto isn’t meant to be anyone’s first language. It’s a quick, intermediary language. I assume that the aforementioned sites with Esperanto internationalization have someone one staff who speaks it fluently, and the translation process for it was effortless.

I hope to integrate i18n into a few projects I’m developing currently. By “hope”, I mean “will.”

Category: esperanto  |  4 Comments

The vital importance of being printable

2008 June 22 1722

The most recent change to my blog theme is one which most of my readers will never see. I added a print media CSS style sheet to all pages on the blog. Go on, try it. Use your browser’s “print preview” function to see it.

Rarely do folks actually print a post from someone’s blog. If it is a blog which does see some kind of readership with an unusual habit for printing articles, e.g. a blog about education which professors frequently print and distribute to their students, then the author or designer usually provides a “print preview” link or the printing user simply deals with the output, however many extraneous pages it may be.

However, accessing this printable version, that is, a version that prints without advertisements or colorful site paraphernalia, requires that the user click on a certain location, an extraneous action often neglected by visitors in a hurry.

This most recent change came about when I actually did have a reason to print one of my posts, and I realized that I wasted approximately five pages of paper just to get a small post. Now, I could have easily specified a page range when printing, but who does that? Users want to click print and have the article in hand.

I hate wasted paper, and most sites use some kind of div as a constricting container for the body text of the site. These containers often occupy less than the width of a page of paper, so the content fills only a portion of the paper, rather than letting the browser decide the width of the text on the printed page.

Print media style sheets remove this extra action and allow the designer of the site to decide how the printed output of a site should look.

The WordPress Codex’s Styling for Print article mentions five key element IDs which are generally a part of every theme:

  1. #header
  2. #content
  3. #comments
  4. #sidebar (or #menu)
  5. #footer

These elements, and their children, are the ones that need to be customized to give a WordPress blog a printable look.

One can append his or her new print style sheet to the bottom of style.css using the @media print{} enclosure, or editing header.php and adding a whole new line, like I did. I prefer to have a separate file for easier code maintenance.

The most key part of my print.css stylesheet is the part which hides elements which have little use in a printed copy of any page of my blog.

#sidebar, #headerad, .search, #hmenu, #content .navigation,
#footer, #respond, #commentform, embed {
    display:none;
}

This is a screenshot of my Blogger Health Insurance article so you can see my blog design even if you’re viewing this in a feed or on a mobile device.

Screenshot used in the printability article

I used Ubuntu’s built-in PDF printer to produce these two print-outs of the site: one with the print style sheet, and one without it.

Open both of those PDFs side-by-side and follow the comparison table with me.

Feature Without print styles With print styles
Blog title Ugly default font, takes up a large amount of space. Subtitle looks like regular text. Title is displayed in intended font and with “Printed from” appended to it to make it look more professional (but it’s only printed on browsers which support :before and :after on elements). Subtitle is present, but smaller and italicized in order to be relatively inconspicuous.
Major Navigation Displayed in bullet form, previous and next entries listed Hidden entirely, as there is no need for them on a printed copy of a single article.
Article title Smaller than the blog title, and in the same ugly, default font. Largest text on the page so that it demands the most attention and can be easily spotted when searching through multiple printed documents. Font is displayed as intended.
Body text Body text is in the same, ugly default font as the headlines and titles, so it’s not differentiated from them. The links are in blue and will print gray on a black and white printer, so they will be virtually unreadable several generations of copies later. The body text is of a font different from the titles and headlines, as is very attractive. The links are simply underlined and are in black, so they will be just as readable as the remainder of the text even after multiple generations of copies.
Block quotations The block quotation is merely indented on the left side. It is virtually indistinguishable from the rest of the text. The block quotation bears a simple gray bar to separate it from the rest of the text, as well as having forced, justified margins.
Article length All of the text is large, so the printer needs three pages to get the whole article, including the categories and tags. The text is smaller, but still very, very readable, so it requires half of the space: only a page and a half.
Comment box Shown. Hidden. It’s not needed in a print-out!
Sidebar Shown, and it takes approximately four pages to show it entirely. Hidden: it’s virtually not needed in a print-out. It’s purely navigational, save the Twitter feed. Even then, if the user needs to print out a Twitter status for some odd reason, he or she can click on the associated link and print the status from its twitter.com page.
Footer Shown, takes up an inch or two on the page. Hidden: it doesn’t contain any information useful in the article. I could (and really, should) have a copyright notice in the footer which is displayed on both the screen and the print version.



If you look at this post in Print Preview, you’ll see a message in the code block. My print format truncates after 80 characters (I think). While this is usually not a problem, since my code blocks are generally meant to be copied and pasted instead of typed, I decided to include a short message at the top for browsers which support :before on elements in CSS.

Designing a decent print style isn’t very difficult. That very simple design took me just short of an hour. That hour of time infinitely increased the readability of printed copies of my blog, and completely eliminates the need for any kind of “printer friendly” link within the article metadata. Visitors to my blog who are so compelled to share my articles via sneakernet and hard copy won’t have to waste paper or ink printing unnecessary parts of the site design and can focus on what they want the most: the article text.

Check out the Styling for Print article at the Codex for more information and tips. Also, check out my print style using Print Preview and tell me if it doesn’t work for you!

Category: design, wordpress, writing  |  2 Comments