Tag: html

Basic Bilingual 0.3 for Multilingual Blogging [en]

[fr] Une mise à jour de mon plugin "Basic Bilingual" qui permet de rendre WordPress bilingue. Modification majeure: il n'y a plus besoin de bidouiller son template pour faire apparaître l'extrait du billet dans "l'autre langue". Par contre, c'est toujours nécessaire pour rajouter les attributs lang.

Long overdue, an upgrade of my plugin Basic Bilingual. Grab the [tgz archive](/code/basic-bilingual.tgz) or [check out the code](/code/basic-bilingual.phps).

Some explanations. First, you all know of my [long-standing interest in all things multilingual](/focus/multilingual) and in [multilingual blogging](http://climbtothestars.org/archives/2007/03/25/blogcamp-multilingual-blogging-session/) in particular.

Years ago, I switched to [Movable Type](http://climbtothestars.org/archives/2004/01/03/switch-to-movable-type/) and then to [Wordpress](http://climbtothestars.org/archives/2004/06/23/switch-to-wordpress/) because I was blogging in two languages. Movable Type allowed me to assign more than one category to each post — so I used two huge categories, fr and en, to indicate what language I was blogging in. This soon made the rebuilds a real pain in the neck, and WordPress allowed me first of all to [happily hack it into being multilingual](http://climbtothestars.org/archives/2004/07/11/multilingual-weblog/), and then actually [write a plugin to do it in a cleaner way](http://climbtothestars.org/archives/2005/01/23/basic-bilingual-plugin/). The plugin hasn’t changed much since, and this upgrade isn’t a major one, but it’s a step in the right direction.

Ideally, I’d like people to be able to use the plugin without having to modify their templates at all. I’d also like the plugin to allow filtering out one language if that is what the reader desires. I still hope that [Wordpress will one day “see the light” and let us define language at post-level](http://wordpress.org/extend/ideas/topic.php?id=1007 “Please vote!”) (Matt [saw the light for tagging](http://climbtothestars.org/archives/2007/09/22/wordpress-finally-has-tags/) ;-), so I do have hope). By the way, I stumbled upon this [Ajax Language Switcher for Basic Bilingual](http://www.freshlabs.de/journal/archives/2006/05/ajax-language-switcher-for-basic-bilingual/) earlier today, and it will probably greatly interest those courageous ones of you who tend to have translations of each post or page.

Back to the plugin. It installs normally (unzip everything in the /plugins directory). If you’re using other languages than French and English, you’ll have to manually change the language codes in the plugin file (not very difficult, you don’t have to know PHP to do it; just look for “en” and “fr” and put the language codes for your languages instead).

I’ve fixed an annoying problem with slashes that popped up at some point (somebody else gave me the fix, but I can’t remember who — let me know!).

But most of all, I’ve made the “other language excerpt” appear automatically in the post content. Yes, you hear me: no need to add <php bb_the_other_excerpt(); ?> in your templates anymore. Yay! Added bonus: it will show up in the feeds, too — for that reason, I’ve added a text separator between the excerpt and the post so that there is a separation between the languages.

Basic Bilingual in Google Reader

Obviously, you’ll want to hide these separators and style your posts a little. Here is roughly what I’m using right now:

.other-excerpt {
font-style: italic;
background: #fff;
padding-left: 1em;
padding-right: 1em;
border: 1px solid #ccc;
}

.other-excerpt:lang(fr) p.oe-first-child:before {
content: “[fr] “;
font-weight: bold;
}

.other-excerpt:lang(en) p.oe-first-child:before {
content: “[en] “;
font-weight: bold;
}

.bb-post-separator {
display: none;
}

div.hentry:lang(fr) .entry-title:after {
content: ” [fr] “;
vertical-align: middle;
font-size: 80%;
color: #bbb;
}

div.hentry:lang(en) .entry-title:after {
content: ” [en] “;
vertical-align: middle;
font-size: 80%;
color: #bbb;
}

Now, notice there is fancy stuff in there which relies on the lang attribute. If you’re mixing languages on a page, you should [use the lang attribute](http://www.w3.org/TR/html401/struct/dirlang.html#h-8.1) to indicate which language is where. This means (unfortunately, until I become buddies with PHP’s ob_start() function) that you need to touch your template. It’s not that hard, though.

Find the outermost <div> for each post in the template (it [should have the CSS class hentry, by now](http://microformats.org/wiki/hatom#Entry)). Add this inside the tag: lang="<?php bb_the_language(); ?>". Do so on every theme template which produces posts. With [the Sandbox theme](http://www.plaintxt.org/themes/sandbox/), it would look like this:

<div id="post-” class=”” lang=””>

That’s it!

If you’re using this plugin, please leave a link to your blog. I’m also always interested in hearing of other examples of multilingual blogging or multilingualism online.

Similar Posts:

Jeremy Keith: The Beauty in Standards and Accessibility (Web2.0Expo, Berlin) [en]

*Here are my notes of [Jeremy Keith](http://adactio.com/journal/)’s session. He’s somebody I always appreciate listening to, and he also happens to be the creator (and provider) of [Buzzword Bingo](http://bingo.adactio.com/). Play with your neighbour when keynotes or sessions go down the buzzword path.*

*My notes are as correct as I can make them, but they may be missing bits and pieces and I might even have misunderstood stuff.*

Web 2.0 Expo 6 - Jeremy Keith

First define. Who knows about beauty? The poets.

John Keats: Ode on a Grecian Urn. “Beauty is truth, truth beauty, that is all ye know on earth, and all ye need to know.”

William Blake: Auguries of Innocence. “To see a world in a grain of sand, and heaven in a wildflower, hold infinity in the palm of your hand, and eternity in an hour.”

Looking deep beneath the surface. Close-up sketch of a flea. Micrographia. Beautiful. Viewing source. This is how we see the beauty of things.

This whole web2.0 stuff is not about details. We’re not using microscopes, but telescopes, looking at the “big picture”. Telescopes can be good: think “Galileo”.

He brought upon the world an *a priori* change. A new way of looking at the world, though the world had not changed. The earth revolves around the sun, and not the opposite.

Darwin: the world didn’t change from one day to the next when The Origin of Species was published, but our view of the world did.

We want to think about structure. How is the house built? It’s when you understand the structure that you can build solid houses. Same with web pages. This is where web standards come in.

Separation. Before: all mixed up (html, css, js). Now: separate. (cf. http://nataliejost.com) Progressive enhancement. An a priori change to how you design websites.

a) begin with your content
b) structure it (HTML)
c) think about how it’s going to look (CSS)
d) think about the behaviour (DOM Scripting)

Web 2.0 Expo 5

If you remove any of these layers, it will still work. It won’t look pretty, it won’t behave as well, but it will still “work”.

**CSS**

# in a separate document!
p { }
#foo { }

Then, add rules using selectors. From general to specific.

**DOM**

Very similar approach. Make it external. You don’t put it in the document. The vocabulary is different, but you also reference elements in the page pretty easily

document.getElementsByTagName(“p”)
documnet.getElementById(“foo”)

School of thought called “unobtrusive scripting”, “unobtrusive javascript”

**Beware**

First structure, then presentation. If you catch yourself doing this…

# wrong!

If you put behaviour in here, you’ve wasted a hyperlink.

Slightly better… but still bad

# JS equivalent of using the style attribute

*steph-note: I’m learning stuff about JS! yay!*

Bandwidth benefits in doing things the right way. Process benefits, you can separate the work. And also… the beauty of it. Flexibility. See how it reacts in situations you haven’t accounted for? It won’t fall apart if somebody accesses with no CSS, no JS, no images…

So, is this about making site accessible? Kind of. Note: go to the talk on accessibility Thursday morning.

Jeremy is talking more about universality. You’re not shutting out devices. Mobile. Search bots. Screen readers.

W.B. Yeats (April 1916) “All is changed, changed utterly: A terrible beauty is born.”

**Ajax**

Wonderful, beautiful, but can be terrible depending on how it’s used. *steph-note: reminds me of what we said of JS in 99-00*

The key to Ajax is about asynchronous communication with the server. XmlHttpRequest.

Jeremy’s definition: “A way of communicating with the server without refreshing the whole page.” Just part of the page.

Buzzword Hijax.

Here is how Jeremy thinks we should build an ajax application.

a) build a website in the old-fashioned way — buttons, links, for interaction with the server
b) then, come along with ajax — which parts of this page benefit from just being refreshed separately, and intercept the links/events. Hijack the requests. Bypass the whole page interaction.

Progressive enhancement rather than a terrible beauty that locks people out. Switch off JS, and everything still works.

Where? When?

Patterns: when I click a link/form, and when I submit it, I return to the same page with almost nothing changed.

– registration forms (specially for user name availability)
– comments on a blog/forum
– add to cart
– *steph-note: sign in links*

“Web 2.0” is not about web applications versus documents in the old “Web 2.0”. It’s a sliding scale. Most sites are somewhere in between documents and application. Applications work with documents! It’s not an either… or thing.

This kind of Ajax is more on the document side of the scale, roughly mid-way to the application end. Doesn’t scale to “more application”.

But at that point, why the hell are you building that with HTML, CSS and JS? The reason to use them is that they degrade gracefully. If you decide that all three are required, maybe you need to use another technology, like Flash. These technologies have their place for applications which cannot degrade gracefully. Flash is made for building web applications! But there is an insistance in building “2.0 Apps” in HTML/CSS/JS.

Maybe hesitancy because Flash isn’t a standard in the same way as HTML/CSS/JS?

Standards: you know your stuff will work, you know there’ll be support there. The best thing that Adobe could ever do in Jeremy’s opinion is to open it up truly (*steph-note: if I understood that correctly*).

History of standards.

ISO, ECMA, W3C…

Open data. API. RSS. XHTML.

If you’re going to release and API, look at what Google and Yahoo are doing and copy. Build upon existing conventions. Your own format is not going to make it.

If you allow people to access your data like that, you start to see emerging patterns.

Microformats! *steph-note: yay!*

Machine tags! *steph-note: yay again!* There is a [machine tags wiki](http://machinetags.org/wiki/Main_Page).

Jeremy, like many of us, really hates the “Web 2.0” label/buzzword. It had its place a few years ago, but now it’s really putting us in a box. Ajax is a good buzzword, because it allows to talk about a certain technology in a snappy way. Whereas Web2.0… ask ten people, and you’ll get 10 explanations.

Web2.0: people.

But we don’t need a buzzword for that. We already have a word for “leveraging collective intelligence”: the WEB!

Combine looking through the microscope and looking through the telescope.

Similar Posts:

Quelques balises HTML pour blogueurs [fr]

[en] A few HTML tags for bloggers. Don't use the visual editor is my recommendation. It sometimes creates hairy problems.

Je recommande en général de ne pas utiliser “l’éditeur visuel” lorsqu’on écrit des billets dans WordPress. L’éditeur visuel vous montre directement, dans le texte que vous écrivez, le gras en gras, les listes sous forme de liste avec des petits points devant, les liens en bleu souligné, etc. Malheureusement les éditeurs visuels sont imparfaits et génèrent souvent plus de problèmes qu’ils n’en résolvent.

Pour désactiver l’éditeur visuel, allez sous “Users/Utilisateurs” et puis sous “Your Profile/Votre Profil”. Tout en bas de cette page, il y a une case à cocher. Vérifiez qu’elle soit décochée, et mettez à jour les réglages.

Votre éditeur de billets est maintenant décoré d’une rangée de boutons un peu différente d’avant: sélectionnez du texte, cliquez sur le bouton approprié, et des caractères étranges apparaîtront de part et d’autre du texte que vous aviez sélectionné. C’est du HTML. HTML?! Pas de panique, c’est [pas si compliqué](http://old.climbtothestars.org/coding/html/ “Un guide pour débutant en anglais.”). Voici ce que vous avez besoin de savoir:

– le HTML, c’est en fait des petits “codes secrets” qui disent au navigateur de formatter d’une façon particulière le texte qu’ils entourent (par exemple: mettre en gras, faire une liste, faire un paragraphe, faire un lien).
– ces codes secrets se nomment “balises”. Les balises vont toujours par deux: une qui ouvre, une qui ferme.

Exemple:

du texte mis en italiques (emphasis)

Ce qui est entre parenthèses angulaires < et > ne va pas s’afficher dans votre texte. Ce sont juste des indications que va interpréter le navigateur web. En l’occurence, il mettra le texte ci-dessus en italiques.

Voici quelques balises que vous rencontrerez en utilisant les boutons de WordPress:

– <em> ... </em> met le texte qu’elles délimitent en italiques
– <strong> ... </strong> en gras
– <a href="http://quelquechose.com"> ... </a> crée un lien qui nous enverra sur http://quelquechose.com si on clique dessus
– <ul> ... </ul>, <ol> ... </ol> et <li> ... </li> sont utilisés pour faire des listes (explications ultérieures).

Similar Posts:

Delicious! A Great Bookmarks Manager [en]

Delicious is an online bookmark manager. It makes it very easy to add and categorize bookmarks, as well as share them with other users. You can also extract your bookmarks from delicious and integrate them in your blog to create a linklog. When I say ‘easy’, I really mean it!

Now, why on earth didn’t I start using delicious ages ago, when I first stumbled upon it? Maybe it didn’t look pretty enough, and didn’t flaunt its features loudly enough for me?

A couple of days ago I paid delicious another visit. See, somebody on #joiito mentioned my Keeping the Flat Clean post, and I suddenly found there was a bunch of people from delicious visiting that article. I thought: “My, people are actually using this thing!” and signed up for an account.

So… what does delicious do? It allows you to easily add pages you visit to your bookmarks, using intelligent bookmarklets (two clicks and no typing to add a link if you want to be minimalist). This is already easier than what I have to do to add links to my LinkBall.

You can categorize your bookmarks very easily by typing words in the “tag” field of the bookmarklet. No need to define categories — delicious takes care of it all for you. You can then view your bookmarks by category or (and this is where it gets interesting) all the bookmarks marked with a same tag. Each bookmark in your list is one-click editable, and each bookmark in somebody else’s list is one-click copyable. For each link, you can also view a list of all the users who have bookmarked it.

Does it stop there? No. All the bookmark lists (by user or by tag) are available in RSS and can be subscribed to within delicious. As a user, you have an Inbox which aggregates the feeds you have subscribed to. You may subscribe to a “user feed” or a “tag (category) feed”. On top of that, bookmark lists are available in plain html, and many users have contributed various hacks which can help you integrate your bookmarks with your weblog. (Update 02.06.04: one thing you shouldn’t do, though, is simply include that HTML feed with a PHP include or an iframe, as this will cause the delicious server to be hit each time somebody views your page.)

If you aren’t a user of delicious yet, you need to go and register right now.

Similar Posts:

Validation and Errors [en]

Although neither do validate, we should not judge a valid page with errors as harshly as a page of tag soup.

For some time now, I have been meaning to clarify the distinction I make between markup which is valid with errors and that which is outright invalid. Yes, I know, in both cases it does not validate.

Take a page which would normally validate as xhtml strict, and insert some are errors into it, like an unclosed tag, an unescaped ampersand and maybe even (oh horror!) a couple of target="_blank" attributes. It does not validate.

Take tag soup. It does not validate either.

But there is a difference between the two, you’ll have to admit. Which is why I suggest calling one of them valid with errors and the other one outright invalid (or just plain invalid). This would also encourage us standards evangelists to be a bit more appreciative of the efforts of those who have gone through the trouble of cleaning up their markup and bringing it nearer to validation, compared to those who just don’t give a damn. As seen on various mailing lists and forums, they are often both greeted quite bluntly with the same “your page doesn’t validate!”

For me, the difference is the same as the one between a well structured text with correct grammar but a few spelling mistakes (it can happen to anybody, even to English teachers!) and a clumsy story with no plot or ending, filled with spelling mistakes, and approximate grammar which makes certain sentences unintelligible.

That might also help us respond to “anti-standards” people who go around sticking our pages in the validator and then say “Hah! it doesn’t validate, look, 50 errors, they’re as bad as we are!”

I’ll say it again: validation (with zero errors) is important. Your PHP or XML parser doesn’t care if there is one or 100 mistakes in your page: it can’t parse it. But we are human beings, and should give credit where credit is due. A “valid page with errors” is not as big a crime as tag soup.

Similar Posts:

Editeurs HTML [en]

Argumentaire pour les éditeurs HTML “à  la main”

Je suis convaincue de l’importance de produire des documents html respectant les standards, et je pense que le moyen le plus efficace, rationnel, et facile consiste à  les produire “à  la main”.

Malheureusement, il ne suffit pas d’être convaincu pour convaincre, et je me trouve souvent empruntée face à  des personnes qui ne jurent que par DreamWeaver et considèrent mon approche comme peu sérieuse, difficile, lente et pas réaliste dans un contexte professionnel (“si tu veux t’amuser à  tout faire à  la main… “).

J’ai tenté de présenter ce qui me semblait être les arguments importants dans ce débat. J’en oublie certainement, et je compte sur vous pour m’aider à  compléter ce document!

Editeurs HTML: argumentaire orienté “personnes normales” 😉

Similar Posts: