Most larger and popular OSM projects (for example iD) host their translations on transifex, using a different platform massively wastes translator time and leads to diverging translations for the same terms.

I’m not saying that weblate is bad, simply that there is little value in not using transifex but lots of advantages if your project is part of the OpenStreetMap organisation, including to be able to use the 1000s of already existing translations.

Seuffzz da du es genau wissen wolltest, dass du daneben liegst:

https://github.com/openstreetmap/openstreetmap-website/commit/9c2de4039c3053c35e76f596faa95557dc237c74

November 2010.

a) die Option gibt’s mindestens seit ich mappe (2010) b) früher war potlatch, dann potlatch2 als Default eingetragen, seit 2013 iD

Das ist auch so oder so vernünftig, da man schon lange nicht mehr davon ausgehen kann, dass Flash im Browser unterstützt und vorhanden ist (JOSM ist aus naheliegenden praktischen Gründen dafür auch völlig ungeeignet)..

Die “aktive Mapper” Definition soll einfach ein gewisses minimales aktuelles Interesse an OSM nachweisen, naturgemäss bevorzugt es ein bisschen Leute die “neu” sind, aber dafür fallen Leute auch relativ schnell heraus. Wenn man den Passus genau liest, sieht man aber auch, dass man zusätzlich zu den “Mapping” Kriterien auch noch:

• eine funktionierende e-mail Adresse haben
• und innerhalb von 3 Wochen auf eine e-mail reagieren muss

in der Praxis dürfte dies mindestens eine gleich grosse Hürde sein.

@DannyMcD place mapping is an issue worldwide and the situation that settlements do not match up with administrative entities is fairly common. There are a number discussion on the subject, some current, in the openstreetmap-carto repository.

@farhadGuli what do you mean with “map loading”?

Except that there was and is already the widely used builiding:levels tag meaning something completely different.

The discussion is getting slightly silly now. We had to choose a default numbering and regardless of which one we would have chosen somebody would have been unhappy.

That said the schema with the ground floor/parterre being numbered as 0 or not at all, and the 1st floor up being number 1 is really very common with literally millions of building being numbered that way.

If regionally your level numbering skips 0 for the ground floor, aka goes directly from -1 to 1, you can simply add non_existent_levels=0 to the building outline and apps that are aware of this will not display 0 as a choice.

@Stalfur I think you will find major parts of Europe disagree with you.

In any case as I’ve pointed out differing numbering schemes etc, can be recorded in level:ref

@joost note that my statement that a large number of the new mappers in the US are SEO spammers is -not- based on the different workday - weekend patterns. It is based simply on the findings of investigating the large increase in incoming new mappers in the states starting end of 2016, which are in the 1000s of SEO spam accounts. If these were filtered out (many different ways possible) you would find the US even more overrepresented as it is.

I’m sure the numbers are accurate for what they are actually measuring (the OS versions of the devices installing via/accessing the play store). That does not mean that they are an accurate measure or proxy for the OS versions of the devices actually in use in one form or the other, which tends to be implied.

The sub 4.4 (non inclusive of 4.4 and mid 2018) portion of installs via the play store is 3% for Vespucci. But I wouldn’t expect most such device owners to install via the play store in the first place (more likely from F-Droid, from our repo, own builds etc).

We don’t have any numbers from any of the other ways of installing and except if we would start to record OS version in changeset tags, which I wouldn’t consider a good idea, we are simply never going to know the details (outside of OS version specific regressions, which has happened now and then :-/).

You are falling for Google marketing.

There is already a level:ref tag defined in SIT that can be added to the level outline for level names or very different numbering.

PS S3DB doesn’t have a level tag and when the concept of levels is used it is as a proxy for the height of the element.

Consider that you have OSM data in some kind of data store and need to determine which languages are supported for your hotel example.

PS: as to the list becoming “long”, all modern editor UIs allow you to select from a list regardless of the underlying data representation.

“schreiben aber lieber auf Baseldytsch” es gibt keine allgemein anerkannte Schriftform des Schweizerdeutschen, was ja Teil des Problems ist.

Das Problem ist eher, dass name:gsw so unspezifisch ist (nur schon in der Schweiz), dass es eigentlich sinnlos ist es in der Form überhaupt zu verwenden.

Im Gegensatz aber zum Gebrauch in FR und DE ist Schweizerdeutsch nicht am aussterben und dass ist vermutlich auch der Grund wieso sich die ISO (und nicht nur die JOSM Entwickler) hauptsächlich daran bei der Auswahl des Kürzels und des Namens gedacht haben.

Es gibt aber keinen Grund wieso wir nicht gsw_CH, gsw_FR, und gsw_DE verwenden könnten, auch wenn das für die Schweiz immer noch beliebig unscharf wäre.

All projects that are in the OpenStreetMap organisation on transifex can (and do share for the majority) translations. That means you can auto-fill exact matches from other projects translations.

For historic reasons the OSM website is translated somewhere else and that would be difficult to change, anything else could likely easily move to transifex.

PS: I’m not a particular transifex fan, but it works well enough for our purposes and avoids us having to run yet another service ourselves.

Sorry but you still haven’t explained -where- you have the issue, in transifex? (can’t reproduce that there), in id (assuming that you are referring to the translations of iD presets) ? or somewhere else?

Could you explain this a bit better? Perhaps with an example?

Thanks

I’ve discussed this with imagico before.

IMHO

• while it can argued that having a non-github like issue tracker would remove the real or imagined bias towards software developers, it is however unlikely that the devs would want to give up the tight integration of the issue tracker with git that github-like systems provide. Having two -different- public issue tracker systems (plus trac for JOSM and itrs internally) would be a step back from what we do today,
• in the end gitlab has exactly the same issues as github and what we would want is something thta allows single sign on with osm,org. That would for example be possible with a self-hosted instance of gitea.