tcl/tk без знания английского

Уэлш Б., Джонс К. - Практическое программирование на Tcl и Tk на русском, старовата правда.

Программирование/IT без английского нереальны вообще, станешь обезьяной без понимания процесса.

Имеется в виду не локализация ключевых слов языка

В Tcl нет ключевых слов. И всего около 100 встроенных примитивов (не считая Tk), так что это как раз очень легко — просто переименовываешь стандартные команды и всё

а локализация только сообщений и форматов.

А вот это как раз довольно сложно. Придётся перевести несколько тысяч строк. Но что, тебе прям так сложно понять, что значит, например «exponentiation of zero by negative power»?

Здесь, понятное дело, нужна локализация.

Берёшь словарь и вперёд. Словарь можно взять stardict или goldendict и переводить сообщения прямо из окна REPL налету. Думаю это проще — заодно и английский чуток подучишь.

Понимание языка (можно ли его понять по переводным книжкам)

Вообще, сам язык заключается в 12-ти правилах синтаксиса на одной странице, их наверняка кто-нибудь на русский переводил. Ну и ещё около 100 базовых команд, и наверняка тех, которые появились в 8.6 нету в книжках — например apply и lmap.

Вот с Tk уже сложнее. Там опять же теперь есть Themed Tk, например ttk::button, если ты будешь писать на обычной Tk, то приложения будут страшноваты. Нужно использовать Tk с темами, чтобы у приложения был более современный вид.

Существенных русскоязычных сайтов я за 5 минут не нашёл.

Уроки Tcl и немного Tк

Но зачем?

Переименовывать стандартные команды считаю пагубным, ненужным и невозможным. Поскольку сломается хотя бы тот же tablelist. Или нужно переводить буквально каждую строчку кода. То, что это не выйдет сделать путём простой замены слова на слово - я уверен почти на 100%.

Перевод сообщений об ошибках нужен. Не все знают Английский.

Перевести несколько тысяч строк - не проблема. Проблема - как определить подлежащее переводу, как ничего не сломать, как сделать систему поддерживаемой на случай изменений в самом tcl/tk.

Вопрос о локализации не для меня, а для тех, кто не знает языка.

Уроки Tcl - видел. Там весьма мало. Неужто больше ничего нет на великом и могучем?

«Азбука Tcl»

Эту не видел, спасибо.

без знания английского

В школе немецкий был?

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

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

Но знание английского в любом случае нужно, на начальном уровне, иначе как ты код писать будешь? Транслитом что-ли?

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

ты ни с чем не перепутал? Вот это «само себя документирует»?

proc dunadh {name arglist variables lambda_proc} {
    set invoke_context [uplevel namespace current]
    set name_context ${invoke_context}::$name

    namespace eval $name_context {
       if {![info exists auto_cnt]} { variable auto_cnt -1}
    }

    namespace eval $invoke_context \
       [subst -nocommands -nobackslashes {
           proc $name {$arglist} { 
               set closure_name \
               ${name_context}::$name[incr ${name_context}::auto_cnt]
               eval [subst {
                   namespace eval [set closure_name] {
                       $variables
                   }
               }]
               namespace eval [set closure_name] {
                   curry [namespace current]::dispatch [$lambda_proc]
               } 
               return [set closure_name]::dispatch}
            }]
}

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

Вопрос о локализации не для меня, а для тех, кто не знает языка.

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

В принципе, нормально. Я толком тикль не знаю, но первые несколько строк распарсил с первого взгляда.

Ты издеваешься? Чтобы понять этот код нужно иметь представление о динамическом скопинге, замыканиях и карринге (и как черезжопно их делать с этим самым динамиком). Тут на лоре то половина икспердов срежется на этом. Теперь представь валенка с двойкой по инглишу, для которых старается упоротый Дэн. Короче, таким нельзя давать динамический язык, тем более тикль наркоманский. Да и вообще, нет что ли других щанятий для даунов, не умеющих читать.

а почему функция называется по-ирландски?

Переименовывать стандартные команды считаю пагубным, ненужным и невозможным.

А как же interp alias? Если стандартные команды тоже останутся доступными, то ничего сломано не будет.

Перевести несколько тысяч строк - не проблема.

Проблема - как определить подлежащее переводу,

grep -or '"[^"]*[a-zA-Z]\{3,\} [^"]*"' ./generic

Примерно так. Ну и плюс специфичные для ОС сообщения. Ещё можно сделать модуль, который будет определять, переведена строка или нет и если нет, то писать непереведёные строки в лог.

как ничего не сломать,

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

как сделать систему поддерживаемой на случай изменений в самом tcl/tk.

Если посмотреть на код, в основном на generic/tclBasic.c, то видно, что сообщения создаются через Tcl_SetObjResult, а man этой функции говорит что их можно получить через Tcl_GetObjResult. Возможно, можно сделать перевод в виде сишного модуля, который будет перехватывать и заменять строчки. Ну или можно попытаться заменять строки в исходниках перед компиляций. Не знаю, правда, что при этом сломается.

как сделать систему поддерживаемой на случай изменений в самом tcl/tk.

А тут в идеале нужно было бы запилить систему локализации через gettext, чтобы можно было любой язык поддерживать.

Вопрос о локализации не для меня, а для тех, кто не знает языка.

А зачем это тебе, если не секрет?

Вот что-то я очень сильно сомневаюсь, что есть хоть одна книга на русском языке, покрывающая хотя бы Tcl 8.5, не говоря уже о 8.6. А ты думаешь, что найдёшь такую? Вообще код на Tcl конечно обратно совместим, но всё же стоило бы обратить внимание на разницу между версиями и описать её в виде отдельной статьи хотя бы.

Ещё можно было бы написать книгу самостоятельно, переведя туториал с сайта tcl.tk

Короче, таким нельзя давать динамический язык

А Хаскель, значит, можно?

а почему функция называется по-ирландски?

Чтобы было понятно, как выглядит для того, кто не знает английский.

Стыдно сейчас не знать английского.

Для школьников стараешься? Не трать время зря. Школота не оценит. «Оффицыально» утверждёнными для школоты является четыре языка: Ершол, Паскаль, Си и Питон (sic!). Отступление от норм приведёт к плачевным результатам.

Одна из проблем с локализованными сообщениями об ошибках заключается в том, что уточнить ее значение, если не вполне понял, будет не у кого. Сообщество тикля и так малюсенькое, а в России оно вообще практически отсутствует. И в случае локализованного сообщения гугл тоже не поможет. Так что лучше потратить время на изучение английского языка хотя бы на начальном уровне.

А как же interp alias? Если стандартные команды тоже останутся доступными, то ничего сломано не будет.

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

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

Спасибо, хорошее замечание. Видимо, нужно сделать чтобы исходное сообщение можно было поискать в некотором словаре, а уже оттуда - в гугл.

Понял, что тут ключевое слово gettext. Да, вопрос о «правильной» локализации - никогда этим не занимался.

А зачем это тебе, если не секрет?

Вот для этого: Ну ладно, можно смеяться и говорить «ненужно»

«Оффицыально» утверждёнными для школоты является четыре языка:
Ершол, Паскаль, Си и Питон (sic!)

Спасибо! А где этот список находится? Питон... ... ... .

Вот для этого

передумал делать русскоязычные команды? Я вот думаю в tcl вполне бы через interp alias можно запилить.

Даже создание алиасов небезобидно

Чем может быть опасно создание алиасов?

Я не собирался делать русскоязычные команды для tcl. В моём языке они будут, а tcl/tk я использую как отдельный инструмент, где на моём языке будет сервер, а tcl/tk выступает в качестве клиента.

Речь шла только о локализации документации (как изучить tcl) и о локализации сообщений (как работать с tcl). В противном случае нельзя честно сказать, что есть полностью русскоязычная среда. То, что команды tcl/tk будут на Английском, не так страшно. В математике и программировании есть всякие условности, типа sqrt, det, rank или dir, которые никто и не думает локализовать.

Если бы у меня было достаточно ресурсов для полной локализации tcl/tk, я бы вместо этого вообще убрал tcl и переделал бы tk, чтобы он работал с моим языком непосредственно.

Спасибо! А где этот список находится? Питон... ... ... .

В КИМ ЕГЭ, вестимо. В 2015 году, по крайней мере. В 2016 ещё не смотрел.

Если бы у меня было достаточно ресурсов для полной локализации tcl/tk

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

Может быть тупо заменить везде в generic/ сообщения об ошибках на русские прямо в исходниках и норм?

Чем может быть опасно создание алиасов?

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

Впрочем, если мои опасения чрезмерны и кто-то (хотя бы ты) возьмётся полностью локализовать сам язык tcl, я буду двумя руками за.

Тем, что работая в tcl, ты часто имеешь дело с алиасами или переименованными процедурами и даже об этом не догадываешься.

Не понимаю. Переименовать все команды опасно — перестанут работать те части языка, которые реализованы на самом Tcl, а создавать для него алиасы должно быть совершенно безопасно. Русскоязычные команды точно не будут конфликтовать ни с чем.

Не так тривиально. snit переименовывает некоторые команды, как и tkcon. Что делают другие библиотеки, написанные на tcl - я не знаю. Но это уже полномасштабный форк. Локализация же сообщений выглядит гораздо менее масштабным мероприятием.

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

И мне кажется, что вопрос перевода документации тоже трудоёмок.

Допустим, мы русифицируем puts как печс. При запуске tkcon создаёт алиас puts в подчинённом интерпретаторе. А алиас для печс он не создаст. Поэтому мы запустим tkcon и печс у нас не будет работать. Вывод: нам придётся форкнуть tkcon, прочитать 5000-6000 строк его исходника, найти места, где делаются алиасы, сделать такие же алиасы для русифицированных команд, протестировать их, и потом тянуть патчи для tkcon, сливая их с нашими не совсем тривиальными правками, т.е. поддерживать наш форк.

snit тоже что-то сложное делает.

Каждый такой случай должен обрабатываться особо для созданных русскоязычных команд.

Зачем?

в подчинённом интерпретаторе

Это что такое?

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

document["вася"] = document.getElementById
console.log( document["вася"]("foo") )

какие ты там нахрен языки пилишь с такими детсадовскими понятиями, хз. Хорошо еще что таких «программистов» до баллистических ракет не допускают, тьфу, тьфу, тьфу. Школьникам то в мосх невозбранно срать — это нормально, ниче страшного. Только хреново, что эти школьники — завтрашние Ынженеры, и рано или поздно эти гнилые мозги доберуться и до баллистических ракет. Может оно и правильно, человечество наверное недостойно выживания.

Я приготовил небольшой ремикс из твоих цитат. Зацени.

тынц тынц тынц тынц джжж
тынц тынц тынц тынц
упса тынц тынц джжж
тынц тынц тынц тынц

Я толком тикль не знаю
тынц тынц тынц тынц
распарсил с первого взгляда упса
тынц тынц тынц джжж

Это что такое?
тынц тынц Это что такое?
тынц Это что такое? тынц
Это что такое? такое? такое? такое?

Хорошо еще что таких «программистов» до баллистических ракет не допускают,

тьфу, тьфу, тьфу, тьфу
тьфу, тьфу, тьфу, джжж
тынц тынц тынц джжж

тьфу, тьфу, тьфу, джжж
тынц тынц тынц тынц
тынц тынц тынц тынц
тынц тынц тынц тынц
Это что такое? такое? такое? такое?

Молодец, жопу свою отмазать умеешь. Но мозга это не прибавит.

Может быть тупо заменить везде в generic/ сообщения об ошибках на русские прямо в исходниках и норм?

Ну по большому счёту это и надо сделать, но с учётом того, что tcl/tk ещё будет меняться и желательно эту работу не повторять каждый раз. Т.е., наверное, не поменять в исходниках, а каждый раз скриптом менять перед сборкой, где скрипт - это набор замен.

Насчёт тривиальности замены я не уверен ещё по нескольким причинам. Команды можно заменить, но у команды есть второе слово, напр. тот же interp alias. А я не уверен, что эта логика всегда написана на tcl. Даже если написана, и переадресовывать интерп псвдним в interp alias, стек станет вдвое глубже. Мало того, что это неудобно и замедляет работу, может сломаться использование uplevel для каких-то случаев. Но некоторые команды наверняка написаны на C.

Далее есть индексы в том же string и text. На что заменить end-1c, к примеру?

а где можно заказать весь альбом?

без знания английского

Зачем помогать выживать идиотам и ленивому быдлу?

Крым Наш

Допустим, мы русифицируем puts как печс

пздц

Упоротый Дэн, пойми же наконец, что русский совсем не годится как база для ЯП. Потому что он синтетический (этого уже достаточно), в нем длинные слова, и для многих терминов просто нет однословных шорткатов. Короче, разупорись. Одинэс (блеванул в этом месте) у нас уже есть.

Зарегистрируйся.

Допустим, мы русифицируем puts как печс

Не надо так русифицировать. «печс» ничуть не понятнее puts, и всё равно придётся запоминать, что оно делает. Лучше как «печатать» перевести или как «вывести строку» даже, Tcl же позволяет субкоманды. А puts -nonewline перевести как «вывести фразу» тогда.

А алиас для печс он не создаст.

Хм... Не знал, но я думаю можно всё оформить как модуль и просто загружать его просто всех алиасов.

т.е. поддерживать наш форк.

Он должен tclshrc открывать, поэтому не нужно ничего поддерживать. Просто загрузить в виде модуля.

Хм... Не знал, но я думаю можно всё оформить как модуль и просто загружать его просто всех алиасов.

Думается, я обосновал факт наличия проблем. То решение, которое тебе казалось тривиальным, оказалось недостаточным. А значит, всё заново тестировать. Меня интересует гораздо более скромная задача - всего лишь сообщения об ошибках.