Хочу поделиться своим взглядом на перевод на русский язык и редактирование документации OSM. Может быть, кому-то пригодится. Или не нужно будет повторять аргументы в очередной раз, а просто можно будет сослаться на эту запись.

Во многих дискуссиях, начинавшихся после очередного клича “давайте все переводить документацию!” я говорил, что стремление перевести всё подряд лишено смысла. Для того, чтобы так говорить, у меня есть несколько оснований, которые подтверждены моим опытом. Понимаю, что мой опыт - частный случай, не более, однако для меня найденные закономерности работают.

• Значительное число участников (включая опытных) не читают документацию или не делают это в первую очередь. Опираются либо на то, что написано в preset-ах редактора, либо просто на умозрительное представление о назначении тех или иных тегов. Ярчайший пример тому - теги доступа для отдельных видов транспорта, которые в России употребляются ошибочно на порядок чаще, чем правильно.
• Толковые люди, которые читают документацию или не ленятся заглянуть туда повторно, чаще могут прочесть ее на английском или немецком, чем не могут.
• Брошенный клич “давайте переводить!” чаще всего стимулирует к деятельности не тех, кто может вдумчиво перевести и дополнить пояснениями, а тех, кому нечего делать. Потом те же самые, кто кричал “давайте …!” исходят желчью на тему того, как ужасно все переведено. А дрянной перевод сбивает с толку немногочисленных, но все же существующих людей, которые иногда читают документацию, но начинают с русскоязычной статьи. Отсюда, например, бредовое представление некоторых о том, что retaining wall - это вид земляного крепостного укрепления - кто-то косноязычный перевел, а кто-то за ним прочитал.
• Есть теги, которые не вызывают особых проблем в использовании (не важно, почему). Так зачем тратить на них усилия, если есть, вероятно, что-то более важное? Никакими кличами просто взять и привлечь к переводу и редактированию больше толковых людей нельзя. Этот ресурс - ограничен. Соответственно, его можно использовать случайным образом (нерационально) и в соответствии с какими-то приоритетами (рационально).

Повторюсь, что я опираюсь на свой опыт, который, естественно, не претендует на универсальность и истину в последней инстанции. Так вот, опираясь на него, я для себя выработал образ действий в отношении редактирования и переводов, который, как мне видится, позволяет более рационально распределять ограниченные усилия и получать не самый худший результат.

• Переводить и редактировать только то, в чем разбираешься. Если предметная область статьи далека от твоей компетенции - не лезь. Недостаток знаний по предметной области легко ведет к ошибкам и неточностям в переводах и объяснениях. А попытки разобраться в чем-то хоть и полезны, но отнимают время.
• Переводить и редактировать то, о чем спрашивают, что вызывает проблемы, с чем связаны частые ошибки в базе. Есть множество тегов, ключей и значений, применение которых не вызывает особых проблем или вызывает их очень редко. И наоборот. Возможность сослаться на четкую понятную документацию вместо того, чтобы в сотый раз повторять одно и то же - бесценна (как минимум, экономит время и нервы). Сами люди документацию обычно не читают, но если ткнуть им в нее - вероятность несколько выше.
• Стараться всегда исправлять явные ошибки и бред переводчиков в статьях, на которые по какой-то причине наткнулся.
• Дополнять, разъяснять, давать примеры, если возникают вопросы, на которые в документации нет явного или понятного ответа. Разъяснять местную специфику. Иногда простого перевода недостаточно из-за языковых или культурных различий. В этом случае обязательно нужно дать пояснение. Есть сущности, которых в других странах нет. Например, какой-нибудь кожно-венерологический диспансер. Тут сильно помогают примеры.
• Если какое-то обозначение или тег часто используются неправильно, писать в явном виде, что так делать не нужно. Российский правовой нигилизм силён, так что пока где-то не будет написано “так делать нельзя”, некоторые будут руководствоваться принципом “разрешено то, что не запрещено явно”.

Таким образом, если попытаться сформулировать это в двух словах, можно назвать это “приоритетом, ориентированным на проблемы”.