Premier jet d'un vague plan [en]

[fr] Here's the really rough first draft of the outline for the book, as I got it down in a bit under an hour many months ago. It will certainly need reworking.

D’abord, merci, vraiment merci, pour vos encouragements, surtout entre samedi soir tard et dimanche midi! Je suppose que c’est aussi un des avantages de se mettre à écrire un livre sur la place publique (ce blog en l’occurence): je me sens un peu moins seule face à mon grand projet.

Comme promis, voici l’ébauche de plan que j’avais mise sur papier (décidément, il nous faut urgemment des équivalents numériques à ce genre d’expression) en moins d’une heure, il y a près de six mois. Ce n’est certainement pas définitif, mais il faut bien commencer quelque part, et ça a au moins le mérite de tenter d’éclairer un peu ce que j’ai dans la tête.

  • Introduction
    • la technologie évolue de plus en plus vite => l’écart se creuse
    • ados livrés à eux-mêmes pour découvrir
      • outils
      • communautés
      • nouveaux moyens d’être en contact avec autrui
  • Ce que les ados font en ligne
    • bibliothèque vs. ville
    • msn/jeux/blogs
    • réseau social s’étend au-delà de la vie hors ligne
  • Regard sur les blogs d’ados
    • pourquoi le font-ils?
      • mémoire collective
      • tribu
    • ce dont ils sont faits
      • photos
      • paroles copiés, poèmes
      • anecdotes
      • le plus souvent: album photos
  • Problèmes sur les blogs d’ados
    • mobbing
    • insultes
    • suicide/dépression
    • s’exposer
      • peau
      • actes
        • vol
        • drogues
        • fêtes
  • Pourquoi nous avons ces “problèmes”
    • anonymat
      • être discrets
      • comment on peut tomber ‘par hasard’ sur qc en ligne
    • permanence du contenu numérique
    • inconscience du caractère public du blog
    • communauté purement de pairs
  • Une approche de cette situation via les écoles
    • personne externe connaissant bien l’internet social
    • approche triple: parents, enfants, enseignants
  • Que dire et comment

Clairement, il faudra reprendre ça. Prochaine étape, je pense, avant, c’est d’essayer de mettre par écrit de façon succinte la problématique dont traitera ce livre (idée attrapée chez Karim, merci!). Comme je l’ai dit hier, je crois que j’ai besoin d’être un poil plus au clair sur où je vais avant de me lancer dans la rédaction proprement dite — sinon je vais me perdre.

Sur ce… j’abrège, parce que bobo — allez donc savoir si c’est lié, ou quoi. Dragon et Parallels seront de la partie. Il faut juste que je m’encourage à les installer, entre une visite d’école, une matinée chez un client et une table ronde à Genève. La suite au prochain épisode!

LIFT'06 Notes [en]

[fr] Mes notes (brouillon) de la journée à  LIFT'06.

Here are my draughty notes, as is, pretty incomplete and not necessarily intelligible. Use if you wish.

Requirements for a Multilingual WordPress Plugin [en]

[fr] Quelques réflexions concernant un plugin multilingue pour WordPress.

My blog has been bilingual for a long time now. I’ve hacked bilingualism into it and then plugged it in. Other plugins for multilingual bloggers have been written, and some unfortunately got stuck somewhere in the development limbo.

Defining specs is a hairy problem. They need to work for the person visiting the site (polyglot or monoglot). They need to work for the person (or people! translation often involves more than one person) writing the posts. They need to work for all the robots, search engines, and fancy browsers who deal with the site.

Here is what I would like a multiple language plugin to do (think “feature requirements”, suggestion, draft):

  1. Recognize the browser language preference of the visitor and serve “page furniture” and navigation in the appropriate language. This can be overridden by a cookie-set preference when clicking on a “language link”.
    • “WordPress” furniture can be provided by the normal localization files
    • how do we deal with other furniture content in the theme (navigation, taglines, etc.)? should the plugin provide with guidelines for theme localization? do such guidelines already exist? extra information appreciated on this point
    • “language links” shouldn’t be flags, but language names in their respective languages; can this list be generated automatically based on present localization files? otherwise, can it be set in an admin panel?
    • upon “language change” (clicking on a language link), could the localization (action) be done in an AHAH– or AJAX-like way?
    • inevitable hairy problem: tag and category localization
  2. Manage “lazy multilingualism” in the spirit of the Basic Bilingual plugin and “true multilingualism” elegantly and on a per-post basis.
    • allow for “other language abstracts”
    • allow for actual other language version of the post
    • given the “general user language” defined above, show posts in that language if a version for that language exists, with mention of other language versions or abstracts
    • if that language doesn’t exist, show post in “main blog language” or “main post language” (worst case scenario: the wordpress install default) and show alongside other language abstracts/versions
    • abstract in one language (would be “excerpt” in the “main” language) and existence of the post in that language are not mutually exclusive, both can coexist
    • does it make more sense to have one WordPress post per language version, or a single post with alternate language content in post_meta? For lazy multilingualism, it makes more sense to have a single WP post with meta content, but fore “translation multilingualism”, it would make more sense to have separate posts with language relationships between them clearly defined in post_meta
  3. Use good markup. See what Kevin wrote sometime back. Make it nice for both polyglot and monoglot visitors. Inspiration?
    • use <div lang="xx"> and also rel attributes
  4. Provide a usable admin panel.
    • when I’m writing the other version of a post, I need access to the initial version for translation or abstracting
    • ideally, different language version should be editable on the same admin panel, even if they are (in the WordPress database) different posts
    • languages in use in the blog should be defined in an options screen, and the plugin should use that information to adapt the writing and editing admin panels
    • idea: radio button to choose post language; N other language excerpt/abstract fields with radio buttons next to them too; abstract radio buttons change dynamically when main post language is set; in addition to other language abstract fields, another field which can contain a post id/url (would have to see what the best solution is) to indicate “this is an equivalent post in another language” (equivalent can be anything from strict translation to similar content and ideas); this means that when WP displays the blog, it must make sure it’s not displaying a post in language B which has an equivalent in language A (language A being the visitor’s preferred language as defined above)
  5. Manage URLs logically (whatever that means).
    • if one post in two languages means two posts in WP, they will each have their own slug; it could be nice, though, to be able to switch from one to an other by just adding the two-letter language code on the end of any URL; a bit of mod_rewrite magic should do it
  6. Integrate into the WordPress architecture in a way that will not break with each upgrade (use post-meta table to define language relationships between different posts, instead of modifying the posts table too much, for example.)
    • one post translated into two other languages = 3 posts in the WP posts table
    • excerpts and post relationships stored in post_meta
    • language stored in post_meta

I have an idea for plugin development. Once the specs are drafted out correctly, how about a bunch of us pool a few $ each to make a donation to (or “pay”) the person who would develop it? Who would be willing to contribute to the pool? Who would be willing to develop such a plugin (and not abandon the project half-way) in these conditions?

These specs need to be refined. We should start from the markup/reader end and get that sorted out first. Then, think about the admin panel/writer end. Then worry about code architecture. How does that sound?

We’ve started a discussion over on the microformats.org wiki. Please join us!

Update: this post is going to suffer from ongoing editing as I refine and add ideas.