Coucou : ce mode d'intégration des données n'est pas efficace (recalcul du
$tableau lang_str à chaque ligne). Il vaut mieux indiquer le tableau en une
seule fois, comme j'avais fait dans mes dernières modfifs ; en plus le code
est plus propre...
J'ai peur que ce soit moins commode pour un traducteur.
Faut tester la rapidité des deux pour voir...
tu as mis les chaines de base en anglais. Pourquoi ce choix ?
Heu, c'est pas vraiment un choix, c'est juste pour tester. On
reprendra depuis zéro quand tout sera prêt. Je n'ai aucune préférence
perso. Les traducteurs seront-ils plutôt francophones ou
anglophones ? Pour une traduc de meilleure qualité (à partir de la
version originale), il vaut mieux qu'ils soient francophones...
1) Pourquoi marquer [NEW] dans la chaine ?? Il serait bien mieux de
mettre un commentaire à côté de cette ligne là, ce qui permettrait,
quand
une traduction est en retard sur le principal, qu'elle affiche le
texte en
français sans marquer cet horrible [NEW].
On peut mettre un <NEW> qui sera masqué en HTML ;-))
Mais l'avantage d'afficher le [NEW], c'est qu'on voit justement
ce qui n'est pas traduit...
> Coucou : ce mode d'intégration des données n'est pas efficace (recalcul
> du tableau lang_str à chaque ligne). Il vaut mieux indiquer le tableau
> en une seule fois, comme j'avais fait dans mes dernières modfifs ; en
> plus le code est plus propre...
J'ai peur que ce soit moins commode pour un traducteur.
Au contraire, à mon avis c'est plus simple:
"origine" =>
"mon texte",
c'est à peine si on voit que c'est du php ET surtout il y a moins de risques
de faute de frappe.
Faut tester la rapidité des deux pour voir...
Ma solution est environ 5 à 10 fois plus rapide selon mes tests (sur un
tableau à 1000 entrées). Je t'envoie le fichier si tu veux !
anglophones ? Pour une traduc de meilleure qualité (à partir de la
version originale), il vaut mieux qu'ils soient francophones...
Oui, je le pense aussi, donc restons en français. D'autant que notre
champion de l'anglais, on l'a déjà
Mais l'avantage d'afficher le [NEW], c'est qu'on voit justement
ce qui n'est pas traduit...
Tu veux voir ça dans le fichier de langue, pas dans l'interface privée
Donc un commentaire php à côté de la chaine à traduire est largement
suffisant. Si notre traducteur wolof nous lâche en chemin, il restera des
bouts en wolof, et le reste en français, jusqu'à ce qu'un autre traducteur
wolof arrive...
c'est à peine si on voit que c'est du php ET surtout il y a moins de risques
de faute de frappe.
Ok
Ma solution est environ 5 à 10 fois plus rapide selon mes tests (sur un
tableau à 1000 entrées). Je t'envoie le fichier si tu veux !
Chez moi c'est plutôt 30% plus rapide, mais bon
Tu veux voir ça dans le fichier de langue, pas dans l'interface privée
Donc un commentaire php à côté de la chaine à traduire est largement
suffisant. Si notre traducteur wolof nous lâche en chemin, il restera des
bouts en wolof, et le reste en français, jusqu'à ce qu'un autre traducteur
wolof arrive...
Ok, bon, je mets un <NEW> pour l'instant, c'est plus simple dans mon
code....
Y a un petit problème dans la façon dont on règle le charset
de l'interface privée actuellement. Le charset devrait être
celui de l'interface et pas celui du contenu. Evidemment si
l'interface est en anglais, voire en français ou en allemand
mais en remplaçant les caractères accentués par les entités
HTML correspondantes, c'est bon (ça n'utilise que les caractères
ascii, qui sont à peu près universels). Mais pour une interface
en thaïlandais, par exemple, je ne suis pas sûr qu'on puisse
demander au traducteur d'écrire ses chaînes entièrement en
entités numériques illisibles ({...). Du coup l'interface
devra être affichée avec le charset thaïlandais : par
contrecoup, impossible de visualiser un texte écrit en russe.
On peut toutefois changer le charset à l'intérieur d'un formulaire.
Il suffit de faire :
<FORM ACTION='$lien' METHOD='post' enctype='multipart/form-data'
accept-charset='windows-1251'> (pour écrire en russe dans une
page HTML d'un autre jeu de caractères ; ça marche avec Mozilla)
Par contre je n'ai rien trouvé pour la visualisation : on ne
peut pas faire un paragraphe en windows-1251 natif dans une page
iso-8859-1 (par exemple). Donc on est un peu bloqués.
On peut faire un compromis : les langues "gentilles" (latines
avec quelques entités HTML) spécifieront un $lang_charset = "",
ce qui règlera le charset de l'espace privé à la valeur de la
config. Les autres langues règleront $lang_charset à la valeur
nécessitée, qui remplacera le charset du site au sein de l'espace
privé (et le mélange des langues montrera ses limites lors de la
visualisation de certains articles). Les formulaires imposeront
systématiquement le charset du site (comme ci-dessus).
Pardonnez-moi pour cette question qui est plus de la curiosité qu'une
proposition. Pourquoi ne passez-vous pas en Unicode ou UTF-8?
-> compatibilité avec des navigateurs
-> mauvaise gestion par les navigateurs supposant le gérer
-> stockage MySQL?
-> cela ne résout pas les problèmes (et pourquoi?) etc.
Juste histoire de comprendre les problèmes de prod d'une 'solution'
informatique.
> Ma solution est environ 5 à 10 fois plus rapide selon mes tests (sur un
> tableau à 1000 entrées). Je t'envoie le fichier si tu veux !
Chez moi c'est plutôt 30% plus rapide, mais bon
Mon test doit être faussé, parce qu'en fait pour avoir une "meilleure" idée
j'ai fait 100 fois l'instanciation en question. Ce qui, je suppose, conduit
à négliger le temps de compilation. Mais sur un système avec
php_accelerator, il faut négliger la compilation
ascii, qui sont à peu près universels). Mais pour une interface
en thaïlandais, par exemple, je ne suis pas sûr qu'on puisse
demander au traducteur d'écrire ses chaînes entièrement en
entités numériques illisibles ({...).
Euh, si, on peut : il suffit qu'il édite son fichier dans Excel ou Mozilla par
exemple, puis qu'un moulinette le remette au format spip. C'est jouable, pas
super pratique mais jouable.
On peut toutefois changer le charset à l'intérieur d'un formulaire.
Il suffit de faire :
<FORM ACTION='$lien' METHOD='post' enctype='multipart/form-data'
accept-charset='windows-1251'> (pour écrire en russe dans une
page HTML d'un autre jeu de caractères ; ça marche avec Mozilla)
Oui, mais ça va être compliqué.
privé (et le mélange des langues montrera ses limites lors de la
visualisation de certains articles).
De toutes façons
Enfin, éditer un site en russe dans une interface en thailandais, on peut
estimer que ça n'est pas super prioritaire.
Pardonnez-moi pour cette question qui est plus de la curiosité qu'une
proposition. Pourquoi ne passez-vous pas en Unicode ou UTF-8?
Ca serait la bonne solution, mais il semblerait que php ne soit pas
suffisamment compatible utf8. A l'avenir, c'est sûrement la bonne solution.
(cf. TODO)
> Euh, si, on peut : il suffit qu'il édite son fichier dans Excel ou
> Mozilla par exemple, puis qu'un moulinette le remette au format spip.
> C'est jouable, pas super pratique mais jouable.
Mouais mais le fichier .php n'est plus lisible après (sauf dans une
interface HTML). C'est pas super pour reprendre la traduction ;-))
Par rapport à d'autres galères quand tu bosses avec des charsets, c'est
assez anecdotique... en plus il suffit de faire un convertisseur
entites<->charset ; tu l'appliques, tu bosses dans ton charset, tu sauves,
tu remets en entités. C'est assez trivial.
Mouais mais le fichier .php n'est plus lisible après (sauf dans une
interface HTML). C'est pas super pour reprendre la traduction ;-))
Par rapport à d'autres galères quand tu bosses avec des charsets, c'est
assez anecdotique... en plus il suffit de faire un convertisseur
entites<->charset ; tu l'appliques, tu bosses dans ton charset, tu
sauves, tu remets en entités. C'est assez trivial.
Heu, il "suffit" ?? De plus l'idéal c'est quand même que le traducteur
fasse ses modifs dans le .php et puisse tester directement le SPIP
traduit sans passer de "moulinette"... Donc qu'il n'y ait pas de conversion
lourdingue (pas comme gettext ;-).
Et si on internationalise aussi le texte des mails, on ne peut plus
utiliser d'entités HTML....
Pour l'iso8859-1 on en a fait un, il est même dans spip... j'ai aussi dans
un coin un convertisseur mac2iso.php3... donc, oui, "il suffit".
De plus l'idéal c'est quand même que le traducteur fasse ses modifs dans
le .php et puisse tester directement le SPIP traduit sans passer de
"moulinette"... Donc qu'il n'y ait pas de conversion lourdingue (pas comme
gettext ;-).
Oui, mais l'idéal sera atteint avec utf8, en attendant on est de toutes
façons dans une situation merdique.
Et si on internationalise aussi le texte des mails, on ne peut plus
utiliser d'entités HTML....
Si si ! Il suffit de passer le mail à la moulinette, comme on le fait déjà
pour le mail nouveautés.
Si si ! Il suffit de passer le mail à la moulinette, comme on le fait
déjà pour le mail nouveautés.
Justement, c'est n'importe quoi cette moulinette. SPIP n'est pas l'endroit
pour stocker la table complète des entités HTML unicode...
Franchement, niveau lisibilité, il faut garder des fichiers langues en
clair, en tout cas pour les langues qui n'utilisent pas une majorité de
caractères occidentaux. L'avantage des fichiers PHP, c'est qu'on n'a pas
besoin d'outils extérieurs pour les consulter (contrairement aux
gettexteries), ce serait dommage de s'en passer.
Bonjour,
Débutant sur Spip je ne trouve pas dans l'interface d'admin ou l'on créait
les squelettes. Qq'un pourrait il m'aider svp ?
Merci d'avance pour l'aide.
A+ Bertrand
