АРМ переводчика

Только технические вопросы по ЯОС и MINOS. Терминология и прочее - в других форумах.
Ответить
БудДен
Сообщения: 2839
Зарегистрирован: 07.10.18 14:01

АРМ переводчика

Сообщение БудДен » 09.01.21 16:37

Поскольку процесс перевода собирается затянуться на годы, нужно как-то повышать производительность труда и автоматизировать его. Притом сама автоматизация должна быть разбита на мелкие этапы и завершение каждого этапа должно улучшать положение. Пытаюсь продумать.
Пока что процесс идёт согласно https://gitlab.com/budden/ja-o-s/-/blob ... перевод.md .

Что можно улучшить?
  • разбить единый файл перевода на много - по числу модулей. Видимо, понадобится ещё глобальная таблица с переводами именно имён модулей. Тогда загружать перевод можно при загрузке модуля.
  • использовать более лаконичный формат, чем XML. С учётом моего тёмного прошлого, напрашиваются S-выражения. В книжке Вирта что-то есть про них, может быть, где-то и парсер есть. Нужна ещё поддержка в ИСР. Можно ещё JSON5, но я не люблю JSON - он отстойный.
  • возможность от места ввода перевода переходить к месту, где определено имя. Особой проблемы с этим не было, пока я переводил последовательно. Теперь я стараюсь группировать переводы, например, сразу перевожу все переменные с именем error. Это может быть потокВыводаОшибок или ошибкаЛи, поэтому просто так сразу перевести нельзя - нужно смотреть в код. Значит, нужно сделать команду "перейти к определению, к-рая должна принимать одно из:
    • имяМодуля.имяЧлена.имяЧлена.имяЧлена
    • имяФайла@смещение
    • имяМодуля???смещение
    • имяФайла.имяЧлена.имяЧлена:счётчикВыполнения
  • возможность найти то же слово в комментариях и строковых литералах
  • разбить перевод на статическую часть (которая нужна только во время преобразования исходников) и динамическую (которая нужна для работы)
  • автоподсказка прецедентов
  • закрывать файлы, чтобы не было проблем с другими приложениями
  • рефакторинг "переименуй идентификатор" - он естественно вытекает из того же движка, но надо допилить.
  • интерфейс к словарю, в т.ч. возможность брать подстановки из словаря и в идеале даже добавлять слова в словарь, а также возможность
    вызова внешних словарей из интернета
  • в заготовке таблицы перевода указывать тип данных - иногда по нему сразу понятно, как переводить.
Ясно, что значки нужно подобрать так, чтобы они указывали на то, какой вид перехода к определению мы хотим.
Последний раз редактировалось БудДен 10.01.21 16:15, всего редактировалось 3 раза.

MihalNik
Сообщения: 244
Зарегистрирован: 05.11.18 11:02

Re: АРМ переводчика

Сообщение MihalNik » 09.01.21 19:07

http://plana.mybb.ru/viewtopic.php?id=766&p=3#p3900
Прошу обратить внимание на проблему случайного перекрытия.
Могут быть полезны объединения тезок по типам.

БудДен
Сообщения: 2839
Зарегистрирован: 07.10.18 14:01

Re: АРМ переводчика

Сообщение БудДен » 09.01.21 19:52

  • Очевидно, пора записать видео с описанием того, что я делаю и какой опыт я из этого извлёк.
  • И сопоставить этот опыт с данными предложениями.
Коротко:
1) м.б. что-то сломается: м.б. литералы, есть границы внешнего взаимодействия.
Старые английские имена остаются в виде динамических имён, поэтому вызов команд не сломается. Есть GETPROCEDURE - там тоже заплатка поставлена. Хотя где-то ещё может сломаться. Сейчас столкнулся с DSL для описания конфигураций сборки - хочу его слова перевести на русский, это будет ломающее изменение. Уже продублировал на русском встроенные команды командного интерпретатора (оболочки) ОС, но это отдельная ручная работа вне обработки собственно ЯП. Ещё один способ сломаться - это наследование. В Обероне override не помечается - пришлось эту возможность добавить в язык. И поставить ограничение, что имена методов в иерархии класса должны переименовываться в базовом классе.
2) м.б. внесена трудноуловимая ошибка, если захочется два слова перевести одинаково - это м.б. допустимо, а может и нет, может захочется разный перевод одного названия для разных, изначально одноименных сущностей. Нужно удобное (простое и быстрое) управление этим.
Обычно от этого защищает компилятор, пока не понимаю, как ещё может сломаться
3) простой перевод не всегда допустим - местами обрывки слов и отдельные буквы. Нужен разбор идентификаторов и сокращений. Хотя бы вычленение слов/поиск по началам/выборкам согласных.
По сути дела приходится понимать каждый идентификатор. Без этого перевод сделает только хуже.
4) нужны сами средства перевода - подключение словарей, возможно гугла и т.п. И для перевода и для подбора синонимов. Чтобы работа шла быстро.
Пока этого нет, но можно конечно дёрнуть браузер, который откроется в другой ОС - в самой ЯОС браузер слишком убогий.
5) нужно средство разделения труда - Git работает с текстами, а требуется разделение/управление/слияние переводов, т.е. одного слоя текстов соотнесенного с другим переводом. Он не может показать одной строчкой, что мы хотим заменить "release" на "выпуск".

Первое средство - это по-модульность, в теории порядок может быть любым, но унаследованные имена должны переводиться в базовом классе. Сейчас пока стараюсь брать модули с малым количеством ведомых - движок пока не идеально работает. Хотя пока я не готов делегировать кому-либо разрабоку переводов. Это ужасно сложно. Нужно набить руку, чётко формализовать процедуру и тогда можно будет.
6) лучший уровень работы - поверх AST, а не текста - проще квалифицировать безопасные замены, чего редакторы не умеют.
В реальности даже не поверх AST, а поверх результатов семантического анализа. Поскольку там уже делается разрешение констант и преобразование типов, пришлось патчить компилятор, чтобы эта информация не исчезала. Возможно, эта работа ещё не завершена. Там набор костылей, полного понимания процесса компиляции у меня нет.

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

MihalNik
Сообщения: 244
Зарегистрирован: 05.11.18 11:02

Re: АРМ переводчика

Сообщение MihalNik » 09.01.21 20:46

Обычно от этого защищает компилятор, пока не понимаю, как ещё может сломаться
Речь про то, чтобы в принципе исключить одинаковые имена для изначально по-разному названных переменных там, где возникнет перекрытие. Т.е. где-то могло быть "len", а где-то "l", а вдруг, мы переведем оба как "длина" и одна переменная перекроет другую? В т.ч. и совместимость типов возможна. Хотя и просто разбираться в ругательствах компилятора - это потеря времени из-за отсутствия безопасности преобразования.
Из вообще нерешённых вопросов - если я сначала перевёл, а потом мне перевод одного имени не понравился и пришлось заменить его другим, то это чисто ручная процедура. И если забыть поправить перевод, то он рассогласуется. По этой причине перевод - это пока что билет в один конец. Но я думаю, что это более-менее норм.
Не годится для применения более чем 1 человеком.
Последний раз редактировалось MihalNik 09.01.21 20:51, всего редактировалось 1 раз.


БудДен
Сообщения: 2839
Зарегистрирован: 07.10.18 14:01

Re: АРМ переводчика

Сообщение БудДен » 09.01.21 20:59

MihalNik писал(а):
09.01.21 20:46
Обычно от этого защищает компилятор, пока не понимаю, как ещё может сломаться
Речь про то, чтобы в принципе исключить одинаковые имена для изначально по-разному названных переменных там, где возникнет перекрытие.
Да, похоже, что это серьёзная проблема, и я её упустил. Что делать - пока не понимаю. С другой стороны, похоже, что ещё ни разу на эти грабли не наступил (или просто не знаю об этом). Было такое, что я две переменные в одной области видимости одинаково перевёл, там сразу была ошибка компиляции. Но в другом случае может случиться и что-то похуже. А что именно? Локальная переменная перехватит глобальную и смысл программы изменится без ошибки. Что делать-то? Эта ситуация не из приятных, потому что обычно она в сложных местах возникает.
Из вообще нерешённых вопросов - если я сначала перевёл, а потом мне перевод одного имени не понравился и пришлось заменить его другим, то это чисто ручная процедура. И если забыть поправить перевод, то он рассогласуется. По этой причине перевод - это пока что билет в один конец. Но я думаю, что это более-менее норм.
Не годится для применения более чем 1 человеком.
Я бы сказал, что это либо вообще не годится (т.к. могут исчезнуть динамические имена, а это страшные грабли, с учётом того, что A2/ЯОС не всегда может дать обратную связь о результатах выполнения команды), либо это годится и для перевода более чем одним, если установить, что за каждый модуль отвечает один человек и что модуль (вместе со всеми ведомыми) на время работы над ним блокируется этим человеком. Во всяком случае, я слёту тут дальнейших грабель не вижу.
Думаю, если понимать опасность, прописать чёткую процедуру и следовать ей (менять и в словаре тоже), то будет норм.

MihalNik
Сообщения: 244
Зарегистрирован: 05.11.18 11:02

Re: АРМ переводчика

Сообщение MihalNik » 09.01.21 21:48

Дело в том, что переводить помодульно медленнее, т.к. совпадающие имена будут в разных модулях, кроме того, тогда одинаковые сущности могут оказаться названы разными синонимами, особенно если переводить будут разные люди.

[quote]Да, похоже, что это серьёзная проблема, и я её упустил. Что делать - пока не понимаю. С другой стороны, похоже, что ещё ни разу на эти грабли не наступил (или просто не знаю об этом). Было такое, что я две переменные в одной области видимости одинаково перевёл, там сразу была ошибка компиляции. Но в другом случае может случиться и что-то похуже. А что именно? Локальная переменная перехватит глобальную и смысл программы изменится без ошибки. Что делать-то? Эта ситуация не из приятных, потому что обычно она в сложных местах возникает.[/quote]

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

БудДен
Сообщения: 2839
Зарегистрирован: 07.10.18 14:01

Re: АРМ переводчика

Сообщение БудДен » 09.01.21 22:32

MihalNik писал(а):
09.01.21 21:48
Дело в том, что переводить помодульно медленнее, т.к. совпадающие имена будут в разных модулях, кроме того, тогда одинаковые сущности могут оказаться названы разными синонимами, особенно если переводить будут разные люди.
Учитывая, что работа происходит урывками, по-другому пока не получится. Даже если переводит один человек, то у меня в памяти все переводы не удерживаются и я могу назавтра в том же модуле такую же сущность перевести другим именем. Работа должна допускать выделение частей, выполнимых за 40 минут. Кроме того, я вообще сомневаюсь, что движок в его текущем виде выдержит 800 файлов перевода - он, скорее всего, будет неприемлемо тормозить - я уже в жизни сталкивался и с парсерами XML, и с проблемами сборщика мусора в A2 - здесь проблемы ожидаемы. Так что, в продолжении темы про "билет в один конец", придётся уничтожать статическую часть словарей (внутренние имена) через некоторое время после перевода - или нужно много работать над качеством управления памятью в A2, а это сильное отклонение от магистрали.

Мне кажется, я придумал, что делать с перекрытием:
  • 1. сделать флаг компиляции, при котором перекрытие имён является ошибкой или предупреждением
  • 2. сделать поддержку полной квалификации любых имен, в т.ч. в процедурах и вложенных процедурах, а также в объектах и предках. При такой записи унаследованное имя поля объекта в его методе будет называться ИмяМодуля.ИмяТипа.ИмяПоля. А сам.ИмяПоля будет только для поля, введённого конкретно в этом типе. То же для имён в процедурах и глобальных имён текущего модуля. Что-то типа самм.ИмяГлобальнойПеременнойВТекущемМодуле.
    которое можно подавив, выписав имя полностью квалифицированным
  • 3. сделать режим рефакторинга, который автоматически квалифицирует все имена, страдающие от перекрытия
  • 4. отрефакторить все имена перед тем, как переводить
  • 5. всегда держать данный флаг включённым
Тогда компилятор предупредит о вновь возникающем перекрытии.
Вероятно, можно попробовать обойтись пп. 1 и 5, в случае, если будет рефакторинг "переименуй идентификатор" и количество перекрытий окажется небольшим.

БудДен
Сообщения: 2839
Зарегистрирован: 07.10.18 14:01

Re: АРМ переводчика

Сообщение БудДен » 10.01.21 17:00

Кстати, первое, с чего надо начать - это с определения доли выделяемых ресурсов. Думаю, это должно быть 25%. И распределены они будут помесячно. Т.е. январь - месяц перевода, февраль - месяц улучшательства. Дальше опять 3 месяца перевода и т.п.

Павиа
Сообщения: 136
Зарегистрирован: 23.05.19 21:28

Re: АРМ переводчика

Сообщение Павиа » 11.01.21 10:39

БудДен вы сильно усложнили себе работу. Переводить нужно лексемы, а не модули. Выделяете лексемы по всем модулям. Группируете одноименные лексемы. И делаете замену по таблице. После правок проверяете упало или нет.

БудДен
Сообщения: 2839
Зарегистрирован: 07.10.18 14:01

Re: АРМ переводчика

Сообщение БудДен » 11.01.21 16:30

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

Павиа
Сообщения: 136
Зарегистрирован: 23.05.19 21:28

Re: АРМ переводчика

Сообщение Павиа » 12.01.21 06:14

БудДен писал(а):
11.01.21 16:30
Перевод слова не может быть однозначным.
Если это разные идентификаторы с одной лексемой то да. Для этого и нужен парсер который такое выявит. Он же у вас уже есть и Вы с его устройством разобрались. Вам нужно просто сделать выгрузку и загрузку.

У вас максимальная единица перевода это слово, а не фраза. Поэтому для таких искусственного языка перевод идентификаторов будет однозначным.

БудДен
Сообщения: 2839
Зарегистрирован: 07.10.18 14:01

Re: АРМ переводчика

Сообщение БудДен » 12.01.21 17:30

Конечно, разные идентификаторы с одной лексемой. Да, парсер есть. Но работа-то не исчезает. Вот у меня есть, допустим, 100 переменных "file". Мне нужно в каждую зайти и понять, как её перевести, как ИмяФайла, ОткрытыйФайл или УпоминаниеФайла, для примера. Вот именно эта работа - заходить и понимать смысл - не лишняя, избавиться от неё нельзя, автоматизировать её полностью нельзя и у неё большой объём, учитывая, что в коде миллион строк.

Я могу её всегда назвать "файл" и тогда будет не хуже, чем было - т.е разбираться придётся тому, кто будет читать код. Я не могу вспомнить ситуацию, когда так сделать нельзя, но такие ситуации есть. Вспомню - напишу. Разве только Term сразу приходит на ум. Переведу я Term как "баня" и что? Лучше будет? Такой перевод вообще не нужен, лучше тогда вообще не переводить. Ну и в целом известно, что английские слова не превращаются в русские однозначно - одному английскому соответствует несколько русских вариантов. Без понимания контекста выбрать его невозможно. И если одно и то же имя переменной встречается много раз (это разные, но одноимённые переменные), то окажется, что в разных случаях нужно переводить по-разному.

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

Павиа
Сообщения: 136
Зарегистрирован: 23.05.19 21:28

Re: АРМ переводчика

Сообщение Павиа » 12.01.21 19:32

Конечно, разные идентификаторы с одной лексемой. Да, парсер есть. Но работа-то не исчезает. Вот у меня есть, допустим, 100 переменных "file". Мне нужно в каждую зайти и понять, как её перевести, как ИмяФайла, ОткрытыйФайл или УпоминаниеФайла, для примера. Вот именно эта работа - заходить и понимать смысл - не лишняя, избавиться от неё нельзя, автоматизировать её полностью нельзя и у неё большой объём, учитывая, что в коде миллион строк.

Я могу её всегда назвать "файл" и тогда будет не хуже, чем было - т.е разбираться придётся тому, кто будет читать код. Я не могу вспомнить ситуацию, когда так сделать нельзя, но такие ситуации есть.
Просто примите что таких ситуаций нет. File он и есть файл. ИмяФайла это FileName.
УпомнинаниеФайла у вас не будет, так не пишут даже на русском.

Да все 100 переменных надо открыть. Но для перевода достаточно знать контекст. Вы же в парсере можете найти пример присвоения и пример где он используется как параметр функции. Этого контекста из 2-х строк вам хватит.

БудДен
Сообщения: 2839
Зарегистрирован: 07.10.18 14:01

Re: АРМ переводчика

Сообщение БудДен » 12.01.21 19:42

Ну вот пример: NoFile - означает "файл не найден". NoPackages - означает "не задано ни одного пакета". Можно было не париться и перевести как НетФайла и НетПакетов, но это было бы не очень понятно.

БудДен
Сообщения: 2839
Зарегистрирован: 07.10.18 14:01

Re: АРМ переводчика

Сообщение БудДен » 12.01.21 19:44

Ну я могу перевести File всегда как File. Потому что у меня перевод, а не составление объяснения. Тогда работа по переводу ускорится, хотя
качество перевода в целом скорее упадёт. Главное, чтобы перевод не вводил в недоумение, но это проще, чем перевод, который уточняет оригинал.
Видимо, за этот счёт можно ускориться. А УпоминаниеФайла у меня есть, см. исходник:

https://gitlab.com/budden/ja-o-s/-/blob ... С.Mod#L397

Контекста в 2 строки недостаточно. Там часто бывает код, который сначала взяли, потом правили в итоге остановились, недоделав. Например, было нелегко понять, что prefix - Это условная переменная. Хотя он же иногда и приставка, и я до сих пор не на 100% уверен, что эти два применения не взаимосвязаны. Т.е. это такой косяк в исходнике, если его перевести в лоб, то станет ещё хуже. Или там неверно названо INCLUDE, которое должно называться DEFINE, а IMPORT должен называться INCLUDE.

БудДен
Сообщения: 2839
Зарегистрирован: 07.10.18 14:01

Re: АРМ переводчика

Сообщение БудДен » 12.01.21 20:20

target - что это? Оказалась "платформа", хотя это вроде понятно, но поскольку речь идёт о системе сборки, то это могла бы быть и цель для сборки.

Аватара пользователя
Сандро
Сообщения: 86
Зарегистрирован: 07.10.18 14:39

Re: АРМ переводчика

Сообщение Сандро » 19.01.21 05:54

БудДен писал(а):
12.01.21 20:20
target - что это? Оказалась "платформа" ...
У меня в переводчиках - QTranslate с девятью трансляторами и большинство из них слово "target" перевели как "цель", а слово "Term" - как "срок, термин, последний"...

Ответить