[spip-dev] i18n/gen_lang.php3

Au fait, comment s'utilise le fichier i18n/gen_lang.php3 ?

Je suppose qu'on commence par marquer les chaînes à localiser via un
    _T("Ma chaîne en clair")

... puis qu'on lance le script qui va parser tous les fichiers à la recherche
des _L et des _T, et demander de donner des codes aux chaînes _T ?

Mais :

1) Comment marque-t-on les arguments ? -- dans inc_gettext.php3 on doit les
   passer via la représentation
      _("texte @valeur@ suite", Array('valeur'=>$toto));

2) Quelle nomenclature choisit-on pour les codes ? Je pencherais pour une
   nomenclature en francais très simple et évidemment sans accents. J'ai
   vu que tu (Antoine) avais fait tes tests en anglais... il faut choisir.

                                    * * *

Pour la suite, il faudrait faire un "guide du traducteur", pour qu'il sache
à quoi il s'expose, et organiser les listes par langue, ainsi qu'un espace
de documentation pour chaque langue. Est-ce qu'on fait un spip-documentation
par langue ? Est-ce qu'on fait un seul gros spip-documentation centralisé ?
Sur uZine ou ailleurs ? Sur spip_contrib ou ailleurs ? Comment nommer les
"champions" de chaque trad ? etc.

-- Fil

... puis qu'on lance le script qui va parser tous les fichiers à la recherche
des _L et des _T, et demander de donner des codes aux chaînes _T ?

En fait, il suffisait d'essayer :wink:
Le reste des questions reste posé...

Un bug (?), tiens :

Fichier : ./admin_tech.php3

Les chaînes suivantes doivent être internationalisées. Veuillez indiquer le
symbole de votre choix afin de désigner ces chaînes dans le code
(conformez-vous aux conventions en vigueur dans votre projet).

Chaîne Code

Maintenance technique

Maintenance technique

Vous n'avez pas accès à cette page.

-- Fil

Bon... un détail, mais qui a son importance : dans mon éditeur préféré avec
ma police de caractères préférée, le _L forme un ensemble bizarre à l'oeil
(symétrique autour de la barre verticale), qui risque d'être gênant s'il se
retrouve partout dans le code.

Il serait plus lisible d'adopter la convention _T comme code de traduction
définitive, quitte à avoir _M ou _L, ou _t ou autre encore pour le
transitoire.

-- Fil

Coucou,

Au fait, comment s'utilise le fichier i18n/gen_lang.php3 ?

Je suppose qu'on commence par marquer les chaînes à localiser via un
    _T("Ma chaîne en clair")

... puis qu'on lance le script qui va parser tous les fichiers à la recherche
des _L et des _T, et demander de donner des codes aux chaînes _T ?

Oui. Il faut que le répertoire "lang" soit créé. Si celui-ci contient
d'autres fichiers langue que la langue par défaut ("fr" paramétré au
début de gen_lang.php3), ces fichiers sont mis à jour à la fin de la
procédure (nouvelles chaînes ajoutées au fichier).

Mais :

1) Comment marque-t-on les arguments ? -- dans inc_gettext.php3 on doit les
   passer via la représentation
      _("texte @valeur@ suite", Array('valeur'=>$toto));

Ce n'est pas géré par gen_lang.php3, il faut le faire à la main dans le
_L. En clair :

- d'abord écrire _T("vous avez @nb_messages@ messages") ;
- passer le script qui transforme en _L("bienvenue_n_messages") ;
- enfin ajouter à la main les paramètres :
  _L("bienvenue_n_messages", array('nb_messages' => $nb_messages)).

2) Quelle nomenclature choisit-on pour les codes ? Je pencherais pour une
   nomenclature en francais très simple et évidemment sans accents. J'ai
   vu que tu (Antoine) avais fait tes tests en anglais... il faut choisir.

Ok pour le français, il faut s'organiser au fur et à mesure.
Je propose par exemple :

- icone_auteurs, icone_edition, icone_deconnexion... pour les icones
(navigation du haut)
- bouton_article_modifier, bouton_rubrique_supprimer... pour les
"boutons"
- label_article_titre, label_rubrique_descriptif... pour les labels de
formulaires

A compléter et amender.

Un truc qu'on n'a pas abordé : l'aide en ligne. J'imagine qu'on adopte
le même genre de système ? (aide_fr, aide_en, etc.)

Pour la suite, il faudrait faire un "guide du traducteur", pour qu'il sache
à quoi il s'expose, et organiser les listes par langue, ainsi qu'un espace
de documentation pour chaque langue. Est-ce qu'on fait un spip-documentation
par langue ? Est-ce qu'on fait un seul gros spip-documentation centralisé ?

Je vois plutôt plusieurs spip_doc, pour différentes raisons :

- S'il y a d'autres charsets que l'occidental, il faut plusieurs
bases et sites distincts.
- SPIP ne permet de toute façon pas une gestion multilingue
compliquée (du genre : si l'article n'est pas dispo en anglais,
l'afficher en français).
- Si on garde les forums, il vaut mieux séparer les langues :wink:

Sur uZine ou ailleurs ? Sur spip_contrib ou ailleurs ?

De toute façon ce sera une zone séparée comme aujourd'hui, avec
ses squelettes à elle. L'unique question est : qui y participe ?
On peut le faire sur spip_contrib, si la gestion des squelettes
et droits d'admin ne pose pas de problèmes. Sur uzine si tu veux,
mais je n'y ai pas accès, et il faudra ménager des droits admin
pour les contributeurs étrangers à la doc.

Comment nommer les
"champions" de chaque trad ? etc.

Au départ on peut prendre les premiers volontaires, non ?
Ensuite on verra s'il y a des "challengers".

a+

Antoine.

> 1) Comment marque-t-on les arguments ? -- dans inc_gettext.php3 on doit les
> passer via la représentation
> _("texte @valeur@ suite", Array('valeur'=>$toto));

Ce n'est pas géré par gen_lang.php3, il faut le faire à la main dans le
_L. En clair :

- d'abord écrire _T("vous avez @nb_messages@ messages") ;
- passer le script qui transforme en _L("bienvenue_n_messages") ;
- enfin ajouter à la main les paramètres :
  _L("bienvenue_n_messages", array('nb_messages' => $nb_messages)).

Eurk : là il y a un gros risque de perdre beaucoup de temps à s'occuper des
variables... on pourrait déjà chopper les @xx@ et préparer l'array() à
remplir ?

- S'il y a d'autres charsets que l'occidental, il faut plusieurs
bases et sites distincts.

On pourrait faire un spip utf-8, pour ça... mais :

- SPIP ne permet de toute façon pas une gestion multilingue
compliquée (du genre : si l'article n'est pas dispo en anglais,
l'afficher en français).
- Si on garde les forums, il vaut mieux séparer les langues :wink:

OK.

-- Fil

Eurk : là il y a un gros risque de perdre beaucoup de temps à s'occuper des
variables... on pourrait déjà chopper les @xx@ et préparer l'array() à
remplir ?

Oui, ça doit pas être trop compliqué...

Il serait plus lisible d'adopter la convention _T comme code de traduction
définitive, quitte à avoir _M ou _L, ou _t ou autre encore pour le
transitoire.

Ok, disons _L => _T ?

@ Antoine Pitrou <antoine@rezo.net> :

> Eurk : là il y a un gros risque de perdre beaucoup de temps à s'occuper des
> variables... on pourrait déjà chopper les @xx@ et préparer l'array() à
> remplir ?

Oui, ça doit pas être trop compliqué...

Et, par défaut, mettre array ('toto' => $toto, 'tata' => $tata), ce qui
sera bon une fois sur deux ou plus...

Ok, disons _L => _T ?

ouaips

-- Fil

Bonjour,

Pour un site multilingue occitan/français, on aurait besoin d'une version de
SPIP permettant :
- interface privée+publique+squelette multilingue
- possibilité de traduction des articles,rubriques et brèves

Y'a t'il déjà un groupe qui travaille sur l'internationalisation de SPIP ? Si
oui, y'a t-il une mailing liste et quel est l'avancement ?

J'ai commencé à bosser sur une doc + fait des modifs dans le code
(en posant qu'on ne travaille qu'avec des langues iso-8859) ;
mais je ne me rends pas compte de toutes les implications car je ne connais
pas SPIP à fond et si un groupe travaille déjà là dessus, autant joindre
mes efforts à ce groupe : comment puis-je aider ?

Florent

Y'a t'il déjà un groupe qui travaille sur l'internationalisation de SPIP ? Si
oui, y'a t-il une mailing liste et quel est l'avancement ?

C'est la liste spip-dev, et on sait comment on veut procéder, ce qui est un
bon début. :wink:

Reste à trouver un peu de temps pour commencer, pour montrer ce qu'il faut
faire, puis vous laisser finir la récupération des chaînes à traduire, puis
les traductions :wink:

mes efforts à ce groupe : comment puis-je aider ?

J'ajoute ton nom comme futur "champion de la version occitane". On devrait
commencer dans le mois qui vient.

Merci

-- Fil

Y'a t'il déjà un groupe qui travaille sur l'internationalisation de
SPIP ? Si oui, y'a t-il une mailing liste et quel est l'avancement ?

C'est la liste spip-dev, et on sait comment on veut procéder, ce qui est
un bon début. :wink:

Reste à trouver un peu de temps pour commencer, pour montrer ce qu'il
faut faire, puis vous laisser finir la récupération des chaînes à
traduire, puis les traductions :wink:

Avez-vous prévu la traduction d'articles/brèves ou est-ce que ce sera juste
une version monolingue dans d'autres langues que le français (c.a.d seule
les interfaces sont traduites) ?

mes efforts à ce groupe : comment puis-je aider ?

J'ajoute ton nom comme futur "champion de la version occitane". On
devrait commencer dans le mois qui vient.

oula, attention, je n'ai pas dis que je voulais faire la traduction en
occitan : je n'y connais rien à l'occitan :slight_smile: En fait j'aide un
copain qui a ce besoin, et je lui passerai l'info, je pense qu'il
sera intéressé par s'ajouter à la liste.

Pour l'instant il ne s'agit que de la traduction de l'interface. Pour
les sites à contenu multilingue, la technique conseillée actuellement
est de passer par des mots-clefs.

Prévoir un système permettant une traduction des contenus demanderait
une refonte assez fondamentale de la structure de la base (pour résumer,
les articles sont identifiés uniquement par leur numéro, on ne peut pas
avoir plusieurs versions d'un seul article ; idem pour les rubriques,
brèves, etc).

La version en espanguoin est presque finie (il manque l'aide) et est à votre
dispo. Comment faut-il procéder? Il faut que je vous l'envoie où?
Luis
PS: excuse moi de l'envoyer en double, je me goure souvent avec les
réponses.

Ne suffit-il pas d'ajouter un champs "langue" pour chaque table gérant
un objet SPIP traductible, puis faire intervenir ce champs chaque fois
qu'il y a une requête vers la base.

Exemple :
spip_articles : ajout d'un champs "lg_article" + prise en compte de ce
champs dans la clé de la table.

Chaque fois que le champs "id_article" est référencé comme clé étrangère
(exemple : table lien_auteur_article), on ajoute aussi le champs
"lg_article")

lorsqu'on insère un nouvel aricle,
- si c'est une traduction, il a même "id_article" que l'article qu'il
traduit, "lg_article" différent
- sinon, il a un "id_article" différent de tous ceux utilisés (=
MAX(id_article)+1)

Quelles sont les limitations à cette solution ? (mis à part que c'est
quand même de la bidouille)

Ne suffit-il pas d'ajouter un champs "langue" pour chaque table gérant
un objet SPIP traductible, puis faire intervenir ce champs chaque fois
qu'il y a une requête vers la base.

Non : il y a 1001 manières de faire un site multilingue, il faut soit trouver
un système générique, puissant et cohérent, soit s'en tenir aux bidouilles.

Pour l'instant nous avons rendu spip plus ou moins compatible utf-8 ; sorti
tous les textes des images. La prochaine étape est l'internationalisation de
la partie privée ; puis il faudra traduire les formulaires publics et le
moteur typographique.

Après tout ça, on se reposera la question de la gestion d'articles "liés
entre eux" (versioning, multilinguisme, etc.) -- ou on partira en vacances
:wink:

-- Fil