Как стать автором
Обновить

Комментарии 98

ну опять холивар
==
Русский язык в 1С по одной простой причине появился, чтобы «Обыкновенный бухгалтер, мог открыть конфигуратор и сам чтото там исправить» (с)… было это еще в 90х… а потом когда сложность перевалила за все мыслимые (для обычного человека) пределы… русский язык так по привычке и остался
И теперь он один из барьеров почему в 1С никто не идет и все её ненавидят

Научиться писать небольшие, но реально работающие решения на платформе «1С: Предприятие» может даже школьник. Не в последнюю очередь потому, что писать он будет на родном и полностью понятном ему языке.

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

а 1С без её прикладных задач не имеет смысла, ну сможет школьник написать чёнить для учета учебников… ну а смысл, если задачи в основном это исправление всяких платежек, УПД, расчета налога на прибыль и т.п. Куда там «легко входить» если аналитик в постановщик задач в отрасли это какието заповедные животные которые гдето есть но их почти никто не видетю?
==
Потом русский язык чтобы было понятно… вот открываю конфигуратор, а там
ОбменКлиентБанкКлиент
ОбменКлиентБанкКлиентСвервер
ОбменКлиентБанкСервер
ОбменКлиентБанкиКлиентСвервер

Процедура ОбработкаКлиент
Процедура ОбработкаКлиентПереопределяемый
Процедура ОбработкаКлиентСерверПереопределяемый Экспорт
(и они все друг на друга ссылаются)

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

А смысл?
Ну т.е. строка
«Процедура МояЛучшаяПроцедура(МояПеременная) Экспорт»
станет выглядеть как
«Procedure МояЛучшаяПроцедура(МояПеременная) Export».
Это, мне кажется, не решит проблему.
НЛО прилетело и опубликовало эту надпись здесь
Ведь синтаксис помощник тоже будет на английском. Хотя в этом я начал сомневаться. Давно это было. Но вроде есть описание процедур на английском

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

Так что, это решит проблему открыли в России значит на русском, открыли в другой локале значит на английском

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

НЛО прилетело и опубликовало эту надпись здесь
Но на практике, 90% кода все-таки будет не в виде «if A equals(Б) then», а обращение к методам и работа с переменными, которые все равно написаны на великом и могучем.
Но я понимаю проблему. Сам когда сталкивался с кодом на 1С на английском испытывал боль, при этом с кодом на других ЯП такой проблемы нет.

Но в первом примере суть всем понятна, а во втором только 1Сникам

Мягко говоря, спорное утверждение =)
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
… хватило мне наркомании в 7.7… восьмерки сейчас касаюсь только в качестве халтурки на выходных, и мне можно не особо вникать в то что они там опять наизобрели нетипового для отрасли программирования в целом
НЛО прилетело и опубликовало эту надпись здесь
Настоящий программист должен страдать и кодить исключительно на иностранном языке! (даже если плохо его понимает!)

Но вывод, по вашему же словам, что только «тупые американцы» недостойны этой участи, и вынуждены кодить на родном языке!!! Пусть мучаются бедные…

Была бы ваша воля — заставили кодить их на китайском (их ведь большинство на планете!)
Настоящий программист должен страдать и кодить исключительно на иностранном языке! (даже если плохо его понимает!)

Это стандарт отрасли.

Но вывод, по вашему же словам, что только «тупые американцы» недостойны этой участи, и вынуждены кодить на родном языке!!! Пусть мучаются бедные…

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

Была бы ваша воля — заставили кодить их на китайском (их ведь большинство на планете!)

дело не в количестве, в общепринятых стандартах

в медицине рецепты вообще на латинском пишут, иш какие странные… ни в одной стране мира на этом языке не говорят, нет чтобы на русском писать 'ан-ти-би-от-ик-и'
чтобы «Обыкновенный бухгалтер, мог открыть конфигуратор и сам чтото там исправить» (с)…

Такое утверждение можно применить, наверное, к «Бухгалтерии 6.0», где при помощи макроязыка бухгалтер действительно мог что-то исправить или дополнить. Но уже «Торговля 7.0» (а именно там и появился Конфигуратор» была ориентирована на специалистов, владеющих базовыми навыками программирования, и почти тогда же (в девяностых) была запланирована и развернута программа подготовки таких специалистов, которые бы совмещали умение разрабатывать программный код с пониманием предметной области (учет/управление).

Это не чтобы поспорить, а просто ради исторической достоверности.
В мировой практике даже комментарии в коде на родном языке, особенно в открытом коде (а почти все продукты на платформе 1С имеют открытые исходники) — считаются признаком нетрадиционной половой ориентации автора кода. Т.к. ваш код возможно будет читать или поддерживать человек из другой страны (а может и не будет, но откуда вам знать). Мировой стандарт — весь код и комментарии на английском. А уж весь открытый код на кириллице это, блин, полный «Новый стандарт разработки от 1С».
Но поддержкой своих конфигураций они занимаются сами. Зачем городить тогда костыли переинжиниринга?
Конфигурации все равно приходится локализовывать под учет в каждой стране, так что поддержку русской бухгалтерии индусы точно делать не будут.
Сам за свою долгую программистскую жизнь программировал (в продакшн) от дельфей и 1С (специалист-консультант по Торговле) до С (научные расчеты на GPU), трудностей в переходе на русский не ощутил. Разве что русский SQL был непривычен.
В англоязычной ERP, рассчитанной на западный рынок, валятся эксепшены на русском. Буржуи будут очень рады такому продукту)
НЛО прилетело и опубликовало эту надпись здесь
Да хз, может и перевели. Я помню год или два назад у 1С на http__www.1ci.com_applications_1c-erp_ была выложена онлайн-демо ERP. Так там при проведении документов ошибки на русском писались)

Да что бы меня заминусовали...


Скажи об этом Китайцам, Французам и Немцам. Они спокойно оставляют комментарии на своих родных языках и почему то ни кто ни чего не говорит им. И только Русским запрещено это делать, причём запрещают это делать сами русские. Это вообще великолепная позиция на мой взгляд.


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

В европах геев больше, да) А если серьезно, то попав на поддержку и развитие проекта, где все комменты и классы на китайском, начинаешь понимать, почему многие разработчики ратуют за то, чтобы весь код и комментарии писались на английском.
В мировой практике даже комментарии в коде на родном языке, особенно в открытом коде (а почти все продукты на платформе 1С имеют открытые исходники) — считаются признаком нетрадиционной половой ориентации автора кода. Т.к. ваш код возможно будет читать или поддерживать человек из другой страны (а может и не будет, но откуда вам знать).

А если заранее известно, что этот код ориентирован на определенный рынок? Что если «возможно будет» является «точно не будет»?

Мировой стандарт — весь код и комментарии на английском

Можете мне глупому и неопытному объяснить/сформулировать/показать этот стандарт? Просто для себя хочу понять этот момент.

В рамках моего интереса к истории о компьютерах и всего, что сейчас именуется IT читал книгу Информационные технологии в СССР. Создатели советской вычислительной техники. и еще много чего. Сделал вывод, что могло все обернутся иначе и мировым языком программирования стал бы могучий русский. Для меня эта непонятность лидера языка программирования аналогична непонятности почему доллар является валютой такого масштаба.

Запилили ERP в АвтоВазе, а его Toyota купила… и офигела от учетной системы с кодом на русском. При ситуации наоборот, АвтоВаз купил Toyota, вы, как программист или системный администратор АвтоВаза были бы не очень рады получить на поддержку и развитие 10 000 000 строчек кода на японском. А вообще английский стал международным языком де-факто во второй половине/конце 20го века, и почти все языки программирования на английском. В эпоху глобализации это невероятно удобно. 99,9% программистов в мире умеют читать код на английском, и 95% из них только на английском либо родном языке. Да, в 19 веке международным языком был испанский, но представьте себе сейчас получить тонну исходников на испанском? Или на английском, что выберете вы?
Запилили ERP в АвтоВазе, а его Toyota купила… и офигела от учетной системы с кодом на русском.

вы преувеличиваете.
обычно ITшники головной корпорации особо не лезут внутрь таких систем
зачастую проще или поддерживать как есть или по новой всё перевнедрять по общим стандартам
Тем более 'головные ITшники' охренеют вникать в наши местные особенности учета и т.п… плюс в остальном мире гораздо менее популярно действие 'а давайте мы этот модуль сами своими силами запилим' если конторе не ИТнаправленности.
p.s. я работал в российской дочке одной корпорации, и мы пилили внутренний учет на 1С, американцы помнится фигели с нас 'ух нифига се вы там чё делаете'

Да, в 19 веке международным языком был испанский

а он и сейчас более распространен в мире чем английский… ;) (если по количеству носителей считать)

p.s. я, как русскоязычный человек, выбрал бы испанский, он к нам ближе
Это все доводы. Бесспорно нужно стараться придерживаться общих принципов и стандартов, но когда наверняка известно что продукт будет жить в компании «Ясное солнышко» (которая по роду деятельности будет только в россии) и нигде больше, тогда в чем смысл?
Наверное из-за того что 1С изначально жестко ориентировалась на отечественного потребителя так и получилось. Могу ошибаться, но это субъективное мнение.
Знание английского языка — это доп. навык который не у всех был/есть. Ведь возможности разработки на английском имеются. Мне видится это тогда как какой-то упрек в сторону людей. Что если ты не на английском пишешь — изгой.
Есть продукт, он выполняет свои задачи и функции, есть люди которые это обеспечивают… разве не главное чтобы в конечном счете была польза от продукта?
Сам не так давно начал изучать английский. Это интересно и весело. Потихоньку пробую и другие ЯП. Изучаю литературу.
Не все люди хотят развиваться. Ругать их теперь что ли за это?
Не все люди хотят развиваться

я бы переформулировал в «не все люди хотят развиваться так, как от них ожидают другие люди». Может человек в свободное время вместо английского языка изучает вязание или на тайский бокс ходит.
Да, так будет более точно
Программируем на C#. У нас запрещено что-либо переводить как с русского на англйский, так с английского на русский.
Всё — классы, методы, переменные, таблицы, столбцы, всё в 99% случаев на русском языке т.к. работаем в России с русско-говорящими сотрудниками и не хотим тратить их время на перевод с русского на английский и далее в обратную сторону когда кто-то другой вносит изменения в тот же код.
Исключение только для интеграции с внешними системами — если разработчики этих внешних систем назвали свои объекты/аттрибуты по английски, то в точности копируем их наименование, таким образом тоже исключаем трату ресурсов на перевод на русский и дальше в обратную сторону, когда во внешней системе что-то изменилось и нужно внести изменения в код.
Работаем в банковской сфере, в которой, казалось бы, не должно быть никаких проблем с международной терминологией. Однако, никто с ходу не знает как перевести «счет подотчета» (даже с использованием Google Translate), а когда смотришь на то, что разработчик назвал это AccountSubreport, хочется плакать.
Всё — классы, методы, переменные, таблицы, столбцы, всё в 99% случаев на русском языке т.к. работаем в России с русско-говорящими сотрудниками

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

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

Мне разок хватило, десяток лет назад, старого сервака на солярисе про который все забыли, tar которого не умел utf-8 в именах файлов и который чуть не запорол целое хранилище с документами при очередной миграции

а ещё помнб геморрой с переключением локали везде где Oracle DB клиент стоит, чтобы упасибоже в неправильной кодировке туда чтото не улетело
а почему у вас сотрудники-не программисты видят классы, методы, переменные и таблицы?

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

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

Мы так уже лет 15 делаем. Если и были какие-либо мелкие проблемы, то они просто несравнимы с N человек * 15 человеко-лет недо-переводов с русского на английский и обратно.

а ещё помнб геморрой с переключением локали везде где Oracle DB клиент стоит, чтобы упасибоже в неправильной кодировке туда чтото не улетело

Если вы таблицы со столбцами ещё можете назвать латиницей, то данные у вас в любом случае полетят в неправильной кодировке, так что проблема кодировки не связана с языком на котором называются объекты
Не замучились еще переключать раскладки?
К раскладкам привыкаешь… за неделю, может быть две.
К различным недо-переводам терминологии привыкнуть не возможно т.к. любой термин переводится разными сотрудниками по разному и в итоге никто ничего не понимает. С тем же успехом можно называть объекты A, B, C,… какая разница уже :)

ух! а можно пример класса с методами на русском языке? сам работаю в банковской сфере, но таких экспериментов не наблюдал...

Пожалуйста
private DataTable БалансКопейкиDT;
/// <summary>
/// Подгружает в форму остатки и обороты в копейках.
/// Заполняются только рубли и валюта, итого заполняется отдельно.
/// </summary>
public void ЗагрузитьБалансВКопейках()
{
    ДобавитьИнформацию("ЗагрузитьБалансВКопейках");

    БалансКопейкиDT =
        ASSql.ConnOper().ExecuteSpDt(
            "[обязательная-отчетность].[Ф0409101 - баланс в копейках]",
            "@ДатаНачало", ДатаНачало,
            "@ДатаОкончание", ДатаОкончание,
            "CommandTimeout", 600);

    foreach (var DR in БалансКопейкиDT.RowsDR())
    {
        var Раздел = Разделы[(string)DR["Символ раздела"]];
        var Счет = Раздел.Счета[(string)DR["Счет второго порядка"]];
        var Валюта = (string)DR["Рубли-Валюта"];
        var РублиВалюта =
            Валюта.StrEq("Рубли") ? Счет.Рубли :
            Валюта.StrEq("Валюта") ? Счет.Валюта :
            throw new DevMistakeException($"Не умею работать с записями [Рубли-Валюта]='{Валюта}'");

        РублиВалюта.Входящий.Копейки = (decimal)DR["Входящий"];
        РублиВалюта.Дебет.Копейки = (decimal)DR["Дебет"];
        РублиВалюта.Кредит.Копейки = (decimal)DR["Кредит"];
        РублиВалюта.Исходящий.Копейки = (decimal)DR["Исходящий"];

        foreach (var Значение in РублиВалюта)
        {
            Значение.Тысячи = Значение.КопейкиВТысячиПоМатематике;
        }
    }

    if (БалансКопейкиDT.RowsDR().IsEmpty())
    {
        ДобавитьОшибку("Странно, но не удалось загрузить баланс в копейках");
    }
}
(string)DR["Рубли-Валюта"];
DR["Счет второго порядка"]


… какой ужас… (тихонечко заплакал)

Значение.КопейкиВТысячиПоМатематике

… по какой блин математике…
НЛО прилетело и опубликовало эту надпись здесь
а есть окр15как20но25окртожекак20иокр35как40?
НЛО прилетело и опубликовало эту надпись здесь
я вообще имел в виду «округлять 0.5 в сторону четного», но даже не знаю, считать вашу шутку удачной или нет) сам не 1С-ник, возможно ваш юмор слишком тонкий для меня)

p.s. и я погуглил, в документации 1С только 2 варианта. Хотя должно быть 5 как минимум, как мне кажется.
НЛО прилетело и опубликовало эту надпись здесь

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


БалансКопейкиDT.RowsDR
а зачем это? если это все равно читают только программисты, разве у них возникают проблемы с переводом данных терминов?

Нет, конечно, с этими терминами проблем особых нет. Но как только разрешаешь переводить термины, такая чехарда начинается… я выше приводил пример про AccountSubreport. А главное… ну толку от того, что 5 полей из 10 будут названы по английски? Уж лучше всё по русски или всё по английски.

особенно убивает это: БалансКопейкиDT.RowsDR

Что именно вас тут убивает? :)

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

Как человек, который принимает участие в написании конфигураций на английском языке — могу Вам заявить, что все это фигня, что русский и английский — равноценны.
А вы посмотрели на это всё в отрыве от платформы?

80% универсальных обработок/отчетов, которые создавались обществом за все эти годы — не работают в конфигурации на английском языке. Только последний год, после пинания народа — они только начали задумываться над этим, а в основном авторы отвечают — «ну нам пофиг, мы то на русском пишем».

Начните применять нормальные технологии, для того же DevOps, и не отдельными конфигурациями 1С, которые заменяют наверное уже даже дженкинс (во всяком случае — пытаются), а вот реально взять и все это запустить на севрере, где стоит английская локаль, где нет поддержки кирилицы в консоле и т.д. — везде чудеса, крит в какой то обработке (в той же ванеесе) — на тебе ошибку "??? ??? ????????" и сиди теперь думай.
И вот тогда — будет понятно, что то, что было приимуществом (когда то), сейчас мешает 1С сообществу куда то двигаться.

По поводу перевода кода — это вообще бред, такое может позволить себе только компания 1С, никто больше себе такого позволить не может, та и это никому не надо.
на тебе ошибку "??? ??? ????????" и сиди теперь думай.
И вот тогда — будет понятно, что то, что было приимуществом (когда то), сейчас мешает 1С сообществу куда то двигаться.

Справедливости ради, корпоративный софт обычно в десятки раз более упоротый

Из того что я видел (названий уже не вспомню, чтото узкоспециализированное и страшно дорогое)
1) Наша программа работает с сервером SQL, серверная часть устанавливаться должна ТОЛЬКО на Windows XP SP1 (дело было в 2013 году), другие ОС мы не поддерживаем и не собираемся
2) Локаль в системе должна стоять — англ, разделитель разрядов — точка, формат даты — американский. нам не важно что вы тут не привыкли, так надо! менять мы не будем
3) пользователи должны иметь админские права, админ в нашей системе должен быть админом компа и иметь имя «Administrator» (в русской винде — переименовать, и вообще у нас в требованиях написано что винда должна быть везде англ)
… еще помнится какието приколы были подобного рода

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

это далеко не самый главный тормоз. я бы даже сказал что это чутьли не последняя проблема 1С в этом вопросе.

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

в том то и дело что такие системы не разработчики выбирают ;)
такие системы выбирает кто угодно, но меня справшивают — а сколько будет стоить, а сколько время займет?
А я такой сижу, и думаю — так, консоли запросов нормальной нет, выгрузки, загрузки и переносов объектов нет, универсального редактора и группового редактора объектов — нет, и выкатываю ценник в 100500 денег, на меня смотрят как на не далекого и говоря — а у нас там проект по УТ был, и там такое же сделали за 100 денег и один день.

А дальше что? правильно — проект срывается, так как одни считают по меркам конфигураций с русским кодом, а когда всплывает реальная цифра и сроки — то немного прифигивают :)
80% универсальных обработок/отчетов, которые создавались обществом за все эти годы — не работают в конфигурации на английском языке

Такое возможно, если вызываются методы прикладного кода (типа БСП), что не имеет отношения к платформе или при каких-то хитрых грязных хаках, когда допустим вручную правится текст запроса, без учета ключевых слов на английском. В общем случае — платформе пофигу на солянку из русского/английского синтаксиса.

Та же ванесса — open source, если вам нужна поддержка английской локали — можете ее добавить, думаю вам только спасибо скажут.
вы читайте не между строк, а целиком. Локаль английская в ванесе есть, и не без моей помощи, а код — русский, и когда там что то падает — то я вижу бред в логе, и ванеса — это просто как пример был приведен, а так все сплошное и везде.
Особенная беда в разработчиках из России, так как они вообще никогда не думают о других языках, и не используют ни одни рекомендации 1С по локализации решений и стандартов их написания.
Но это все не имеет никакого отношения к тому, что я писал выше.
Особенная беда в разработчиках из России, так как они вообще никогда не думают о других языках

Справедливости ради, забугорные разработчики тоже очень мало думают о других языках, несмотря на то что UTF существует много лет, с этим до сих пор проблемы
UTF — это проблема решабельная, а не проставленная НСтр — это проблема не решабельная :)
Ну так решайте решабельную проблему. Заставьте разработчиков поддерживать юникод в именах файлов и в выводе консоли, в чем проблема? Не, не хотят решать? Чем 1С тогда хуже?
И какое отношение имеет 1С к коду конкретных разработчиков, которые вопросом других языков не озаботились — не понимаю все еще.
вот в этом и проблема, что не только вы не понимаете :( И сам принцип интересен — типо если кто то что то не делает, то почему мы должны? Я верно уловил посыл?
Из серии — я на зло маме разобью коленки? :)

Ну и на будущее — читайте с первого комментария, тогда все поймете.
вот в этом и проблема, что не только вы не понимаете

смотрите, 1С позволяет писать код на английском. Но большинство 1С-ников пишет его на русском («так исторически сложилось»). Вы пишете код на английском и можете получить проблемы с универсальными обработками, причем не из-за языка, а из-за использования разработчиками универсальных решений, допустим, БСП. Да, увы, если вы эту библиотеку не используете — будет ошибка. Но это в любом ЯП так будет.

И сам принцип интересен — типо если кто то что то не делает, то почему мы должны? Я верно уловил посыл?

не совсем, верно. Посыл скорее в том, что «если все косячат, то нужно обсуждать проблему, а не одного выбранного представителя косячащих».

Ну и на будущее — читайте с первого комментария, тогда все поймете

Ну и на будущее, я вам и на первый комментарий отвечал, если вы не заметили. Так что я внимательно прочитал все. Боль понимаю, но согласиться с критикой не могу.
Нет, все намного проще. Представьте себе, что вам надо получить тип объекта.
Но, вы бегаете по массиву, и у вас получается что то типо:
СтрокаМетаданных + «Ссылка», что в итоге дает, например, «ДокументСсылка».
Если конфа на английском, то там аннотация DocumentRef, а если обработка написана криво, то вы получаете:
DocumentСсылка. А такого зверя, уже нет.

И таких примеров уйма, только последних пол года — год, что то начало меняться в этом направлении.
Так это пример, про который я говорил в самом начале. По сути это хаки, которые использовать не нужно. В конце концов, в той же БСП есть, если мне не изменяет память, функции получения вот этих «ДокументСсылка» и всяких модулей менеджера по переданной ссылке на объект.
Нет, все намного проще. Представьте себе, что вам надо получить тип объекта.
Но, вы бегаете по массиву, и у вас получается что то типо:
СтрокаМетаданных + «Ссылка», что в итоге дает, например, «ДокументСсылка».
Если конфа на английском, то там аннотация DocumentRef, а если обработка написана криво, то вы получаете:
DocumentСсылка. А такого зверя, уже нет.


Это снова не проблема мультиязычности, а проблема «рук из жопы». При чем это касается не только «разработчиков с Инфостарта», но и разработчиков типовых решений. Десятками видел подобные глюки в украинском Документообороте КОРП, где метаданные пытались искаться на украинском. А запись настроек в локали настройщика и сравнение со строковыми литералами в локали пользователя — это вообще родовая травма. Я для борьбы с этим вообще запретил всем использовать русский язык — все интерфейсы и ввод данных лишь на «державній мові»!
UTF — это проблема решабельная

лет через 200… может и решат, ага ;)

, а не проставленная НСтр — это проблема не решабельная :)

есть еще особо упоротые (не 1С) производители софта (взгляд в сторону гугла и гнусмаса) типа «заставляют насильно» разработчиков ставить локали без возможности их смены пользователям.
помню программу которая видя русский в телефоне, включала тайскую локализацию… и всё, ниче не сделаешь, официальный ответ «change phone language to english»
И у самсунговских часов точно такаяже история… нельзя поставить локаль часов отличную от телефона (я тогда пробовал английский ставить… это кошмар какойто, часы то ладно, но куча разного софта начинает английский контент показывать скрывая русский… причём наглухо без возможности его открыть)
А вы не ходите далеко — мобильная платформа 1с, все абсолютно также :)
НЛО прилетело и опубликовало эту надпись здесь
80% универсальных обработок/отчетов, которые создавались обществом за все эти годы — не работают в конфигурации на английском языке.

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

Хочешь инструменты разработчика в управляемой конфигурации? — Перезаходи в обычном толстом интерфейсе и только там запускай.

Хочешь запустить обработку 8.1 под 8.2-8.3? — Нужно сделать копию и пересохранить в конфигураторе нужной версии. Копия нужна, так как эта обработка теперь перестанет работать под 8.1

Хочешь в типовых или отраслевых конфигурациях, которые создавали под 8.2, но которые сейчас у тебя в режиме совместимости на одной из последних версий платформы 8.3 работать с консолью запросов (даже той, что с ИТС) и вызвать в режиме приложения типовой конструктор запроса? — Досвидос и перезагрузка! Встроенная обработка не понимает режимов совместимости и написана с использованием новых функций по работе со строками…

И такие «бока» куда не сунься. Универсальных отчетов и обработок даже для русскоязычных конфигураций просто не бывает. Всюду есть нюансы.
Ну почему вот этот отрывок: " Гораздо важнее, чтобы мы – в команде, на предприятии, в отрасли – понимали друг друга с минимальными издержками на трансляцию смысла через текст. Тогда, и только тогда наша работа будет эффективной, а количество ситуаций «Что-то пошло не так» будет сведено к минимально возможному." напомнил мне насколько реальность отличается от того, что пишут люди. Напомнил мне слово Ложь. Или False. Как кому удобнее в двуязычном синтаксисе 1с.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь

Представление это наверное интересно. Особенно, когда актеры хорошо играют и сценарий хороший. Но когда пытаются выдать функцию запроса к СУБД за формат отображения типа Булево в полях и табличных документах, то это звучит странно.

НЛО прилетело и опубликовало эту надпись здесь

Формат(выражение, форматнаястрока)

НЛО прилетело и опубликовало эту надпись здесь

Для пользователя отображение Булево происходит в полях формы, в полях ТЧ, табличных документах (скд). Для каждого поля формы или скд разработчик может задать формат Даты, Числа, Булево.
Представление — это функция Запроса.
Я тоже когда вы упомянули Представление подумал, а при чем здесь запрос.

НЛО прилетело и опубликовало эту надпись здесь

Извините, но ROFL.

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

они в большинстве своем даже не догадываются что существуют другие языки (кроме возможно Испанского) и вообще страны… в староглинянные времена (до середины 2000х) это выливалось в существенные проблемы во многих местах (чего стоит насильное перекодирование писем почтовыми серверами из какихто странных кодировок в 'правильные')

ну как собственно и программисты 1С ;)
Программирование на родном языке возможно главный фактор формирующий успешное сообщество-программистов; А ни для кого не секрет, что именно такие сообщества ключ к успеху.
Времена когда писали на ассемблере прошли; Программирование теперь ближе к естественному языку. Функции сейчас стараются называть длинно-и-сочно. И в этом есть большой смысл.
Вот посмотрите на Гарвардский курс CS50; Первое впечатление — чепуха для дет-сада; А тем не менее, кое какая идея есть. И как мне показалось — гораздо важнее научить программиста структурированно излагать мысли на родном языке, чем жонглировать аббревиатурами на чужом.
возможно главный фактор формирующий успешное сообщество-программистов;

давайте пример такого успешного сообщества с 'родным-не-английским' языком.

миста в мире 1С не в счет… это вообще обитель зла и ужаса
НЛО прилетело и опубликовало эту надпись здесь
COMОбъект передает привет.

И еще:
Указатель.GetTheCurrentOrderStatus()
а разве артикли в идентификаторе — это хорошая практика?
НЛО прилетело и опубликовало эту надпись здесь

Не открывайте сгоряча. Вот вам нужно подписать JWT. Нативные методы подписи только по PKCS #7, а нужно PKCS #1. Ваши действия?

Артикль в имени метода вряд ли можно назвать хорошей практикой, но что, если эту систему писал специалист, плохо владеющий английским и вынужденный поэтому перегонять все изобретенные термы со своего родного языка на английский через Google Translate? То есть мы имеем дело не с осознанным применением той или иной лексемы, а с чисто механическим «Копировать-вставить». Овладение чуждым языком – вовсе не такая простая задача, какой нам ее рисуют агенты по продаже разнообразных ускоренных курсов.
Пишу в 1с на русском и не вижу в этом ничего зазорного. У нас все клиенты русскоязычные, так что смысла в использовании другого языка не вижу. А вот когда открываешь конфигуратор и видишь строку типа ЗаписьJSON = Новый ЗаписьJSON или Соединение = Новый HTTPСоединение или прочую кашу с использованием двух языков, ну как-то это некрасиво)
А вообще, считаю что и 1снику знать английский лишним не будет
НЛО прилетело и опубликовало эту надпись здесь
Переменную можно как угодно обозвать, а вот объект, который предопределен в системе, по другому, кроме как ЗаписьJSON, не вызвать. На мой взгляд, это не особо красиво, но от этого никуда не уйти. А вот когда переменные называют англоязычно, когда основной код написан на русском — это уже не очень удобно.
Может быть в среде настоящих программистов так принято, я не знаю.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
что на английском оператор, процедура, функция звучит однозначно что она делает, а на русском есть варианты, мягко говоря

можете пояснить?

А вы не сталкивались с тем, что на котлин делается в 10 строк, в 1с надо писать целую портянку?

а я сталкивался с тем что в 1С делается тремя кликами мышки, а в котлине/яве/и т.п. надо писать огроменную программу

вообще над отсутствием ООП в 1С уже помоему должно было надоесть издеваться, есть другие языки без ООП (тот же Си) и никто особо не кукарекает по этому поводу (разрешено только закатить глаза и цокать языком от осознания какой это гениальный язык без изъянов)
НЛО прилетело и опубликовало эту надпись здесь
Пример с лету не приведу, но описание в котлин и в голанг для функций./процедур короче и результат предсказуем


у вас просто предвзятое мнение, как собственно и у многих
голанг, на мой взгляд вообще наркоманский язык, из которого решительным движением выкинули ООП, а потом всякими жуткими костылями пытаются вернуть этот функционал обратно… а обработка исключений через одно место?

неоднозначние поведение тоже много где бывает, котлин всётаки язык современный, а вот возьмите finalize у java, где даже в документации написано что они там накосячили так что никто не знает когда оно срабатывает… и типа 'не используйте теперь"

Потом раз вы сказали котлин… вы скорее всего его имеете в виду в связке с андройдом? андройд сам по себе пример просто бесконечно и катастрофически кривой архитектуры… где теряются интенты (не пришел интент что интернет вернулся… и всё, будешь куковать с приложением которое думает что его нет, а попробовать подключится даже пытаться не будет), данные между формами надо передавать чутьли не на ездовых собаках через северный полюс… по умолчанию приложения плодят кучу экземпляров форм которые фактически как разные приложения запускаются… и это при том что платформа развивается, помоему процентов 70% апи уже задеприкейчено… причем вплоть до того что в 6 андройде чтото новое ввели, а в 8 уже выпилили.
1С тут со своим переходом 8.2-8.3 прямо образец стабильности.

ну а частности с json это конечно косяк 1С, которая несмотря на прогрессивность (как платформы для бизнеса) очень консервативная.
То что в котлин, голанг одной строчкой распаршивантся в структуру, в 1с целая процедура нужна для этого. И ещё не забыть про даты.

Это не то?
Глобальный контекст (Global context)

ПрочитатьJSON (ReadJSON)

Синтаксис:
ПрочитатьJSON(<ЧтениеJSON>, <ПрочитатьВСоответствие>, <ИменаСвойствСоЗначениямиДата>, <ОжидаемыйФорматДаты>, <ИмяФункцииВосстановления>, <МодульФункцииВосстановления>, <ДополнительныеПараметрыФункцииВосстановления>, <ИменаСвойствДляОбработкиВосстановления>, <МаксимальнаяВложенность>)

Параметры:
<ЧтениеJSON> (обязательный)
Тип: ЧтениеJSON.
Объект чтения JSON.
<ПрочитатьВСоответствие> (необязательный)
Тип: Булево.
Если установлено Истина, чтение объекта JSON будет выполнено в Соответствие.
Если установлено Ложь, объекты будут считываться в объект типа Структура.
Примечание. При десериализации объектов JSON в структуру необходимо помнить о требованиях к ключам структуры. Если при десериализации объекта будет найдено имя свойства, недопустимое для ключа структуры, то будет вызвано исключение.
Значение по умолчанию: Ложь.
<ИменаСвойствСоЗначениямиДата> (необязательный)
Тип: Массив, Строка, ФиксированныйМассив.
Массив, элементы которого содержат имена свойств JSON, для которых нужно вызывать восстановление даты из строки.
Если имя свойства указано в этом параметре и указано в параметре ИменаСвойствДляОбработкиВосстановления, то для таких свойств восстановление осуществляется в функции восстановления.
Если восстановление даты из значения свойства невозможно, то будет сгенерировано исключение.
Значение по умолчанию: Неопределено.
<ОжидаемыйФорматДаты> (необязательный)
Тип: ФорматДатыJSON.
Ожидаемый формат даты при десериализации объекта в формате JSON.
Если в результате десериализации значение не является строкой и имеет формат даты, отличный от ожидаемого, то будет вызвано исключение.
Значение по умолчанию: ISO.
<ИмяФункцииВосстановления> (необязательный)
Тип: Строка.
Данная функция вызывается при чтении каждого свойства и должна иметь следующие параметры:
<Свойство> — значение типа Строка, указывается только при чтении объектов JSON,
<Значение> — значение допустимого для сериализации типа,
<ДополнительныеПараметры>.
Возвращаемое значение — произвольного типа.
Если данный параметр задан и не задан параметр <МодульФункцииВосстановления>, и наоборот, будет вызвано исключение.
Если функция не установлена, то при вызове метода ПрочитатьJSON параметр <ИменаСвойствСоЗначениямиДата> игнорируется.
Значение по умолчанию: Неопределено.
<МодульФункцииВосстановления> (необязательный)
Тип: Произвольный.
Указывает модуль, процедура которого будет использована для восстановления значения.
Значение по умолчанию: Неопределено.
<ДополнительныеПараметрыФункцииВосстановления> (необязательный)
Тип: Произвольный.
Дополнительные параметры, которые будут переданы в функцию восстановления значений.
Значение по умолчанию: Неопределено.
<ИменаСвойствДляОбработкиВосстановления> (необязательный)
Тип: Массив.
Массив имен свойств JSON, для которых будет вызвана функция восстановления.
Параметр игнорируется, если не установлен параметр ИмяФункцииВосстановления.
Значение по умолчанию: Неопределено.
<МаксимальнаяВложенность> (необязательный)
Тип: Число.
Максимальный уровень вложенности объекта JSON.
При превышении уровня вложенности будет сгенерировано исключение.
Значение по умолчанию: 500.
Возвращаемое значение:
Тип: Произвольный.

Описание:
Считывает значение из JSON-текста или файла. JSON-текст должен быть корректным.

Доступность:
Тонкий клиент, сервер, толстый клиент, внешнее соединение, мобильное приложение (клиент), мобильное приложение (сервер), мобильный автономный сервер, интеграция.

Примечание:
Массив будет десериализован в массив. Объект JSON будет преобразован в соответствие или структуру (если ключ структуры окажется недопустимым, будет вызвано исключение).
Для дат действует аналогично методу ПрочитатьДатуJSON.
Во время выполнения метода может быть вызвана пользовательская функция для восстановления значения — для этого следует использовать параметр <ИмяФункцииВосстановления>. Функция восстановления должна быть описана с директивой &НаСервере или &НаКлиенте. Использование функции вне контекста не допускается.

Использование в версии:
Доступен, начиная с версии 8.3.6.


Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории