No, it's good to question (especially as you did it very politely). And the discussion for having the same name in different languages equal to the default language is perfectly valid. We had it on [talk-fr]... and I thought as you BTW ;-). But the case of multiple user language preference was raised.

And yes, [coalesce](http://www.postgresql.org/docs/9.5/static/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL) does the job, except in some case.
Let ave a IT/FR/EN preference. The user on a dynamic map would see the one with hyphens because the name:it is not given, not the name.

it is *not*, in French you have hyphens, not blanks as separator.
For alt_name:fr, it's because the alternative name is also valid in French. There is a subtle difference between I don't have the name, use the default one and this is correct in your language.

In fact that's one of my favorite shema for life cycle.
Some are complex, good for complex cases only:
osm.wiki/Comparison_of_life_cycle_concepts

Yes, you got it right.

You're welcome! The wiki is pretty good. Not always, but we can improve it.
According to start%20date=*?uselang=fr#Approximations, you should write 2019..2020 (not 2019/2020).
construction:railway=station instead of
railway=station so that people see the station is not in use yet.

Hi, can you please use osm.wiki/Railways#Life-cycle to add the expected start date?
construction:railway
start_date:2019 (or 2020)
The start date should not be part of the name.

OK, en fait c'est même disused comme lighthouse.
Et "Phare de Gravelines" en alt_name pour un wikipedia=fr:Phare_de_Gravelines en prime !

Bonjour, je vois que vous avez nommé le phare "Phare". Est-ce que le phare s'appelle vraiment "Phare" ou est-ce un phare (et quel nom a-t-il) ?

Chemin : Impasse des (59099764) : impasse des...
Il ne manquerait pas quelque chose ?

According to the wiki "place=locality" place=locality is used to name places without inhabitants but you've added place=locallity to objects (nodes) without names. Any reason for that?
Any reason

@4rch
no, there are international agreements and conventions, for instance the outer limit of a EEZ is 200 NM from the baseline (by default), for territorial waters it's usually 12 NM, 6 or 3 in some areas. That some countries may want something different (like the 200 NM extension of territorial waters), shouldn't be reflected by OSM expect if there is some consensus. If the referenced document, you can see for instance Ireland, UK and France making a common proposal for their shared waters.
About your comment to jptolosa87, I think you should explain what in why and maybe reformulate this part on the wiki (may be you did in a pm).

as jptolosa87 said, this is a claim and 4rch refers to a claim too. Being neutral doesn't mean to accept the de facto invasion of the EEZ! Grüße aus Frankreich/Greetings from France (apologize for the strange language - German - today it's the celebration of the end of WWI - a good day for trying to deescalate potential conflicts)

You seem to have added details on a non existing track / disused track.
Check http://www.sncf-reseau.fr/fr/projets-chantiers-ferroviaires/cartes/carte-interactive-reseau-ferre-francais for the current network (including track not currently open to the traffic)

indeed, for two reasons, the one you said and the one I said (eez are not rendered, not even on OpenSeaMap... yet).
Normally we should create a UNCLOS territorial water, describe Peru using this 12 NM border, add a "second Peru" for the claimed part, right? It would be neutral.

Hi, that's exactly what I'm saying: the 200 NM (i.e. the previous version) as eez is correct.
It's the eez border, and it was correct.
Do you mean that Peru considers its eez as being territorial water?
According to https://en.wikipedia.org/wiki/Territorial_waters, you're right but the rules for boundaries (at least on shore!) is to set the highest tag in the hierarchy (if a boundary separates two districts of two countries, the level is set to country).
Using this rule, the border_type should remain eez.
http://www.marineregions.org/eezdetails.php?eez_id=138 shows the eez, and that's correct.
Moreover according to http://www.indexmundi.com/peru/maritime_claims.html, its a claim, not a decision.

BTW, I was looking at eez already described in OSM, using overpassturbo :
http://overpass-turbo.eu/s/c0B
And suddendly I saw the (to me at least) strange territorial water of Peru.
If you don't say boundary_type=administrative the display is not correct?
Then the renderers have to be updated, not the data - I mean 200 NM=EEZ).

Hi, you've changed the border_type from eez to administrative, this is wrong, as the sea-side territorial boundary is the 12 NM, not the 200 NM boundary. As stated in boundary=maritime#Territorial_sea_.2812.C2.A0nm_zone.29 :
This line should also be member of the border relation surrounding the country.

Well, the comment is valid, but it's not you that set the wrong boundary level for way/224452841.

Please DON'T touch the boundary at sea side except if you exactly know what you're doing.
The casdastre is NOT a reference in any way for country boundaries. Boundaries at sea are 12 MN from the shore, it is NOT the coastline..

un arbre ne s'appelle pas "arbre", c'est un arbre.
"name" n'a de sens que pour un nom spéficique d'un arbre par exemple "arbre de la liberté"

bonjour, les défébrillateurs doivent être tagués
emergency=defibrillator
pas :
highway emergency_access_point
(très peu utilisé en France, correspond à des points de référence pour les secours, par exemple pour retrouver quelqu'un sur la pointe du Raz)
name:br DEFEBRILLATEUR
(name:br veut dire nom en breton).
Si possible mettre l'endroit exact pas "seulement" la salle polyvalente.