> Le 2017 Here 18 à 07:54, Christian Quest <cqu...@openstreetmap.fr> a écrit :
> 
> Le 17 octobre 2017 à 19:22, Christian Rogel <christian.ro...@club-internet.fr 
> <mailto:christian.ro...@club-internet.fr>> a écrit :
> 
> Sur la page *name= en anglais, il est bien indiqué qu’il faut y mettre le « 
> default name », donc, si le nom est déjà mis par défaut, il n’y a aucune 
> raison logique de le doublonner, ou alors « default » compte pour du beurre.
> 
> La  précision :fr ne peut alors concerner que ce qui ne serait pas là par 
> défaut. C’est comme cela que ça marche dans la plupart des cas,où on se donne 
> la peine de définir une valeur par défaut.
> Quelle raison y aurait-il de déroger à la régle du défaut ?
> 
> avoir name + name:fr permet:
> 1) de savoir que name=* est en français si les deux sont identiques
> 2) de permettre un rendu où l'on peut favoriser une langue...
> 
> En effet, si on a juste name, rien ne me permet de savoir que ce name est en 
> français et que je peux l'utiliser en priorité pour le rendu "FR"... ou 
> alors, je suis obligé de faire une requête géographique en plus pour savoir 
> que comme je suis dans un pays où la langue officielle est le français (et 
> donc encore un appel à d'autres infos comme une relation type-default), j'ai 
> de fortes chances que ce name soit en français...
> 
> Pour mémoire le rendu FR utilise (dans l'ordre):
> - name:fr (c'est ce que je veux)
> - intl_name (car potentiellement écrit avec alphabet roman)
> - name (dernière pioche et de langue/alphabet inconnu)
> 
> Je comprends bien le risque de retrouver dans name des versions multilingues 
> pour de mauvaises raisons, mais à l'usage des données, avoir les deux 
> simplifie grandement les choses et les clarifiant !
> 
> Ceci représente très peu de données en plus dans la base, c'est marginal et 
> si on se pose ce genre de question il y a bien d'autres données moins utiles 
> qu'on pourrait du coup limiter.
> 
> Je suis donc partisan de doubler name et name:fr (et en plus ça permet de 
> détecter les name=* multilingues qui ne devraient pas l'être).

Si le point de vue du doublage prévaut, cela va donner des résultats curieux :

Les zones (très vastes) où les toponymes sont majoritairement dans une langue 
allophone se verront attribuer la quaité de « français » (c’est le sens de 
l’Histoire et on vient de le rappeler aux Catalans)., mais je suis très étonné 
d’apprendre que les quartiers de ma ville, dont le nom est en breton depuis des 
siècles vont magiquement être travestis en noms français (Stang Vihan, Stang 
Zu, Tréquéffelec, Créac’h Guen, Kerjestin,…)
Les zones trilingues (Alsace, Bretagne Est) devront être taggués name, name:fr, 
name:lang 1, name:lang 2 (ce sera génial pour les noms de voie)

En fait, si vous tenez tant que cela à votre truc, soyez cohérents, déterminez 
la zone où il n’y a pas de langue locale, afin de ne pas vous faire accuser 
d’impérialisme linguistique, dénonçable devant la communauté internationale 
(Mussolini a laissé de mauvais souvenir au Tyrol du Sud et au Val d’Aoste).

Vous pourriez l’imposer par un bot, mais, essayez d’aller le défendre sur la 
liste internationale OSM : vous n’y serez pas forcèment bien reçu, vu que c’est 
la « fête » des bots, en ce moment.


Christian R.
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Répondre à