В продолжение темы, сданной в архив...

Владимир, ну какое отношение объекты имеют к наименованию форумов?

monk в этом треде присутствует.
ИМХО он да и вы хорошие разработчики.

Хм, хотя тут пишут, что это не Хлебников, а чуть ли не сами лётчики придумали. https://dzen.ru/a/XC3ZkpF11QCqvUvB

Удивлю вас.

Я ведь по духу Русский и вообщем-то большинство ваших суждений поддерживаю (категоричность все же в суждениях «не очень», хотя суть верна).

Так как я верующий, то по другому сужу о происходящем в мире.

Для меня злоба запада, это прежде всего борьба против Православной России.

Сотни лет людей воспитывали в духе ненависти к России.

ИМХО безбожный народ там был и есть (конечно не 100%).

Но Вы же понимаете, что раз мы сейчас с Вами не на английском говорим, то у нас двухъязычная ИТ-сфера. Это вообще же не выгодно. Ровно по той причине, что мы не знаем, как перевести «Desktop», т.е. из-за того, что слова не имеют однозначного перевода. Т.е. любой шов между русским и английским в нашей отрасли - это линия, при пересечении которой происходит потеря информации. Зачем нам это наказание?

Но Вы же понимаете, что раз мы сейчас с Вами не на английском говорим, то у нас двухъязычная ИТ-сфера. Это вообще же не выгодно.

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

Ровно по той причине, что мы не знаем, как перевести «Desktop», т.е. из-за того, что слова не имеют однозначного перевода. Т.е. любой шов между русским и английским в нашей отрасли - это линия, при пересечении которой происходит потеря информации. Зачем нам это наказание?

Вот именно. Не нужно его никак переводить. Пусть будет Desktop (или десктоп) — просто и понятно.

«Меня это устраивает» - это Ваш личный синдром утёнка. А есть интересы отрасли в целом. Наличие двух языков путается под ногами и снижает производительность труда.

Т.е. любой шов между русским и английским в нашей отрасли - это линия, при пересечении которой происходит потеря информации.

Не потеря, никак не потеря. Может быть только удваивание, что только на пользу для когнитивных способностей.

Я понимаю так, что и x, y и u в математической нотации это тоже потеря информации?

Как говорят лингвисты, смена алфавита, например с кириллицы на латиницу, не только не имеет особого смысла, но и не повлияет на язык в целом.

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

Дальше, неясно как мы перескочили от смены языка (например, замены слова Desktop на словосочетание «Рабочий стол») на смену букв. Можно пояснить, как этот переход оправдан?

неясно как мы перескочили от смены языка (например, замены слова Desktop на словосочетание «Рабочий стол») на смену букв

Неа, не перескочили. Сильно выше писал, что основа языка - лексемы, десктоп (desktop) - это такая же лексема в русском языке, как и «настольный». Вы определение «настольный» не принимаете буквально как «стоящий на столе»? Скорее это для вас как сравнительная степень применяемая к чему-либо, т.е. есть варианты нескольких исполнений, среди которых настольный - как более компактный или менее профессиональный, зависит от контекста.

любой шов между русским и английским в нашей отрасли - это линия, при пересечении которой происходит потеря информации

Какая потеря, в чём шов, в том что лексемы ЯП являются таковыми и в английском? Я что-то не знаю таких людей, которые изучали бы ЯП как английский. Все воспринимают как самостоятельный.

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

Ну вот укоренился он в русском, во многих значениях, принудительная замена на «рабочий стол» сильно сужает эти значения.

И да, я против вот такого контекста, как «вопросы применения Linux/Unix на рабочем столе», на самом деле он шире.

Я не всю тему читал и не понял Вашу аналогию. Если так, то потеря состоит в том, что перевод не однозначен. Если вы перевели английское слово русским в составе предложения или наоборот, то смысл предложения поменялся. Угадает ли читающий смысл оригинального предложения до перевода - вообще говоря, непредсказуемо. Сколько усилий ему для этого понадобится - тоже неясно. Это и есть потеря информации.

Вот википедия пишет: «В ряде концепций в лексему включаются разные смысловые варианты слова, зависящие от контекста, в котором оно употребляется (например, соль в смысле названия вещества и в значении того, что придает остроту или интерес какому-либо высказыванию, мысли).»

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

Не потеря, никак не потеря. Может быть только удваивание, что только на пользу для когнитивных способностей.

У меня свежий пример. Попросил человек автоматизировать архив. Там если дела, короба, стеллажи. Хорошо, в программе case, box, shelf.

Пишу, внедряю. Делаю внешнее API для интеграции с кучей всего и вся.

Приходит человек и говорит, что в коробах могут быть ящики, а на стеллажах надо сделать учёт в разрезе полок. Но box и shelf уже заняты и с учётом использования в API переиспользованы быть не могут. Приходится рождать subbox и subshelf и пожелать счастья тому, кто это потом будет сопровождать.

А в той части, где учёт в 1С, всё однозначно: дело, короб, стеллаж, коробка, полка.

Я понимаю так, что и x, y и u в математической нотации это тоже потеря информации?

Иногда да. Например, если надо изобразить изменение молярной концентрации при перемещении вдоль оси абсцисс.

Как говорят лингвисты, смена алфавита, например с кириллицы на латиницу, не только не имеет особого смысла, но и не повлияет на язык в целом.

Если без потери букв, то да. Если с заменой на транслит, то слегка повлияет (также как влияет замена ё на е: есть имена Алёна и Алена).

Какая потеря, в чём шов, в том что лексемы ЯП являются таковыми и в английском? Я что-то не знаю таких людей, которые изучали бы ЯП как английский. Все воспринимают как самостоятельный.

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

Например, есть кнопка с надписью «Поместить». В русском ЯП имя функции, обрабатывающей событие этой кнопку будет также «Поместить». В английском может быть submit/post/commit/… и обратно найдя в коде какой-нибудь CustVAT придётся просматривать где оно используется и как выглядит в интерфейсе (с русским ПокупНДС или ТаможНДС такой проблемы нет).

Сильно выше писал, что основа языка - лексемы, десктоп (desktop) - это такая же лексема в русском языке, как и «настольный». Вы определение «настольный» не принимаете буквально как «стоящий на столе»?

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

заняты и с учётом использования в API переиспользованы быть не могут

А в той части, где учёт в 1С, всё однозначно

Смысл проблемы понятен, но непонятен трагизм ситуации. Можно было, наверное, с самого начала делать иерархическую систему или задать для каждой единицы title-наименование, которое ни на что, кроме как отображения не влияет, а внутри пусть будет просто node. И т.п., согласовать с API, что уровней и связей может быть много.

Я не вижу здесь «языковых» нерешаемых препятствий. Неудобства есть, но они скорее архитектурные.

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

Так от этого лучше и не стало, можно было или обойтись без, или подумать тщательнее над описанием.

найдя в коде какой-нибудь CustVAT придётся просматривать где оно используется и как выглядит в интерфейсе

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

с русским ПокупНДС или ТаможНДС такой проблемы нет

Ой, у меня был опыт работы в франчайзи 1С. Не согласен. Это как с hello world, примеры всегда выглядят причёсанными и аккуратными, действительность сильно сложнее и менее красивая. Я не заметил, что мне было сильно проще понимать, что делает функция из-за того, что она именована на родном мне языке.

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

???

В смысле, вместо ПолучитьСтеллаж(), ПолучитьКоробку(), ПолучитьПолку() писать GetNode1(), GetNode2(), GetNode3() ?

Проблема не в заголовках, а в том, что имена функций и переменных должны быть значащими. А значение мы берём не из ТЗ, а из перевода ТЗ. И получаем перспективу коллизий.

вместо ПолучитьСтеллаж(), ПолучитьКоробку(), ПолучитьПолку() писать GetNode1(), GetNode2(), GetNode3()

Здесь на помощь должны прийти абстракции, ООП и иерархия (или di).

не носителю английского потребуется время, чтобы втянуться в контекст

Я имел в виду, что не носитель английского легко сократит CustomerVAT до CustVAT, так как в этом месте вроде очевидно, а английский он знает не настолько досконально, чтобы понять, что CustomsVAT сокращается в его же.

Я не заметил, что мне было сильно проще понимать, что делает функция из-за того, что она именована на родном мне языке.

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

ООП и иерархия

???

И кто из списка дело, короб, стеллаж, коробка, полка от кого наследуется?

Я специально нигде не упоминал про наследование, хотя его если захотеть можно и здесь притянуть.

У перечисленных сущностей есть общее, их можно «получить, переместить», их можно связать с другими сущностями «кто на ком стоял». Значит не обязательно «GetNode1(), GetNode2(), GetNode3()», когда можно изменить только реализацию get.

Я не заметил, что мне было сильно проще понимать, что делает функция из-за того, что она именована на родном мне языке.

В следствии того, что у многих программистов бытует мнение о том, что достаточно использовать лишь «внятные» названия переменных.

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

Если в исходных кодах проекта нет комментариев, то это приводит к непроизводительной трате времени на «реставрацию» архитектуры проекта и алгоритмов.

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

Но не думаю, что это время будет критичным.

Конечно, в каждом случае, оно не будет критичным. Но на круг за весь цикл проекта может много набежать. Кто должен за это заплатить? Ты или твой заказчик? И почему за это нужно платить, какое благо мы за это купим? Кроме того, хорошо работать в двухъязычной среде будет только тот, кто хорошо знает и русский, и английский. Если знает не хорошо - будет ошибаться. А сколько нужно человеко-лет в жизни потратить, чтобы хорошо прокачать английский? Сколько-то. Что мы получаем в итоге в продукте? Ничего. Т.е. ресурсы мы потратили и ничего не получили. Зато специалисты, которые могут дорабатывать эту программу, дороже стоят (хорошее знание английского означает хорошую прибавку к зарплате). Зачем мне это, к примеру, если я выступаю в роли заказчика? Ради твоего комфорта?

Это всё решается документацией, описанием API. За такую документацию приходится платить, кому и как, это как договорились «на берегу».

Вопрос не в том, что это не решается. Вопрос в том, что это имеет свою цену. Почему мы должны её платить? Какова выгода? Для примера, 1Сники не платили эту цену, а разработчики для Галактики - платили. Долю рынка можешь посмотреть в обзорах рынка учётных систем. Теперь объясни разработчикам Галактики, ради чего они меньше заработали и не заняли место 1С. Конечно, нельзя сказать, что дело только в языке. Однако тот факт, что разработчики Галактики оплачивали двухъязычность, а разработчики 1С - не оплачивали, остаётся и он не мог не внести свой довесок в исход рыночного соревнования.

И кстати, ты говоришь, что эта цена некритична. А можешь дать оценку, насколько она некритична? Т.е. допустим, насколько процедура Галактики дороже аналогичной процедуры в 1С? Желательно, с обоснованием цифры, даже если цифра равна нулю.

обязательно «GetNode1(), GetNode2(), GetNode3()», когда можно изменить только реализацию get.

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

Почему мы должны её платить? Какова выгода?

Хороший вопрос.

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

Некоторые попытки были (например UML), но это скорее ... (ну вы поняли).

1с двуязычна. Про галактику ничего не знаю. Про критичность - это опыт личный, который показывает, что сложность вникания в чужой код зависит только от: наличия документации (в том числе и комментариев), близости используемой парадигмы и, наверное, всё. Кодестайл не сильно влияет.

Про критичность - это опыт личный, который показывает, что сложность вникания в чужой код зависит только от: наличия документации (в том числе и комментариев)

Представь себе, что все функции названы f1, f2, …, а переменные v1, v2, …. Неужели тебе не потребуется больше времени, чтобы понять такой код (при равном количестве документации и комментариев)?

Вспомнилось:

В 1971 году мне представился случай обсудить вопросы мнемоники и содержательности меток с программистом, разрабатывающим важные имитационные программы для Центра пилотируемых космических кораблей НАСА. По его мнению, переменным, подпрограммам и другим меткам не следует давать «значащие» имена, поскольку впоследствии они могут быть ошибочно поняты или истолкованы программистами, обеспечивающими сопровождение. По этой причине он намеренно выбирал такие имена, как QPK17, GLOP42 и ZYX123, ни одно из которых не имело никакой связи с именуемыми переменными и подпрограммами. Он считал, что в этом случае программист будет вынужден тщательно изучить программу, чтобы узнать истинный смыл этих меток.

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

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

Но здесь и ф1, ф1, п1, п2 не помогут.

Я лишь удивился про ООП и иерархию (которая ещё и не является наследованием) как предлагаемое решение. Задача всё равно была всего лишь примером.

А проблемой является то, что мы обязаны фиксировать перевод в API. При этом перевод осуществляет программист (а значит либо все должны отменно знать английский, либо будет жуткая неоднородность в наименовании, вплоть до UstroistvoCode). И вторая часть проблемы: в ТЗ может появиться другая сущность, имеющая по-русски другое название, а по-английски то же самое. И дальше стыковка ТЗ и кода многократно усложняется. Бывает, что перевод не совсем однозначен (в 1С:Hotel в интерфейсе Посетитель, а в коде Customer).

Но здесь и ф1, ф1, п1, п2 не помогут.

Это всего лишь иллюстрация к тезису, что алгоритмы с значащими идентификаторами читаются легче.

1с двуязычна в том смысле, что она в принципе позволяет (но не обязывает) использовать английские ключевые слова и некоторые названия функций. При этом разработки на ней одноязычны, во всяком случае, многие. Открой стандартную конфигурацию 1С:Предприятия и убедись в этом. Также зайти на форумы 1С-ников и посмотри на примеры, которыми они обмениваются.

Есть ли в стандартной конфигурации синонимы для справочников на английском? Я думаю, что их нет. Если я прав, то в прикладной области 1С не двуязычна.

Но можно всё это узнать непосредственно у monk

В Галактике тоже есть встроенный язык программирования, но он полностью англоязычный. Названия сущностей в конфигурации тоже англоязычные (включая имена таблиц и полей).

У меня доработка англоязычного 1C:Hotel занимала для задач равной сложности примерно вдвое больше времени, чем, например, для 1С:Управление автотранспортом.

Потому что сначала надо было найти как в коде называется то, что я вижу на экране (что надо дорабатывать). Потом для каждого имени в коде найти соответствие в интерфейсе (чтобы понять как работает сейчас и что менять). Через некоторое время запоминаешь что чему соответствует, но этот лишний словарь занимает слот рабочей памяти (которых у человека всего 5-9) либо требует постоянной подгрузки-вспоминания.

Есть ли в стандартной конфигурации синонимы для справочников на английском? Я думаю, что их нет. Если я прав, то в прикладной области 1С не двуязычна.

Синонимы есть для всех поддерживаемых конфигурацией языков. Например, для 1C:Hotel это английский, немецкий и русский.

Вот описание языка «Галактики», он называется VIP.

https://www.erpandcrm.ru/vipprogr.ru/

Но я почему-то не вижу тут описание сущностей БД. Где-то вроде тоже было, может просто мало искал.

А в стандартной конфигурации 1С:Предприятия?

Названия сущностей в конфигурации тоже англоязычные (включая имена таблиц и полей).

Гм…

Счета - в buhschet, организации - katorg, подразделения - katpodr.

А в стандартной конфигурации 1С:Предприятия?

В пустой? Любые из 15 поддерживаемых платформой.

Если речь про типовую 1С: Бухгалтерия, то там, естественно, только русский (зачем русскому бухгалтеру англоязычный интерфейс? и как на него переводить термины, которые есть только в российском бухучёте?).

«Меня это устраивает» - это Ваш личный синдром утёнка.

Я и не отрицал, что это лишь субъективное мнение. Конкретно синдром утёнка в данном случае ни при чём, впрочем.

А есть интересы отрасли в целом. Наличие двух языков путается под ногами и снижает производительность труда.

Есть ссылки на исследования по этому поводу?

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

Есть ссылки на исследования по этому поводу?

Моего личного хватит: В продолжение темы, сданной в архив... (комментарий) ?

Именно поэтому я за то, чтобы использовать англоязычные наименования IT-специфичных понятий, как я и сказал выше. И никакой путаницы. И не надо одно и то же понятие на двух языках учить.

Осталось ещё заставить всех заказчиков ТЗ по-английски писать и интерфейс по-английски делать (хотя его и так делают, так что проблема только в ТЗ).

Ну вот, Вы были против того, чтобы какой-то язык навязывался из политических соображений, и всё же, если разобраться, то предлагаете навязывать английский из соображений удобства. Ведь предложение изменить терминологию касается всех, в том числе и меня. А я предлагаю из тех же соображений навязывать русский. Чья позиция лучше? Притом, если мы работаем внутри России, то русский естественен, как ответил monk, т.к. это язык заказчика и язык пользователя. А английский не имеет никаких корней. Теперь опять - чья позиция логичнее и приведёт к более удобному результату?

Английские термины всё равно надо знать. Для чтения документации, учебников, для именования переменных и функций по-нормальному, да и просто для общения с людьми вне России (тут уже нужен весь английский язык, а не только термины).

Теперь опять - чья позиция логичнее и приведёт к более удобному результату?

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

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

Так в том и состоит задача русификации ИТ, чтобы не нужно было знать английские термины. Общение с людьми вне России нужно далеко не всем (вспоминаем моряков Петра I). Другое дело, что да, как и в морском деле, большинство терминов позаимствованы и являются прямыми кальками с английского (здесь наши позиции даже почти не расходятся). Но тем не менее, «рабочий стол», «настольный компьютер» и даже «десктоп» - это русские слова, а desktop - нет.

потому что так не надо учить английский

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

Я предлагаю не мешать естественному процессу.

Не всякому естественному процессу нужно не мешать. Засилье английского - это результат поражения СССР в холодной войне. Когда я был маленьким (а это было ещё до поражения), такого не было. Мой синдром утёнка протестует. Любая страна, потерпевшая поражение, рано или поздно поднимается обратно и навёрстывает своё - это тоже естественный процесс. Вот если этому процессу не мешать в случае России - то тут я соглашусь. И это подразумевает восстановление роли государственного языка.

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

Не надо вырывать из контекста. Фраза целиком: «потому что так не надо учить английский + три разных русских перевода на каждое понятие». В том смысле, что не надо учить четыре термина вместо одного.

Любая страна, потерпевшая поражение, рано или поздно поднимается обратно и навёрстывает своё - это тоже естественный процесс. Вот если этому процессу не мешать в случае России - то тут я соглашусь.

Что-то моя уверенность, что такой процесс действительно сейчас идёт, стремится куда-то в сторону бесконечно малых величин. Но мешать ему, если он идёт, конечно же, не нужно. Тут, как говорится, хочется верить, но верится с трудом.

И это подразумевает восстановление роли государственного языка.

Не подразумевает. И уж точно не подразумевает в таком виде. Что это действительно подразумевает, так это то, что если предположить, что Россия действительно поднимется и начнёт давать миру принципиально новые изобретения, а может и новые сферы деятельности (не всё же на одном IT завязано), то вот эти новые понятия действительно могут начать называться русскими словами, причём тоже во всех языках, как тот же Tokamak. Но это новые слова для новых понятий, старые для этого заменять «тихогромами» и «мокроступами» не требуется.

Не надо вырывать из контекста.

Я просто не понял.

Но это новые слова для новых понятий, старые для этого заменять «тихогромами» и «мокроступами» не требуется.

Конечно, не надо. Это делается путём русификации понятий. В худшем случае, Desktop -> Десктоп, равно как rondhout -> ронгоут (круглое дерево или как-то так). Так речь-то и не идёт об изобретении «топталищ» и «мокроступов». Речь идёт о том, чтобы перевести разделы форума. Если языковой барьер некритичен, то эта задача осуществима и большой разницы нет, не так ли?

Россия действительно поднимется и начнёт давать миру принципиально новые изобретения

«Подняться» и «давать новые изобретения» - это разное. Подняться - это просто означает обрести суверенитет и перестать платить дань. Пётр I не делал новых изобретений в кораблестроении. Он взял технологии у голландцев, построил свой флот и вломил шведам. Сегодня у нас эпоха НТР и новые изобретения нужны, для себя, а не для того, чтобы давать их миру. Сначала надо вломить миру, чтобы он понял, что не надо лезть. А потом уже на усмотрение. Собственно, так было всегда - никто никогда ни с кем добровольно не делился военными изобретениями, разве только с союзниками, да и то с оглядкой. Потому что сегодня союзники, а завтра - как знать.

По-моему, очевидно, что я отвечу, что моя, потому что так не надо учить английский + три разных русских перевода на каждое понятие, а достаточно одного термина.

Для меня именно по этой причине проще писать по-русски. Есть термин «поместить в хранилище» и ему соответствуют разные переводы: put, commit, post, store, … в зависимости от используемой библиотеки. И надо помнить как «поместить» в каждом конкретном случае переводится. То есть, это с английским приходится учить английский + три разных английских перевода на каждое понятие.

maxcom, а вы что на это всё скажете?

Не вижу смысла менять привычные названия.