Deelight a écrit :
> >the management of member's language seems to be fixed
> 
> Parfait.
> 
> Il y ajuste un petit détail : si l'utilisateur est admin galette, il 
> semble qu'après login toute l'interface admin soit dans la langue par 
> defaut. Tu crois qu'on peut faire la même chose pour toutes les pages ?
> 
> Sinon j'étais en train de bosser sur la même chose que toi, mais tu t'en 
> es mieux sorti :)

La base de l'attribution d'une langue à une personne est la donnée
pref_lang présente dans la table galette_adherents. Il faut donc avoir
accès à l'id_adh de la personne qui est logée.

L'admin n'existe pas nécessairement dans cette table d'une part, et d'autre 
part les codes php traitent l'admin tout à fait à part, comparé aux 
utilisateurs ordinaires. Tout cela rendrait assez compliquée l'extension à 
l'admin de la gestion des langues.

Dans l'état actuel, cela marche ainsi :
- l'admin crée la langue par défaut des administrateurs, lors du premier
  lancement de Galette, ou lors de l'édition des préférences générales.
- il n'y a qu'une seule langue pour les admins.

Pour ma part je n'y vois aucun inconvénient, car
- si l'association est purement nationale, la langue des admins est
  connue et fixe.
- si l'association est plurinationale, il est suffisant que les admins
  utilisent une langue-pivot. Il serait anormal d'avoir des admins ne
  pratiquant pas cette langue-pivot, car ça peut mener à des
  dysfonctionnements graves de l'association.
- si les admins veulent un traitement fin des langues pour eux-même, il
  leur suffit de créer un compte d'admin et un compte d'utilisateur
  ordinaire. Ce fonctionnement est sain a priori, et un sysadmin qui ne
  saurait pas distinguer les situations d'administration des situations
  d'usage fait planer de gros risques de plantage sur l'outil
  informatique il me semble.

amitiés,                        Georges.

Attachment: signature.asc
Description: Digital signature

Répondre à