Pour l'instant, il y a deux solutions pour faire ça:
- les squelettes séparés par langue; mais c'est extrêmement lourd à gérer,
car ça multiplie les squelettes pour d'infimes modifications;
- des boucles de test sur les langues, testant la langue courante de
l'article/rubrique, genre si c'est en français on affiche "Imprimer cet
article", sinon on affiche autre chose. C'est gérable pour deux langues, au
delà on imbrique des boucles à perte de vue.
J'en suis au même point et j'arrivais avec les mêmes conclusions.
Une solution serait d'autoriser la création de fichiers de trads
personnels. Pas de modifier les fichiers trads fournis (qui, de toute
façon, ne sont pas conçus pour contenir la mention "Imprimer ce truc,
télécharger cette cochonnerie, envoyer ce virus à un ami..."), mais de
créer de petits fichiers supplémentaires. Genre "perso-fr.php3", "perso-
en.php3", "perso-it.php3"...
Effectivement, ça simplifierais énormément le travail en le rendant plus
souple.
Une solution serait d'autoriser la création de fichiers de trads
personnels. Pas de modifier les fichiers trads fournis (qui, de toute
façon, ne sont pas conçus pour contenir la mention "Imprimer ce truc,
télécharger cette cochonnerie, envoyer ce virus à un ami..."), mais de
créer de petits fichiers supplémentaires. Genre "perso-fr.php3", "perso-
en.php3", "perso-it.php3"...
C'est prévu, et c'est déjà censé marcher. Il suffit de créer tes fichiers de
langue toto_fr.php3 sur le modèle de spip_fr.php3, et d'appeler :
- soit en direct _T('toto:code')
- soit dans un squelette [(#LANG|traduire{"toto:code"})]
(Dans toto_fr.php3 tu auras
'code' => 'la chaine traduite',
et non pas 'toto:code' ; c'est ça les "modules" de langue)
>- soit en direct _T('toto:code')
>- soit dans un squelette [(#LANG|traduire{"toto:code"})]
Ca marche! C'est top-génial, ce truc
Mieux :
[(#LANG|traduire{"toto:download"}|sinon{"Download this file"})]
affichera la traduction du code 'download' dans la langue #LANG ; si cette
traduction n'a pas été faite, affichera "Download this file"...
PS: sur spip.net, les fichiers de langue du site sont aussi gérés par
l'interface de Florent : par conséquent, le fichier public_fr.php3 que tu es
en train de fabriquer devrait être traduisible directement en ligne, ce qui
est plutôt bien. Du coup je préférerais tout de même que tu ne le nommes pas
'public', mais que tu donnes un nom de module plus spécifique ('spipnet',
par exemple).
PS: sur spip.net, les fichiers de langue du site sont aussi gérés par
l'interface de Florent : par conséquent, le fichier public_fr.php3 que tu es
en train de fabriquer devrait être traduisible directement en ligne, ce qui
est plutôt bien.
A ce propos, il suffirait de peu de choses dans cette interface pour qu'on
puisse créer de nouvelles chaînes.... si vous voyez à quoi je pense...
Du coup je préférerais tout de même que tu ne le nommes pas
'public', mais que tu donnes un nom de module plus spécifique ('spipnet',
par exemple).
Bis repetita
En revanche ça pourrait être sympa de mutualiser un module 'public', qui
reprendrait les chaînes les plus courantes qu'on trouve dans les squelettes
("Accès rédacteurs", "Administration", "Site créé avec SPIP", etc...), et
qui serait livré avec SPIP pour faciliter la création de sites multilingues
"classiques"
Pour l'instant, il y a deux solutions pour faire ça:
- les squelettes séparés par langue; mais c'est extrêmement lourd à gérer,
car ça multiplie les squelettes pour d'infimes modifications;
Oui, effectivement, après quelque temps, ça devient vite l'enfer à gérer.
- des boucles de test sur les langues, testant la langue courante de
l'article/rubrique, genre si c'est en français on affiche "Imprimer cet
article", sinon on affiche autre chose. C'est gérable pour deux langues, au
delà on imbrique des boucles à perte de vue.
Effectivement, pour 2 langues, ça va bien pour l'instant, du moins pour moi.
Mais pour 3 langues et plus, je vois pas comment je m'en tirerais.
Une solution serait d'autoriser la création de fichiers de trads
personnels. Pas de modifier les fichiers trads fournis (qui, de toute
façon, ne sont pas conçus pour contenir la mention "Imprimer ce truc,
télécharger cette cochonnerie, envoyer ce virus à un ami..."), mais de
créer de petits fichiers supplémentaires. Genre "perso-fr.php3", "perso-
en.php3", "perso-it.php3"...
> >- soit en direct _T('toto:code')
> >- soit dans un squelette [(#LANG|traduire{"toto:code"})]
>
> Ca marche! C'est top-génial, ce truc
Mieux :
[(#LANG|traduire{"toto:download"}|sinon{"Download this file"})]
Franchement, c'est une horreur votre truc. Non seulement
il faut se taper du PHP pour ajouter des chaînes mais
en plus la syntaxe du filtre confine au n'importe quoi.
Je ne vois pas comment on peut sérieusement conseiller ça
à un webmestre de base.
> [(#LANG|traduire{"toto:download"}|sinon{"Download this file"})]
Franchement, c'est une horreur votre truc. Non seulement
il faut se taper du PHP pour ajouter des chaînes mais
en plus la syntaxe du filtre confine au n'importe quoi.
Je ne vois pas comment on peut sérieusement conseiller ça
à un webmestre de base.
Dans un premier temps il fallait que ça marche : ça marche ! Maintenant, si
tu trouves une API plus sympa, n'hésite pas.
Version 1.7a5 CVS
En utf-8
Apache/2.0.47 (Unix) DAV/2 PHP/4.3.2 MySQL/4.0.13
1. Dans Mozilla 1.4 (Mac OS X) - Quand on pointe sur les guillemets
français, ça affiche en dessous "Ins?rer des «guillemets français»".
Les autres raccourcis, c'est OK.
2. Sous Mac OS X, dans Internet Explorer, la barre des raccourcis n'apparaît
pas; c'est OK comme ça. Mais dans Safari 1.0 et Omniweb 4.5, la barre
apparaît, mais ne fonctionne pas.
Leur identification dans le "header" HTTP
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/85 (KHTML, like
Gecko) Safari/85
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US) AppleWebKit/85 (KHTML, like
Gecko) Omniweb/v496