(1) Première possibilité: tu as défini une syntaxe "privée", transparente
in fine pour les rédacteurs, qui servira uniquement de support de stockage
de l'information qui, elle, sera déterminée par une interface spécifique
(genre, "traduire ce mot-clé en anglais"). Dans ce cas, effectivement, la
syntaxe retenue importe peu.
Non, c'est plutôt un raccourci ; faut pas charrier non plus, quand tu en
arrives, dans ton site, à traduire les mots-clés et les descriptifs des
auteurs, tu as déjà suffisamment de bagage pour pouvoir fabriquer une
structure comme celle-ci à la main (et elle est très simple).
Je tiens d'autant plus à cette structure "manuelle" que la fonction qui
affecte un mot à un bloc multi est très ouverte. Elle pourrait très bien,
par exemple, aller chercher les traductions dans un fichier externe, ou dans
la base de données, ou auprès d'un service de traduction en ligne...
Cela signifie, signifie, en clair, qu'il pourrait suffire de taper
<multi>Irak</multi> pour obtenir toutes les traductions à partir d'un dico
installé en local (un simple fichier texte, par exemple, ou une structure
plus complexe). La fonction à modifier pour ça, c'est
function multi_trad ($lang, $trads) {
// $lang est la langue demandée
// $trads un tableau déjà analysé, de la forme
// Array ('' => 'Irak', 'en'=>'Iraq');
}
- comme indiqué, il faut conserver les habitudes des raccourcis
précédents (qui sont, dès l'origine, du pseudo-html, avec des balises
ouvrantes et fermantes, et l'usage des chevrons);
Le raccourci c'est <multi>...</multi>, mais ensuite il faut un méthode
simple, rapide, intuitive pour taper ce qu'il y a *à l'intérieur*. Les
balises fermantes sont inutiles (mais on pourrait éventuellement décider de
les ignorer si elles sont présentes et qu'on est stressé par le xml, bien
que je n'en voie pas l'utilité) ; les chevrons sont trop problématiques (on
les voit mal, ils se confondent avec les autres tags), et d'ailleurs en xml
il faudrait mettre <lang name='li'>en lituanien</lang>...
- la définition du texte "par défaut" me semblait très peu claire et
incomplète, puisqu'il est déduit d'une autre balise (c'est la première
chaîne traduite), et on est obligé d'avoir une chaîne par défaut;
Tu n'as pas vu que <multi>Irak [en] Iraq</multi> utilise "Irak" comme chaîne
par défaut : il n'est pas *obligatoire* de préciser la langue de la chaîne
par défaut (même si c'est mieux si on aime les choses "bien rangées").
- surtout: ça me bloque sur un autre point qui me turlupine depuis
belle lurette: une balise permettant de changer de langue dans un même
champ.
.../...
Pour le pavé dans une autre langue, je pensais à quelque chose du genre:
> blah blah blah en français
> <lang_ar>du texte en arabe</lang_ar>
> blah blah blah en français à nouveau.
Pour ce genre d'applications, je pense qu'il est totalement illusoire de
vouloir gérer une typo défférenciée ; il reste le problème du bidi, qui se
règle en HTML par le truc lourdingue <div dir='ltr'>...</div>, pour lequel
on peut inventer un raccourci sous la forme <bidi>...</bidi>, qui inverse le
sens du bloc concerné (pas besoin de mnémotechnique trop lourde).
Je remets mon code en améliorant deux-trois points suite à cette discussion,
tu me diras.
PS: tu verras dans inc_filtres, je calcule un ensemble de <div>...</div>
contenant les textes traduits, mais un peu plus longs que ce qui s'affiche
en survol. Dans inc_presentation, il faudrait écrire le javascript qui
affiche le popup correspondant quand on clique sur le micro ; là j'ai fait
un simple alert("texte à afficher"), faute de maîtriser le DHTML...
-- Fil
