[spip-dev] internationalisation des formulaires

Coucou,

je réfléchis à haute voix à l'i18n des formulaires de l'espace public.

A priori, il faut que ça soit optionnel, ce qu'on peut rendre soit par un
réglage dans l'espace privé, soit par l'ajout d'un tag #MENU_LANGUES, soit
les deux.

#MENU_LANGUES donnerait exactement le même menu que dans l'espace privé.

La langue par défaut des formulaires devrait être *celle du site* (ça fait
tache si j'ai un formulaire en anglais sur le Monde diplo seulement parce
que je le regarde avec un Mozilla mal configuré...), et ne changer que si
quelqu'un clique sur le #MENU_LANGUES

Mais du coup je ne sais plus très bien à quoi sert le réglage navigateur
dans cette hypothèse... a priori ça n'est utile QUE dans l'hypothèse d'un
site multilingue, ce qui n'est pas pour tout de suite (mais peut-être pour
plus tard).

-- Fil

Mais du coup je ne sais plus trÚs bien à quoi sert le réglage navigateur
dans cette hypothÚse... a priori ça n'est utile QUE dans l'hypothÚse d'un
site multilingue, ce qui n'est pas pour tout de suite (mais peut-être pour
plus tard).

Pour moi, le réglage navigateur n'est pas une bonne idée. Personne ne configure jamais la langue par défaut de son brouteur. Du coup, genre sur uZine, quelqu'un qui utilise un brouteur pas configuré se connecte en anglais, alors que la langue par défaut du site est le français. Pour moi, tant que l'utilisateur n'a pas choisi, la langue est celle imposée pour le site, pas par un brouteur jamais configuré.

Par ailleurs, je comprends pas bien: j'ai cru comprendre que la langue par défaut servait à la fois à afficher "la bonne langue" par défaut, et également comme choix d'une langue "complÚte" pour quand on sélectionne une langue pas totalement traduite. Ca me semble poser problÚme: et si ma langue par défaut est une langue incomplÚte? Et que se passe-t-il si la seule langue proposée sur mon site est une langue incomplÚte?

A*

From nicolas@zepitt.net Tue Feb 18 08:13:40 2003

Return-Path: <nicolas@zepitt.net>
Received: from ns1.medialook.net (ns1.medialook.net [213.186.34.15])
  by miel.brainstorm.fr (Postfix) with ESMTP id 147231C89F9
  for <spip-dev@rezo.net>; Tue, 18 Feb 2003 08:13:40 +0100 (CET)
Received: (from root@localhost)
  by ns1.medialook.net (8.9.3/8.9.3) id IAA13067;
  Tue, 18 Feb 2003 08:13:39 +0100
Message-Id: <200302180713.IAA13067@ns1.medialook.net>
X-Mailer: NeoMail 1.25
X-IPAddress: 62.202.165.12
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
X-BeenThere: spip-dev@rezo.net
X-Mailman-Version: 2.1.1+
Precedence: list
List-Id: SPIP : developpement <spip-dev.rezo.net>
List-Unsubscribe: <http://listes.rezo.net/mailman/listinfo/spip-dev>,
  <mailto:spip-dev-request@rezo.net?subject=unsubscribe>
List-Archive: <http://listes.rezo.net/archives/spip-dev>
List-Post: <mailto:spip-dev@rezo.net>
List-Help: <mailto:spip-dev-request@rezo.net?subject=help>
List-Subscribe: <http://listes.rezo.net/mailman/listinfo/spip-dev>,
  <mailto:spip-dev-request@rezo.net?subject=subscribe>
X-List-Received-Date: Tue, 18 Feb 2003 07:13:40 -0000
Status: O
Content-Length: 1373
Lines: 33

Salut à tous,

Je sais que le sujet a déjà fait couler pas mal d'encre (http://listes.rezo.net/archives/spip/2001-12/msg00038.html et autres), mais l'idée d'éditer en wysiwyg me trotte dans la tête depuis pas mal de temps.

Ma configuration est particuliÚre, je vous en ai déjà parlé, j'utilise Spip pour un intranet (env. 500 personnes). Les rédacteurs sont des novices pour la plupart - ce qui est le but avec un CMS - et paradoxalement je leur explique qu'il faut utiliser des "codes" pour la mise en forme.

Comme je dispose d'une plate-forme homogÚne (Windows/IE), je peux en tirer parti pour en utiliser les spécificités, car la solution retenue IMPOSE Windows & IE.

Toutefois, quelques remarques :
- la solution est simple et légÚre, elle implique d'ajouter 1 seule ligne de code dans Spip (désolé, c'est pas une usine à gaz)
- elle impose Windows & IE, tout comme la macro Word impose Word et l'utilisation d'une éditeur HTML impose de disposer d'un éditeur HTML ; ça peut paraître stupide, mais c'est fou comme en entreprise on n'a pas forcément tous les outils disponibles sur tous les postes de travail
- la logique et le fonctionnement de Spip ne sont pas remis en cause ! aux utilisateurs de choisir ce qu'ils préfÚrent

Pour plus de détails et pour télécharger le code : http://www.zepitt.ch/spip/article.php3?id_article=10

Amicalement

Nico

From nhoizey@php.net Tue Feb 18 08:39:57 2003

Return-Path: <nhoizey@php.net>
Received: from kraid.nerim.net (smtp-102.nerim.net [62.4.16.102])
  by miel.brainstorm.fr (Postfix) with ESMTP id 665571C8202
  for <spip-dev@rezo.net>; Tue, 18 Feb 2003 08:39:57 +0100 (CET)
Received: from 192.168.1.30 (cleverage.net2.nerim.net [62.212.113.254])
  by kraid.nerim.net (Postfix) with ESMTP id 07DEC40F2D
  for <spip-dev@rezo.net>; Tue, 18 Feb 2003 08:39:57 +0100 (CET)
X-Mailer: The Bat! (v1.61)
X-Priority: 3 (Normal)
Message-ID: <1872690118.20030218083951@phpheaven.net>
In-Reply-To: <200302180713.IAA13067@ns1.medialook.net>
References: <200302180713.IAA13067@ns1.medialook.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-BeenThere: spip-dev@rezo.net
X-Mailman-Version: 2.1.1+
Precedence: list
List-Id: SPIP : developpement <spip-dev.rezo.net>
List-Unsubscribe: <http://listes.rezo.net/mailman/listinfo/spip-dev>,
  <mailto:spip-dev-request@rezo.net?subject=unsubscribe>
List-Archive: <http://listes.rezo.net/archives/spip-dev>
List-Post: <mailto:spip-dev@rezo.net>
List-Help: <mailto:spip-dev-request@rezo.net?subject=help>
List-Subscribe: <http://listes.rezo.net/mailman/listinfo/spip-dev>,
  <mailto:spip-dev-request@rezo.net?subject=subscribe>
X-List-Received-Date: Tue, 18 Feb 2003 07:39:57 -0000
Status: O
Content-Length: 2117
Lines: 69

Bonjour,

Les rédacteurs sont des novices pour la plupart - ce qui est le but
avec un CMS

Pourquoi les cibles d'un CMS seraient-elles plus particuliÚrement
"novices" ? Et "novices" en quoi d'ailleurs ?

paradoxalement je leur explique qu'il faut utiliser des "codes" pour
la mise en forme.

Il faut présenter cela comme des codes de mise en exergue, et non de
mise en forme.

Ainsi, plutÃŽt que parler d'italiques, tu peux parler de citation.
PlutÎt que parler de graisse, tu peux parler de mise en évidence.

L'idée est d'identifier des parties d'un texte selon leur importance
ou fonction, et non selon leur mise en forme finale.

La non représentation dans l'interface de publication d'un italique ou
d'une graisse est alors tout à fait cohérente, et il serait même
judicieux qu'on puisse utiliser la feuille de styles pour symboliser
ces caractéristiques dans la partie publique comme on le souhaite.

Je pourrais ainsi dire que

  c'est {{trÚs important}}

soit transformé en

  c'est <span class="spipImportant">trÚs important</span>

plutÃŽt qu'en

  c'est <b>trÚs important</b>

Libre à chacun ensuite de décider comment doit être mis en évidence un
texte de la classe "spipImportant" ...

- la solution est simple et légÚre, elle implique d'ajouter 1 seule
  ligne de code dans Spip (désolé, c'est pas une usine à gaz)

Ce qui est simple n'est pas forcément bon ... :wink:

- elle impose Windows & IE, tout comme la macro Word impose Word et
  l'utilisation d'une éditeur HTML impose de disposer d'un éditeur
  HTML

J'ai édité pendant des années mon code HTML sans éditeur particulier !

la logique et le fonctionnement de Spip ne sont pas remis en cause !

Bin si.

Pour plus de détails et pour télécharger le code : http://www.zepitt.ch/spip/article.php3?id_article=10

Il suffit de voir le code HTML généré pour savoir tout de suite que tu
auras bien du mal à conserver une cohérence dans le site ...

-Nicolas

Pour moi, le réglage navigateur n'est pas une bonne idée. Personne ne
configure jamais la langue par défaut de son brouteur.

Non, car le brouteur arrive tout configuré avec le système
d'exploitation. La question ne se pose que pour les gens qui
installent un autre brouteur que celui d'origine, et sous réserve
qu'ils n'installent pas une version localisée. Ceux-là sont capables
en général d'aller modifier leurs préférences...

Il y a beaucoup de sites qui tiennent compte automatiquement de
la langue du navigateur. Au hasard : Google ; s'il s'affiche en
français, c'est que ton navigateur est configuré en français...

Ceci dit la langue des formulaires devrait être la langue du site,
tout simplement (si tu comprends des textes en wolof, tu peux
comprendre des formulaires en wolof...).

Par ailleurs, je comprends pas bien: j'ai cru comprendre que la langue par
défaut servait à la fois à afficher "la bonne langue" par défaut,
et
également comme choix d'une langue "complète" pour quand on sélectionne une
langue pas totalement traduite.

Hum, non. Quand une langue n'est pas complète, les chaînes sont bien là
mais certaines sont restées dans la langue d'origine (français ou
anglais en général).

Ca me semble poser problème: et si ma
langue par défaut est une langue incomplète? Et que se passe-t-il si la
seule langue proposée sur mon site est une langue incomplète?

Pour l'instant, le réglage des "langues proposées" a été désactivé car
ça ne fait pas beaucoup de sens (aucun intérêt à limiter le choix des
langues sélectionnables ;-)).

Hello,

je réfléchis à haute voix à l'i18n des formulaires de l'espace public.

Pas trop fort, ça dort encore ici ... :stuck_out_tongue:

A priori, il faut que ça soit optionnel, ce qu'on peut rendre soit
par un réglage dans l'espace privé, soit par l'ajout d'un tag
#MENU_LANGUES, soit les deux.

Je ne suis pas sûr qu'il soit pertinent de gérer plusieurs langues
pour un formulaire si ce n'est pas proposé plus globalement par le
site ou la page.

La langue par défaut des formulaires devrait être *celle du site*

Ou de la page, donc, pour un site multilangue.

Mais du coup je ne sais plus très bien à quoi sert le réglage
navigateur dans cette hypothèse...

A détecter quelle langue utiliser lors de l'arrivée sur le site, comme
je le fais sur phpHeaven. C'est tout, mais c'est déjà pas mal ! :wink:

-Nicolas