Chapitre 4 : étiquettes SPIP à multiples sous-étiquettes et nom de langue

, par _Eric_

Introduction

Dans sa dernière version stable 3.2.1, SPIP définit une liste de 196 langues (fichier inc/lang_liste.php) dont 28 sont composées de plusieurs (2 ou 3) sous-étiquettes permettant de préciser la région, l’écriture ou une variante très spécifique à SPIP.

Les étiquettes des langues berbères

Les étiquettes « ber_tam » et « ber_tam_tfng » désignent respectivement le tamazight (avec un T) et le tamazight en écriture tifinagh. Néanmoins, aucune de ces deux étiquettes ne sont valides : si « ber » représente bien la famille des langues berbères et « tfng » l’écriture tifinagh, « tam » n’est pas un extlang valide pour l’IANA.

En cherchant dans le tamazight dans le site SIL.org on constate qu’il y a 4 références de langues tamazight qui possèdent un code alpha-3 ISO 639-3, à savoir, le Tamazight Tidikelt « tia », le Tamazight Temacine « tjo », le Tamazight d’Atlas central « tzm » et le Tamazight marocain standard « zgh ».

Etant donné qu’il existe des traductions en « ber_tam » dans SPIP il faudrait déterminer quel tamazight est traduit et choisir l’étiquette correspondante. Pour le « ber_tam_tfng », le mieux est de supprimer la langue car aucune traduction n’existe.

Les étiquettes de créole

Les étiquettes de créole « cpf_hat » et « cpf_dom » désignent respectivement le créole haïtien et le créole dominicain. Néanmoins, aucune de ces deux étiquettes ne sont valides : si « cpf » représente bien la famille des créoles, ni « hat » ni « dom » ne sont des extlang valides pour l’IANA.

Mais il existe aujourd’hui pour ces deux langues des étiquettes simples qui selon la règle d’or R0 devraient être utilisées. Le créole haïtien possède même une étiquette ISO 639-1, « ht », qui doit être choisie au profit de l’étiquette ISO 639-3, « hat ». Le créole dominicain lui ne possède qu’une étiquette ISO 639-3, « acf ».

Il est donc souhaitable de renommer l’étiquette SPIP du créole haïtien en « ht » car cette langue est déjà traduite. Pour pour le créole dominicain qui ne possède aucune traduction sur la zone ni sur Tradlang, le mieux est de la supprimer.

Les étiquettes d’occitan

SPIP propose plusieurs variantes de l’occitan. Jusqu’à aujourd’hui il n’y avait pas d’étiquette spécifique pour ces variantes. Mais depuis avril 2018, l’IANA a intégré 13 variantes de l’occitan (type égal à variant). Il serait donc naturel de modifier les étiquettes SPIP en utilisant la composition avec variante comme expliqué dans l’article Chapitre 2 : règles de construction des étiquettes de langue (en utilisant le souligné et pas le tiret) :

  • « oc_auv » deviendrait « oc_auvern »
  • « oc_gsc » deviendrait « oc_gascon »
  • « oc_lms » deviendrait « oc_lemosin »
  • « oc_lnc » deviendrait « oc_lengadoc »
  • « oc_ni » deviendrait « oc_nicard »
  • « oc_ni_mis » deviendrait « oc_grmistr »
  • « oc_prv » deviendrait « oc_provenc »
  • « oc_va » deviendrait oc_vivaraup

Il reste le « oc_ni_la », désigné par òc niçard (larg) et qui semble être une déclinaison du nicard. Comme le tag « la » n’est pas valide dans ce contexte pour l’IANA il faudrait utiliser une étiquette d’usage privé pour SPIP qui caractérise cette déclinaison. L’étiquette finale pourrait être « oc_nicard_x_larg ».

Les étiquettes régionales

Les étiquettes SPIP « es_co » et « pt_br », si on excepte le fait que la forme canonique possède un tiret et que les étiquettes « co » et « br » sont en majuscules, désignent bien respectivement l’espagnol parlé en Colombie et le portugais parlé au Brésil. Ces étiquettes sont valides et peuvent être conservées.

De même pour l’étiquette « zh_tw », si ce n’est que le même problème se pose sur l’étiquette « zh » qui désigne une macro-langue et non une langue individuelle (voir article Chapitre 3 : étiquettes SPIP alpha-2 et alpha-3). Il faudrait donc vérifier de quelle langue individuelle chinoise cette traduction est une déclinaison taïwanaise ?

Pour l’étiquette es_mx_pop, Mexicano a lo güey, les choses sont plus complexes. Le tag mx présuppose que l’on est en présence d’une déclinaison mexicaine de l’espagnol. Mais le suffixe pop n’est pas une variante valide pour l’IANA. Ce suffixe semble vouloir exprimer que cette variante du mexicain est une variante populaire. Pour être plus conforme à la norme des étiquettes il faudrait plutôt utiliser un tag d’usage privé et renommer l’’étiquette en « es_mx_x_guey ».

Les étiquettes avec écriture

Les étiquettes « sh_cyrl » et « sh_latn » sont invalides à plusieurs titres. Comme expliqué dans l’article Chapitre 3 : étiquettes SPIP alpha-2 et alpha-3, l’étiquette sh est une macro-langue dont l’utilisation en tant que langue individuelle est dépréciée depuis l’intégration des langues individuelles serbe, croate, bosniaque et monténégrine.

Il faudrait en premier lieu déterminer de quelle langue individuelle on parle. Ensuite, suivant la langue, l’écriture par défaut diffère et cela veut dire que l’une de ces deux étiquettes pourrait être redondante car il ne faut jamais suffixer avec une écriture par défaut (on ne met jamais « latn » pour le français). Enfin, sachant qu’il existe déjà les étiquettes « sr », « bs » et « hr » dans SPIP, il faudrait vérifier si la langue n’est pas présente deux fois.

Maintenant, « sh_latn » n’est pas traduite ni sur Tradlang ni sur la zone. Le plus simple pour cette étiquette serait de la supprimer.

Les étiquettes particulières de SPIP

L’étiquette « fr_lsf » désigne pour SPIP la langue des signes française mais n’est pas valide au sens de l’IANA. Or, depuis l’ISO 639-3 il existe un code alpha-3 pour désigner la plupart des langues de signes, dont celle du français qui possède le code « fsl ». Il faut donc renommer l’étiquette « fr_lsf » en « fsl » ou sinon comme elle ne semble pas traduite la supprimer.

Les autres étiquettes sont plus exotiques. Aucun des suffixes accolés aux langues individuelles française, anglaise et italienne ne sont des variantes valides pour l’IANA. Il faut donc considérer que ces déclinaisons sont des usages privés de SPIP et utiliser la notation adéquate (voir l’article Chapitre 2 : règles de construction des étiquettes de langue. Une proposition est fournie dans le tableau suivant :

Code actuel Nom Nouveau code proposé Commentaire
en_hx H4ck3R en_x_hack
en_sm Smurf en_x_smurf Non traduite (ni Tradlang, ni sur la zone). Peut être supprimée
fr_fem français féminin fr_x_fem
fr_lpc langue parlée complétée fr_x_lpc Non traduite (ni Tradlang, ni sur la zone). Peut être supprimée
fr_sc schtroumpf fr_x_smurf
fr_spl français simplifié fr_x_spl Non traduite (ni Tradlang, ni sur la zone). Peut être supprimée
fr_tu français copain fr_x_tu
it_fem italiana it_x_fem

Les noms de langue

SPIP affiche le nom d’un code de langue dans la langue du code. Néanmoins, il existe beaucoup de langues non encore traduites qu’il conviendrait de corriger en utilisant par exemple Wikipedia. Le nom est inclus dans le fichier SPIP inc/lang_liste.php.

De même, il serait intéressant de conserver aussi pour chaque code le nom en français et/ou en anglais, voire de mettre en place une traduction multi-langues un peu comme pour les plugins, pour que les non locuteurs puissent comprendre de quelle langue il s’agit.