While all of that is true, none of it is applicable for new mappers which by definition could not have experienced any of the issues you mentioned (outside of iD not working at all, which would have naturally stopped them from being counted).
Did I claim that Vespucci had a significant user base? Donât think I did.
Actually Iâm on the (broken) record of poining out time and time again that the fractured OSM editor landscape is insane and doesnât make any sense at all. Rapid just has the same issues in that respect as essentially all the others (it simply has the advantage of having a deep pocket sugar daddy).
Isnât this just the natural outcome of decentralized software development with an open API?
How else would it work?
1 Like
Thatâs just a precondition.
( my comment )
If English is your native language or youâre proficient in it, you wonât find this problematic.
However, there are two main issues with translations:
- The translation is not fully completed - or low quality - in the given language.
- There are known mistranslations that may have already been corrected (e.g., in Transifex) but will only be included in a new release in 2-4 months ( and can cause OSM data problems )
Therefore, in a pop-up window regulated by OpenStreetMap.org, a message similar to the following could appear in the browserâs language setting:
- ~ This editor is only 30% translated into your language, so itâs not recommended for beginners.
- ~ There are known translation errors that havenât been released yet (see the
<<wiki page>>for detailed issues). We ask the editor to exercise greater caution.
The problem is that many donât consider translation issues with OSM objects to be critical, so thereâs rarely an urgent program release because of this. Unfortunately, in this regard, smaller languages will never be equal.
It would be beneficial if the community of the given (non-English) language had the opportunity to place a warning before any external editor is called from osm.org.
The Rapid-editor Translation Status:
Low translation percent examples:
- Estonian: 46%
- Croatian : 32%
- Slovenian: 27%
- Latvian: 26%
- Romanian: 20%
- Albanian : 17%
- Indonesian: 17%
- Filipino : 9%
- Hindi : 3%
- âŠ
iD editor :
- Finnish : 61%
- Estonian : 56%
- Croatian: 36%
- Bulgarian: 32%
- Icelandic: 29%
- Lithuanian: 25%
- Slovenian: 25%
- Irish: 22%
- Romanian: 22%
- Latvian: 22%
- Albanian: 6%
- âŠ
An OSM Editor may have to handle more than 200 languages, and it is unreasonable to expect developers to guarantee quality for every language. However, there should be some warning mechanism for language communities to at least send a brief message to other OSM editors in the given language.
These statistics are unfortunately quite misleading: the total would include many strings that translators normally donât need to translate, such as placeholder strings for synonyms of preset names (what if thereâs no synonym for it in your language?), as well as a ton of strings advertising local communities as part of osm-community-index. Personally, I havenât prioritized translating the full description of a local YouthMappers chapter at a university in Tanzania into Vietnamese, to give just one example.
I think itâs high time to split the id-tagging-schema, editor-layer-index, and osm-community-index strings into separate translation projects. Not only would this give everyone a clearer idea of translation coverage, but it would also keep translators from feeling overwhelmed. These other projects would be able to update their strings independently of iDâs release schedule. And it would be easier for iD forks and other projects to leverage these translations, promoting multilingualism across the board.
Anyhow, Transifex gives projects the ability to define a cutoff percentage, below which it doesnât pull in any translations for the language. As far as I know, iD doesnât make use of this cutoff; it only considers translation coverage when deciding which language to fall back to for a given string.
1 Like
(How) do you want this in the editor inclusion policy?
I can create only a simple spec:
( using âenglishâ in this example, but think as an Non-english ( Albanian , Hungarian, etc ⊠) )
Now:
Expected :
Proposal UI (Example) :
-
Edit with iD (in-browser editor)
- Good translation in your language!
- Warning: 2 mistranslated OSM tags, be careful! [Links]
-
Edit with Rapid (in-browser editor, sponsored by Microsoft)
- Translation error expected in your language, please help fix it [Links]
- Warning: Please donât import buildings in Eastern Hungary due to low quality. [Links]
Metadata
somewhere the metadata stored :
- .github.com/openstreetmap/osm_editor_lists/meta.ymal
languages:
- language: hu
edit_tools:
- tool: iD
description: In-browser editor
msg1: Good translation in Hungarian
msg2: Warning: 2 mistranslated OSM tags, be careful! link: [Links]
- tool: Rapid
description: In-browser editor, sponsored by Microsoft
msg1: Translation error expected in Hungarian, please help fix it. [Links]
msg2: Warning: Please don't import buildings in Eastern Hungary due to low quality. [Links]
The YAML - HU - metadata can be updated by a GitHub issue authorized by 3 HU-OSM community members.
The community can receive a warning within a day, whereas the SDRP might take weeks. In the summer, developers might be on vacation, which could cause delays.
As discussion has settled down, Iâm going to do another round of pulling out and summarizing feedback on the policy. Thereâs been a lot of good discussion on related issues, but only a couple specific points of refinement on the policy itself.
On the topic of imports, there was a fuller articulation of a recommendation that the policy addresses concern that new editors do not inappropriately lower barriers to importing. Such barriers are necessary to ensure community review and limit importing to users with higher technical proficiency.
There was also a suggestion that this suggestion be a bullet included in the final section:
Clarify (para 2) that the criteria are the minimum to be accepted, and that the OSMF board still has the ultimate decision whether to accept or reject.
3 Likes
Are you sure about this? Then what about this
For context of who didnât saw that on twitter
Basically it was suggested in the official account on social media to delete previous content to the tool be able to suggest new predictions.
2 Likes
As Bryan mentioned, âthis workflow is only for situations where the existing buildings are not worth keeping.â
If edits are removing buildings that should not have been removed, this is not something we want to see. Your point about the risks of encouraging deletion are valid and Iâll bring this up again with the team along with the risks posts like that create.