NPDS
Responsive

pas simple / par contre on peut donner accès aux traducteurs aux alpha versions !

jpb : tu ouvre un site de support NPDS en chinois ? :-D

Eh dev le chemin est encore long...
je te fais un petit point de l'avancement de la traduction en chinois

- bien sûr j'ai choisi le chinois simplifié (une fois la traduction terminé il sera très facile de convertir _il existe des tas d'outil pour ça- pour obtenir un deuxième language en chinois traditionnel)
- j'ai opté pour l'unicode (qui est à mon sens la solution la plus ouverte et la plus logique même si elle pose quelque problème d'avant gardisme...)
_ je me suis basé : sur les fichiers langue de postnuke, phpBB2 est aussi sur des traductions personnelles que nous avons réalisés...
Actuellement il doit me rester un petit quart à traduire avant de pouvoir disposer des fichiers langues en chinois (par contre ensuite il restera un gros boulot pour le manuel...)

Bon maintenant des questions et des suggestions. Qui permettront une gestion plus sereine des autres langues...


- comment faire pour assouplir la fonction qui rajoute un underscore entre & et # ce qui fiche en l'air le codage du caractère et fait par exemple que je ne peux pas t'afficher de chinois unicode dans ce messsage...je ne me rends pas compte du travail que ca peut représenter mais en tout cas ça risque de poser de gros problèmes...
==> ON peut imaginer faire une liste des codes autorisés ou alors supprimer cette lilite / cela ouvre un petite porte dans la secu de NPDS mais c'est pas la pire


- la gestion des pluriels pose un problème par exemple dans le fichier admin.php à la fonction adminMain le pluriel est codé en dur ce qui veut dire que pour une langue comme le chinois ou bien d'autre on est obligé de modifié ce code car sinon on a en chinois :

le texte en chinois ET s qui devient dans cette situation inutile et incompréhensible pour un chinois...

pour cet exemple précis je pense qu'on peut supprimer purement et simplement la gestion du pluriel (sémantiquement et logiquement on peut sans problème car le "précédent" et le "suivant" s'applique à un groupe de x articles ( de plus en anglais est ce que previouss est correct je doute...

==> si tu me fait une liste, je vire ces trucs sans aucun problèmes !
A suivre

Message édité par : developpeur

Bonjour à tous

Voila encore quelques notes concernant mon exploration des langages

dans : reviews.php function reviews
echo "<BR><b>$title</b><BR><BR>$description<BR><BR>";
il me semble que cette ligne ne sert à rien, si elle sert on devrait la réécrire pour la traduire...


dans : download.php
une petite traduction manquante ?
Les fichiers .zip sont décompactables avec un logiciels comme WinZip, les fichiers .tgz ou tar.gz sont plus spécifiquements orientés Linux (Gzip et Tar).
The .zip files are extractible with software as WinZip, .tgz or tar.gz files are more from Linux world (Gzip & Tar).
par contre j n'arrive pas à trouver le texte dans le fichier???


dans forum.php
ligne 194
je propose de remplacer :
.translate("Join us ! As a registered user, cool stuff like : forum'subscribing, special forums (hidden, members ...), post and read status, ... are avaliable.").
par :
.stripslashes(translate("Join us ! As a registered user, cool stuff like : forum'subscribing, special forums (hidden, members ...), post and read status, ... are avaliable.")).

cela supprime le petit vilain \ qui apparait dans le texte....


Le module glossaire qui possède son fichier lang n'est pas affecté par le choix du langage par l'utilisateur...Sa traduction reste à compléter...

"Dev écrit : ==> ON peut imaginer faire une liste des codes autorisés ou alors supprimer cette limite / cela ouvre un petite porte dans la secu de NPDS mais c'est pas la pire "

J'ai regardé un peu pour une limitation de caractères hélas j'ai des idées mais pas la compétence pour les mettre en oeuvre...enfin ceci est le raisonnement je ne sais pas si il est traduisible en informatique...

- comme premier verrou il faut coder en hexa ce qui permet d'avoir le x comme seul caractère possible après le &#
on peut donc conserver l'ajout de l'underscore pour toute séquence commençant par &# sauf si elle est immédiatement suivi par un x
lui même suivi de 4 ou 5 caractères (qui ne peuvent être que A à F (minuscule ou majuscule) et 0 à 9
qui ne peuvent être suivi que par un point virgule...
et on peut ensuite faire une liste restrictive où on trouverait des caractères unicode fortement déconseillé pour le html par le W3c (http://www.w3.org/TR/unicode-xml/#Suitable) ainsi que ce qu'ils appellent les non-caractères ainsi que tous les caractères non attribués...

Voila si ca peut aider un peu

Bon je retourne dans mes longues traductions...

Salut jpb

Je reprend cette file de discussion un peu tardivement.

Je suis en contact avec giamdoc pour un projet de traduction en chinois et japonnais de pages Internet d'un site existant.
Sauf si Giam me dit qu'il a du nouveau il semble que son contact apte à faire la traduction soit innaccessible pour une période indéterminée.

Serais-tu intéressé pour faire une traduction d'un site d'une dizaine de pages Web en chinois ?
on peut en discuter en message internet si tu veux

exemple ci dessous:
pour écrire en Viet j'utilise les caractères spéciaux... Tout le monde l'a compris!
le problème réside comme l'a tres bien expliqué JPB.
[quote]comment faire pour assouplir la fonction qui rajoute un underscore entre & et # ce qui fiche en l'air le codage du caractère et fait par exemple que je ne peux pas t'afficher de chinois unicode dans ce messsage...je ne me rends pas compte du travail que ca peut représenter mais en tout cas ça risque de poser de gros problèmes...
==> ON peut imaginer faire une liste des codes autorisés ou alors supprimer cette lilite / cela ouvre un petite porte dans la secu de NPDS mais c'est pas la pire[/quote]
Ce qu'il faudrait : que cette fonction qui rajoute un underscore entre & et # ne le rajoute qu'aprés avoir vérifié si ces deux caractères ne sont pas accolés à 4 chiffres suivi d'un point virgule. et si tel est le cas ne pas insérer l'underscore.



voilou, ça fait plaisir de s'accorder une petite demi heure ;-)

Eh Giam !
Pardon mais je crois que l''on doit étendre la suite de caractère (après le #x) à 5 sinon il en manquera dans certaine langue...De plus je pense que le codage hexa offre plus de possibilité de verouillage (Voir le poste précédent)... qu'en penses tu??

Bonjour tous

- Description d'un petit problème...


1- objectif : un footer un chinois...
contexte : saisie de caractères unicode dans les champs footer de préférences

je saisi donc les caractères unicode codé pour le html en hexa entre les balises [chinese][/chinese] je sauvegarde les préférences et nous voila avec un beau footer en chinois dans les pages...

Mais voici le problème : à l'ouverture suivante des préférences les champs des lignes footer affichent maintenant des caractères chinois... Ce qui devrait être bon signe MAIS lors de la sauvegarde des préferences il se transforment en ????? dans le fichier config et donc dans les pieds de pages...

note 1 : j'ai saisi aussi directement des caractères chinois (donc non codé html) de mon clavier pas de problèmes on peut saisir du chinois dans les champs du footer mais lors de la sauvegarde des préferences il se transforment en ????? dans le fichier config et donc dans les pieds de pages
- un constat

note 2 :
- un constat
une erreur de balance des balises langues par exemple : [chinese][/english] dans le footer et le navigateur charge indéfiniment (enfin probablement)...


alors toujours des verrous? ou c'est autre chose...

faut me faire une liste les enfants sinon je vais me perdre !

Footer ... je pense que c'est un prob de codage (je vais regarder)
Erreur de balance des balises .... le script ne le gère pas ... et donc plante (je vais regarder aussi)
Le codage hexa : on peut assouplir removehack si c'est plus simple pour vous

Pensez à me faire une liste ! :=!

Bonjour tous
pour info :
- le fichier lang-chinese est en version beta00 (ce qui veut dire qu'il est entièrement traduit et entre dans son étape de correction)
- tous les autres devrait être en beta à la fin du mois ( à l'exception du manuel non encore attaqué...)

voili

a++

Bonjour,

Voilà enfin tous les fichiers langue de base de NPDS sont en beta 00 (donc à priori utilisable pour une prochaine mise en ligne) bien sûr il y aura de nombreuses corrections et nous attendrons le retour et les propositions de corrections d'éventuel utilisateurs de la langue de l'empire du milieu...
Je tiens à remercier Mlle Zhang Yingzhu pour son travail acharné car quoiqu'on dise c'est un gros boulot la traduction des fichiers langue...
Alors la suite du programme le manuel et les modules... Au cas ou on s'ennuierait...

Salut , salut,

Une étape de plus de la traduction en chinois de NPDS : les manuels sont traduits relus et corrigés une première fois (hors contexte d'utilisation)...
- il reste donc deux petites étapes : restructuration des fichiers html
et dernières corrections dans le contexte d'utilisation...
Ce qui veut dire que NPDS version chinoise devrait pouvoir faire partie de sable...

restera ensuite à se pencher sur les modules de base... Mais le plus gros boulot est fait 8-)

PSPI (post scriptum pour initiés) : le premier fichier manuel admin.html est sur labo

Et pour nous ...

en ce moment, on fait pleuvoir les modules :-(

faudrait peut etre voir a "imposer" un systeme de codage des modules pour disposer du multilangue d'office...
je pense qu'un article avec la marche a suivre pour remplacer TXT_FR par tanslate(TXT_FR) ds ses modules aiderai bien...

Axel :-| >Normalement c'est fait pour tous les nouveaux modules.... :b
Reste la marche a suivre pour l'uft8