Обновить
4K+
10
Валерий Ледовской@Goudron

Product Manager

12
Рейтинг
3
Подписчики
Хабр КарьераХабр Карьера
Отправить сообщение

Вероятно, этот вопрос можно будет решить в рамках следующего этапа моей работы в этой теме - проверка грамматики и стилистики. В рамках этой работы дополнение может определять, в каком стиле пишет пользователь (использует ли он по тексту ё) и делать предложения, исходя из того, ёфикатор он или нет :) А анализ только лишь орфографии не способен это определять по определению. Нужен дополнительный слой, но решаемо.

Именно так :) Я ещё решил поработать с грамматикой. Там, правда, сложнее, но выполнимо. Скрин для затравки. Хочу, чтобы грамматические ошибки подчёркивались синим, а стилистические - зелёным с отображением того, что не так и предложениями по исправлению. И чтобы оно при этом работало достаточно быстро. На скрине концепт, что в принципе это работоспособно. Для Firefox и Thunderbird будут разные расширения.

Я сам ёфикатор. Но часто это связано с комплайенсом. Например, если вы пишете техническую документацию, новости или книгу, которая будет издана, корректоры/редакторы будут у вас ё убирать, если её отсутствие не может привести к неоднозначности.

Над такими открытыми словарями обычно работают ИТ-энтузиасты. Например, я до бага, упоминаемого в статье, этим не занимался, но вот занялся, ибо есть потребность и мои руки. У меня тоже есть такие скрипты, которые отбирают кандидатов. Корпус Хабра использовался. Вопрос в том, стоит ли добавлять всё, что можно добавить. Я над этим буду ещё думать. Словарь не должен быть огромным. Из-за частотности что-то может отсекаться. Если это обычные слова, часто применяемые, добавлять можно. Спасибо за коммент, буду думать, что можно будет из ваших наблюдений вытянуть :)

Интересная тема, спасибо за коммент. Попробую провентилировать, как будет время. Тоже вопрос, касающийся локализации в смысле i18n, а не l10n :)

Всё подряд, может быть, и не стоит, но устоявшийся технический жаргон считать за ошибку в современном словаре орфографии всё же не стоит, потому что он используется. В таком орфографическом словаре должно быть побольше распространённого узуса, который используется намеренно. Это не словарь нормированного языка. Скорее, словарь разговорной (прямой) письменной речи (в т.ч.). Кстати, вот выявил, что слово "узус" этот мой словарь считает ошибкой. Есть нормированный (официальный) русский язык. Но этот мой словарь не про это. Это про орфографию в ежедневном реальном использовании языка. Другая несколько функциональность (кстати, специалисты РАН на Грамоте.Ру считают, что "функционал" вместо "функциональность" в ИТ уже тоже можно не считать ошибкой) :)

В статье не всё, что попало в словарь. Конкретные слова лучше проверять по факту, подчёркиваются или нет. По возможности в таких случаях включаю оба таких варианта. Но спасибо за коммент. Проведу отдельную проверку по этой теме.

Спасибо. Добавляю в список слов на проработку.

Я учил английский, переводя романы :)
Все эти аргументы некритичны. В профессиональном сообществе есть некоторые правила корректного поведения. Многие из комментаторов вообще практически не публикуют статьи. У меня на этом ресурсе тоже пока одна :) Я не ленив, но думаю, о чём писать. Ибо есть. Давайте будем более терпимы друг другу. Это был смысл моих комментариев. В жизни и так много объективно неблагоприятных факторов.
Изначально в статье был указан основной фактор закрытия соцсети. Вы пытаетесь лезть в бутылку, это тоже непрофессионально и не стоит тех минусов. Это непохоже на обсуждение инфоповода.
Я считаю, что автор не поспешил со статьей. И утечка данных не основной фактор свёртывания работы соцсети. Неприятно, конечно, что в очередной раз утекли данные. Но это происходило хотя бы раз у любого более-менее крупного сервиса, который работает продолжительное время. Именно поэтому рекомендуют периодически пароли менять независимо ни от чего. Зря минусуете автора. Это непрофессионально.
Документация писалась на этих стендах не о продуктах VMware, а о продуктах _для_ виртуальных сред на основе VMware vSphere. В нашем случае мы писали доки об антивирусах и других продуктах из области ИБ для этих сред. И авторы в таких случаях технические писатели, которые были специалистами по ИБ, а не по продуктам VMware. Т.е. речь о том, чтобы быстро овладеть объектом документирования, который работает в таких средах (см. примеры внизу статьи, для каких публикаций это делается). Что касается песочницы, то в таком случае она не подходит, ибо придётся отправлять описываемый продукт на облако VMware. Это не всегда приемлемо, ибо вендор передаёт продукт для виртуальных сред автору и при этом должны соблюдаться условия NDA.
Не полезнее, если описываемый объект работает под vSphere.
Ставил так по накатанному. Потому что всегда так делал. И в инструкциях к продуктам в области ИБ, которые описывал, поддерживались именно такие компоненты. Понятно, что всё течёт, всё меняется. Поэтому и данный метод придётся корректировать. Но я думаю, что некоторое время он будет актуальным. Понимая, что предлагается в целом, можно дальше уже корректировать по ситуации. Здесь я попытался описать общую концепцию и возникающие на пути основные подводные камни.
Лишних слов для уровня ЦА здесь нет. То, что можно, не всегда доступно. Но спасибо за взгляд с «той стороны». Я там тоже долго работал, поэтому могу понять.
Жаль, если Вы так считаете. Ибо мало где эта информация есть. А практически применялась неоднократно. Многих интересных публикаций не было бы без этого. Я лично учил этому подходу нескольких авторов. При этом спасибо за мнение. Оно вполне понятно моим коллегам, которым нужно описывать это всё. При этом кто техписов пустит физически к виртуальным средам, находящимся в продакшне? Говорили бы Вы про мартышкин труд, если бы от документатора поступила просьба получить админский доступ к реальному такому объекту?
Мне такие ресурсы неизвестны. При возникновении проблем за долгое время использования демок в таком режиме мне хватало документации и видеороликов на Ютубе, в которых показывалось, как обойти те или иные трудности. Для этого необходимо владеть некоторым уровнем технического английского, но без этого по-любому будет сложно.
В моём и нескольких других случаев это было вынужденной мерой. Поставить на рабочую станцию пару десятков ГБ ОЗУ дешевле, чем покупать второй компьютер, на котором нужно тоже много оперативки.
Собственно, ответ на этот вопрос есть в статье. Технические писатели часто работают в удалённом режиме и у них нет отдельного ПК. Мне приходилось использовать свой домашний для этой работы. И приходилось ещё несколько людей учить аналогичным действиям.
1

Информация

В рейтинге
659-й
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность

Специализация

Менеджер продукта, Деливери-менеджер
Ведущий
От 400 000 ₽
Английский язык
Управление проектами
Разработка ТЗ
Agile
Управление людьми
Оптимизация бизнес-процессов
Стратегическое управление
Стратегическое планирование
Управление разработкой