Я слышал, что либре развился и молодец, но единственное, что отталкивало - это медленный джавовый интерфейс ппц

или Qt, чего там они используют

Периодически использую для некоторых задач. В принципе он норм, но есть особенности:
1. Действительно, приложения пакета долго запускаются. Есть встроенный костыль для быстрого запуска.
2. Нормальная проверка грамматики - через дополнение LanguageTool, которое, в свою очередь, требует установленной JRE.
3. В Calc формулы на латнице. Непривычно, если работаешь в русской версии Excel.
4. До сих пор не работает корректно с масштабированием интерфейса Windows: если масштаб отличается от стандартного - иконки кнопок превращаются в мутное нечто.
5. Вроде не совместим с VBA-макросами MS Office
6. Мозг ломается от разницы в интерфейсах MS Office и LibreOffice.

не далее как год назад получали фидбек от клиентов, которые открывали наши сгенерированные DOCX в LibreOffice на линуксе: TOC рассыпается, автообновляемые поля иногда отваливаются, шрифты выглядят чуть-чуть не так

Эх.. звучит это все так себе, хотя казалось бы, почему гуглдокс умеют, а проект, который вроде как нужен толпе - нет)

Мы скомпилировали ваше приложение на Java c помощью компилятора C# и вот что нам не понравилось...

короче, в итоге это всё начало напоминать кросс-браузерную верстку: надо просто помнить, что разные клиенты смотрят разными просмотрщиками, и адаптироваться под это

#wanted_tw  #Москва #english #fulltime
Срочно нужен тех писатель Revizto для написания документации на англ языке (https://www.linkedin.com/company/revizto/) .
Тысячи пользователей по всему миру.
https://www.youtube.com/watch?time_continue=5&v=y27s9Gwh490
Вилка: 150 000 - 190 000 р (на руки).
Требования:
•Продвинутый уровень английского языка Upper Intermediate/Fluent (разговорный и грамотный письменный);
•Опыт работы техническим писателем от 1 года;
•Умение систематизировать/структурировать информацию, мыслить логически, структурировано излагать информацию;
•Хорошее знание Windows, Author-it, других профильных программ;
•Умение работать в команде, ответственность, стрессоустойчивость.
•Навыки работы в Jira, Confluence;
•Приветствуются знание или представление о программах Autodesk Revit, Navisworks или AutoCAD.

Светлана Ожогина- HR Revizto (s.ozhogina@revizto.com, telegram +79037220510).

Форматы не изоморфные. Это был осознанный выбор безответственных товарищей

Единственный выход -- doc as code)

Привет всем.
У нас есть двуязычная пользовательская документация по сложному продукту. Есть регулярные (примерно раз в две недели) обновления в продукте.
Мы хотим каким-нибудь образом отслеживать все статьи документации, которые требуется обновлять.
Бывает так, что в статье, в которой не ждёшь, обнаруживается устаревший скриншот или какая-то ещё информация.
Наверняка кто-то сталкивался? Как решили?

docs-as-code, md

а как может обнаружится "в статье, в которой не ждешь"?

если обновления продукта или в интерфейсе есть - текст который будешь менять и скриншоты и прочие данные - вполне себе ожидаемые) у нас к примеру 265 статтей, каждая из них мультиязычна - 5 языков, и вот их все один человек знает, так как все писал и публиковал. если что поменялось - где именно поменять и сразу везде. не знаю какой тут может быть алгоритм
если статтей/страниц документации больше - больше людей просто на это обычно.
или в телеграмм бот должен оповещение присылать, а искусственный интеллект анализировать весь текст?

1. камменты в коде (у нас местами прямо линки на сорс доков)
2. automation скриншотов - написать software робот который будет скриншотить одни и те же экраны в приложении и сравнивать с имеющимися скриншотами (это из области фантастики, но видела доклад на тему)

3. включение писателей в команды разработки с самых первых этапов - слушать дейлики и смекать

> вот их все один человек знает, так как все писал и публиковал

увы, нет. многое писалось другими людьми

Да, автоматизация скриншотов — это очень круто. Подскажи подробнее про комменты в коде, вы указываете ключ задачи и по нему отслеживаете изменения?

А как у вас происходит онбординг новых техписателей?

Девелоперские тикеты. Их можно как минимум мониторить на предмет изменений, а в идеале документирование должно быть таким же этапом в жизни тикета, как тестирование (то есть ни одна фича/баг фикс не может считаться законченным, пока не будет аппрува от писателя)

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

какие-то доки автоматизированны через документационные модули, например если ты девелопер и добавляешь или удаляешь фичи (DSL, архетипы), то твоя ответственность - обновить include в документационном модуле, из которого в конце спринта генерятся списки фич