Novell ставит цели

> Б. Страуструп, Язык C++: -- Слово "statement" принято переводить на русский язык как "оператор". Мы привыкли к тому, что if, while, case и т. д. - это операторы. Увы, в контексте С++ такой перевод неприемлем. Дело в том, что в С++ слово "operator" (которое и переведено как "оператор") имеет совсем другое значение. Оно применяется для обозначения сложения (оператор +), разыменования (оператор *), выяснения размера (оператор sizeof ()) и в других подобных случаях…

Перевод Страуструпа очень плохой, любительский. В других переводах той же книги правильный термин (погуглите): operator -- "знак операции", термин это ШКОЛЬНЫЙ, ИЗ ЭЛЕМЕНТАРНОЙ АЛГЕБРЫ (!!!). А вот "++" -- это действительно оператор (statement). Operator overload -- перегрузка операции.

Доводилось обсуждать с преподавателями из СПбГТУ эту проблему, тдержа в руках два перевода Страуструпа и... учебник арифметики для 3 класса :))))) Согласились со мной после показа школьного учебника... :)))

> …Что же касается термина "statement", то из предлагаемых различными словарями вариантов "утверждение", "предложение" и "инструкция" мы избрали последний, так как он, по-видимому, лучше всего соответствует сущности обозначаемых словом "statement" конструкций С++ и, кроме того, периодически встречается в книгах и документации в нужном значении… --

А это уже полная беда: либо редактор безграмотный, либо перевод не проходил редактуру. "Книги и документация" сейчас тоже грамотрую редактуру проходят не всегда. Так вот, назвать "инструкцией" МАШИННУЮ КОМАНДУ -- это транслитерация, но вполне понятная. Здесь это чистейшей воды пальцем в небо, причём это рассуждение НЕ СТРАУСТРУПА, А ИЗЛИШНЕ "УМНОГО" ПЕРЕВОДЧИКА. Чей перевод, кстати?

> statement - это выражение.

Два балла по основам и информатики, и английского. sign(a**b-c) -- это выражение, но не statement, a expression.

демагогия.
менеджер - это именно руковoдитель.
Микрософтовцы строжайше должны были запретить именно "ответственное лицо" - я правильно понял? (М$ разве может быть ответственнен за что-либо?)

ответственное лицо - "in charge of".
манагер может быть in charge of a project, а может и не быть.
Ответственное лицо в русской семантике наверное можно перевести обратно как official (не знаю точно семантику русского употребления).

Господа - в переводах нет обратных функций, и даже прямых функций нет, надо знать употребление.
это, как я много раз говорил, отображение (если не хотите маппинг) конкретных случаев употребления (я называл также объектами) - на конкретный язык. В случае с другим языком - другое отображение (реальности в язык) a словари - подборка каких-то корреляций (one-to-many, не всегда исчерпывающая), а выбор - за переводящим спецом, чтобы сохранить семантику (где словарь кстати больше вредит)

> Т.е. либо определяй смысл слов в начале книги/статьи, либо пиши его на английском.

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

> Вообще, проблемы с `ЗАБЫЛИ ПОКАЗАТЬ ЭТОТ САМЫЙ ДОГОВОР' не существует, ибо из контекста всегда понятно более-менее все. А identifier /operator /statement имеют кучу значений и в английском, так что перевод тут не при чем.

Ошибаетесь. Мне довелость просматривать советы по нетбинзу на сановском сайте, так вот, в разных статьях разные авторы один и тот же объект называют кто component, кто control, а кто widget. И из контекста понятно далеко не всё.

Вы подняли проблему разгильдяйского английского. Да, она существует и стоит очень остро. Возвращаясь к Микрософту: в микрософтовсой тех. документации этой проблемы практически НЕТ, разработчики документов ВЫШКОЛЕНЫ. И это есть ПЛЮС, так как не надо разгадывать шарады.

> Если вы не можете осознать язык как объективную сущность безотносительно конкретного человека (так же как государство, культуру и др.)

не могу

> Перевод Страуструпа очень плохой, любительский. В других переводах той же книги правильный термин (погуглите): operator -- "знак операции", термин это ШКОЛЬНЫЙ, ИЗ ЭЛЕМЕНТАРНОЙ АЛГЕБРЫ (!!!). А вот "++" -- это действительно оператор (statement). Operator overload -- перегрузка операции.

Неохота гуглить. Я по крайней мере затруднений при прочтении книги не испытал никаких, так что думаю, все ваши измышления - банальный overkill (перевод, кстати?). Читай: недостойно заморачиваться на эту тему.

> Чей перевод, кстати?

(C) Перевод с английского. <<Невский Диалект>>, 1999, 2001

> Ошибаетесь. Мне довелость просматривать советы по нетбинзу на сановском сайте, так вот, в разных статьях разные авторы один и тот же объект называют кто component, кто control, а кто widget. И из контекста понятно далеко не всё.

Хм. То есть все плохо. Но тут имхо спорить не о чем :)

> демагогия.

> менеджер - это именно руковoдитель.

Нет. Мне сказали, что это не так, что вызвало у меня крайнее изумление. Руководитель -- это Lead, старший руководитель -- Executive. Что касается manager, видимо, либо "руководитель" оно значит в Англии, либо кто-то один раз не разобрался, а дальше пошло-поехало. Впрочем, если задуматься, там, где это слово употребляется в английском, подстановка вместо него "ответственного лица" не приводит ни к каким противоречиям.

> Микрософтовцы строжайше должны были запретить именно "ответственное лицо" - я правильно понял? (М$ разве может быть ответственнен за что-либо?)

Да, правильно. В микрософтовском словаре нет ни слова "менеджер", ни словосочетания "ответственное лицо" :)))

> ответственное лицо - "in charge of".

Это уголовная ответственность. Здесь имеется в виду иной род ответственности, не уголовный, а ответственность за состояние дел. Sales manager -- ответственный за продажи, а не руководитель продаж. И т.д.

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

> Только что по быдловизору был репортаж про то, что в автобусах теперь будут правила русского языка рассказывать (куда ударение ставить).

В Москве давно уже в маршутках такое.

> Неохота гуглить.

Зря. Первое или второе попадание.

> Я по крайней мере затруднений при прочтении книги не испытал никаких, так что думаю, все ваши измышления - банальный overkill (перевод, кстати?). Читай: недостойно заморачиваться на эту тему.

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

>> Чей перевод, кстати?

> (C) Перевод с английского. <<Невский Диалект>>, 1999, 2001

По-французски это называется le vaque.

Найду эту лавку, покажу им учебник арифметики :))) ТОлько думаю, они бабло срубили и свалили :((( А их диалект к невскому никакого отношения не имеет :(((

> ок, лоханулся, _оператор_ цикла конечно.

> может лучше тогда - конструкция - чтобы не конфликтовать с плусонутыми операторами.

Конструкция -- для слова clause вполне нормально, для statement не годится.

> Или говорить парой - оператор ветвления, оператор цикла

До перестройки так и говорили. +100.

> , в разных статьях разные авторы один и тот же объект называют кто component, кто control, а кто widget

нет, здесь всё просто.
контролями называют прошлые виндузятники (IE-control и пр), widget- те кто пришёл из Unix.
component - жаба-вей. Если переводите нетбинс - component однозначно.
А те кто в яве methods называют member-functions или components - виджетами - выё^пендриваются (показывая что пришли из C++, Unix)

> Вы не правы. Вы привыкли к поганому языку, а школьникам этот перевод давать в руки ни в коем случае нельзя.

Логика? Привыкнут к поганому языку и тоже не будут испытывать проблем.

> Если переводите нетбинс - component однозначно.

Напрямую не катит. Cловом "компонент" в J2EE переводится "bean", так что придётся либо переводить весь этот зоопарк как "элемент управления", либо трясти разработчиков документации и заставлять их договариваться друг с другом.

>> Вы не правы. Вы привыкли к поганому языку, а школьникам этот перевод давать в руки ни в коем случае нельзя.

> Логика? Привыкнут к поганому языку и тоже не будут испытывать проблем.

Логика простая. Ни к чему они привыкать не будут, просто пошлют нафиг программирование и будут воровать лес, катать левую водку или спекулировать землёй, благо гораздо выгоднее. А нам на работу придётся брать китайцев :(((((((

> Логика простая. Ни к чему они привыкать не будут, просто пошлют нафиг программирование и будут воровать лес, катать левую водку или спекулировать землёй, благо гораздо выгоднее. А нам на работу придётся брать китайцев :(((((((

Ну это уже, простите, бред.

"in charge of project" - это именно "ответственный за проект". это не уголовная ответственность :)


>Руководитель -- это Lead, старший руководитель -- Executive. Что касается manager, видимо, либо "руководитель" оно значит в Англии, либо кто-то один раз не разобрался, а дальше пошло-поехало.

Executive - скорее управляющий.
наверное в штатах и в англии - разные классификации и традиции менеджмента.
Потом многое перекрывается (менеджер проекта = project lead почти всюду где я был).

Хотя lead - скорее ближе к тому кто что-то может делать руками, наверное. manager - тот кто ходит, пинает, реальную работу не делает, да и не может, других погоняет.

>> Логика простая. Ни к чему они привыкать не будут, просто пошлют нафиг программирование и будут воровать лес, катать левую водку или спекулировать землёй, благо гораздо выгоднее. А нам на работу придётся брать китайцев :(((((((

> Ну это уже, простите, бред.

Ничего подобного. Так и происходит. У меня знакомый мальчишка, хорошо разбиравшийся в ИТ и весьма грамотный, походил-походил на разные занятия, в том числе в СПбГТУ, да и пошёл в ПТУ на повара :(((

И в отделочники много ребят идёт, и в авторемонт, а выпускники вузов по специальности "ИТ" просто никуда не годны -- в приличных конторах месяцами висят объявления о приёме на работу, только выпускники эти в них работать не могут :(((

> Хотя lead - скорее ближе к тому кто что-то может делать руками, наверное. manager - тот кто ходит, пинает, реальную работу не делает, да и не может, других погоняет.

Я lead по языку, и мне объясняли мою задачу как ходить и пинать, исполнителей погонять, и ещё образовывать их. Так что наоборот, manager что-то может делать руками.

> Потом многое перекрывается (менеджер проекта = project lead почти всюду где я был).

Это не перекрытие, а банальная экономия на ставках (урезанная структура управления).

> И в отделочники много ребят идёт, и в авторемонт, а выпускники вузов по специальности "ИТ" просто никуда не годны -- в приличных конторах месяцами висят объявления о приёме на работу, только выпускники эти в них работать не могут :(((

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

bean - это конечно компонент, но всё-же его лучше не переводить (или как боб:) - это же маркетинговое имя порождённое санями.
потом - всё компонент.
Если переводите - то переводите Apache индейцем и в таком роде.
Bean это Bean.

>Я lead по языку, и мне объясняли мою задачу как ходить и пинать, исполнителей погонять, и ещё образовывать их. Так что наоборот, manager что-то может делать руками.

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

>Это не перекрытие, а банальная экономия на ставках (урезанная структура управления).
а зачем столько нахлебников нужно?
если lead "in-charge of project" - он и будет подгонять, либо сам делать (если не может эффективно погонять), и отчитываться уже перед менеджером отдела или архитектором

> Ничего подобного. Так и происходит. У меня знакомый мальчишка, хорошо разбиравшийся в ИТ и весьма грамотный, походил-походил на разные занятия, в том числе в СПбГТУ, да и пошёл в ПТУ на повара :(((

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

> а манеджер у вас что тогда делает - если Вы и образовываете, и с палкой?

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

> молодец парень - реальную работу выбрал, а не жить на вулкане.

> И за его будущее можно не беспокоится.

Лет в 40 гарантированные проблемы с сердцем (как у кочегаров, литейщиков и банщиков). :((( А так да, работа реальная.

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

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

добавление:
в отличие от тех где все повально валят на менеджмент и продажи - исключительно для того чтобы не перенапрягаться и _не_работать_

> bean - это конечно компонент, но всё-же его лучше не переводить (или как боб:) - это же маркетинговое имя порождённое санями.

Переводить слово bean как "компонент" -- требование разработчиков технологии :((( Редакционный отдел СПбГТУ отдыхает :)))

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

+inf

За будущее Косова беспокоиться нужно: там публика не умеет делать НИЧЕГО, даже воздух сотрясать, только торговать героином :(((((

И всё-же это неправильно: прочитав русскую книгу где бины названы компонентами - я бы запутался, даже имея многолетний опыт и с просто бинами (образца 98 года), и с JSP бинами, и с компонентными архитектурами и с GUI-компонентами и с EJB-бинами, и с JSF-бинами (managed beans). О каких компонентах идёт речь???
А что говорить о тех кто читаыет первый раз?? И ещё не встречает бинов в книге про бинов где они обозваны компонентами?

короче или называйте бины бинами или переждите пока сегодня модные технологии уйдут в небытиё (как те бины 98 года) и уже почти - EJB-бины (немного осталось), но не увеличивайте ентропию и не запутывайте молодых людей. Mожет по-этому они и в повара идут? ;) что с другой стороны хорошо. ОК, делайте своё дело! запутывайте! :)

> И всё-же это неправильно: прочитав русскую книгу где бины названы компонентами - я бы запутался, даже имея многолетний опыт и с просто бинами (образца 98 года), и с JSP бинами, и с компонентными архитектурами и с GUI-компонентами и с EJB-бинами, и с JSF-бинами (managed beans). О каких компонентах идёт речь???

> А что говорить о тех кто читаыет первый раз?? И ещё не встречает бинов в книге про бинов где они обозваны компонентами?

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

> прочитав русскую книгу где бины названы компонентами - я бы запутался, даже имея многолетний опыт и с просто бинами (образца 98 года), и с JSP бинами, и с компонентными архитектурами и с GUI-компонентами и с EJB-бинами, и с JSF-бинами (managed beans).

Именно потому и запутались бы, что опыт многолетний.

> а component как элемент управления (а к этому идёт) -- будем
переводить

То что кто-то хочет видеть их через призму контейнеров - их меркетинговое дело. Я согласен с элементом (радио-компонент) но не согласен с "управления"

> Именно потому и запутались бы, что опыт многолетний.

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

Не надо паники. Проверяющий новости - Шаман. Наверняка по ссылке совсем другое сказано.

> Прикажут переводить bean как компонент, а component как элемент управления (а к этому идёт) -- будем переводить.

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

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

+100

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

Такой подход устроит университеты, но никогда не устроит КОРПОРАЦИИ. Первым достаточно единиц профессионалов высочайшего класса, выросших на костях тысяч несостоявшихся специалистов, а вторым нужна именно МАССА профессионалов, пусть не заоблачного качества, но способных строить что-то на основе их технологий. Собственно, корпорации нужно то же, что нужно было социализму, потому и подход очень близкий. А противоположный (университетский) подход -- это подход СРЕДНЕВЕКОВЫЙ, ЦЕХОВОЙ. В науке проходит первый, в производстве -- второй. Я говорю о втором, мне -- о первом как об абсолютной истине. Мы о разном, господа. И пора понять, где вы работаете. Я знаю, где работаю я и для кого предназначены результаты моей работы.

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

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

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

То есть, господа, всё замечательно, но... для другой социальной системы. Которая, увы, конкурентоспособна далеко не во всём. И динамизм отнюдь не является её сильной стороной.

> Такой подход устроит университеты, но никогда не устроит КОРПОРАЦИИ. Первым достаточно единиц профессионалов высочайшего класса, выросших на костях тысяч несостоявшихся специалистов, а вторым нужна именно МАССА профессионалов, пусть не заоблачного качества, но способных строить что-то на основе их технологий.

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

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

> способных строить что-то на основе их технологий.

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

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

Да? Я вот работаю в корпорации, например. В офисе сидят поляки, голланцы, немцы, французы, итальянцы, корейцы, англичане, ирландцы, американцы, австралийцы, индусы и т.д. И корпорации похрену эти лингвистические выкрутасы - намного важнее что бы люди как-то могли общаться между собой. И государству, в котором стоит офис в свою очередь похрену на каком сленге говорят люди в корпорации - потому что эти люди приехали из своих стран сюда работать и платят государству налоги. А если оно, государство, будет дурковать и навязывать какие-то непонятные термины - люди просто разъедутся по другим странам и будут платить налоги там, а не тут.

> А противоположный (университетский) подход -- это подход СРЕДНЕВЕКОВЫЙ, ЦЕХОВОЙ. В науке проходит первый, в производстве -- второй. Я говорю о втором, мне -- о первом как об абсолютной истине. Мы о разном, господа. И пора понять, где вы работаете. Я знаю, где работаю я и для кого предназначены результаты моей работы.

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

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

> Да? Я вот работаю в корпорации, например. В офисе сидят поляки, голланцы, немцы, французы, итальянцы, корейцы, англичане, ирландцы, американцы, австралийцы, индусы и т.д. И корпорации похрену эти лингвистические выкрутасы - намного важнее что бы люди как-то могли общаться между собой. И государству, в котором стоит офис в свою очередь похрену на каком сленге говорят люди в корпорации - потому что эти люди приехали из своих стран сюда работать и платят государству налоги. А если оно, государство, будет дурковать и навязывать какие-то непонятные термины - люди просто разъедутся по другим странам и будут платить налоги там, а не тут.

Вы производитель, а я о клиентах, причём не из корпоративного сектора, а из SoHo и индивидуалах. Тем, кто пишет тех. документацию на ПРОДУКЦИЮ ВАШЕЙ КОРПОРАЦИИ, далеко не наплевать, каким языком она будет написана: от этого напрямую зависит сбыт. Вы со свиоим лингвистическим отделом ещё не имели дела, или Вы от него слишком далеко?

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

Я перевожу документацию, которую корпорации (Микрософт, Новелл, Вольво, Самсунг, Нокия, Филипс и т.п.) выпускают для ПОТРЕБИТЕЛЕЙ своей продукции. Я не занимаюсь переводами ВНУТРЕННЕЙ документации корпораций и сомневаюсь, что её надо переводить.

Я не имею в виду простоту бизнеса. Все бизнесы разные, но есть общие, стандартные процессы (так-же как и в бухгалтерии). Раз написанная система аналогичная SAPу или Оракле ERP - будет иметь вокруг специалистов специализирующихся на подстройке, опять-же из университетов. А что, недоучки без опыта - смогут сконфигурировать SAP? А что, SAP сложнее чем хотя-бы тот-же линукс overall?
Зачем платить миллионы каждый год ораклу спонсируя все их совершенно ненужные проекты-эксперименты, когда то что бизнесам надо - это реляционная база уровня 7.3 (год 98)? Если допилить PostgreSQL и платить иногда в 10 раз меньшие суммы за поддержку всеми госструктурами и бизнесами - то свободная база будет цвести и пахнуть везде. Вспомним коммерческие юниксы - где они и где линух. Опять-же - сложность операционки - во много раз больше чем многие из продуктов, которым как-бы и нет замены.
Сейчас сотни людей делают одну и ту-же работу паралельно, в разных компаниях, кормя кучу нахлебников, делая это плохо (так как они не лучшие). Потому всё медленно, сложно, багово.

anonymous (*) (22.03.2008 6:51:58)

+10

> Вы производитель, а я о клиентах, причём не из корпоративного сектора, а из SoHo и индивидуалах. Тем, кто пишет тех. документацию на ПРОДУКЦИЮ ВАШЕЙ КОРПОРАЦИИ, далеко не наплевать, каким языком она будет написана: от этого напрямую зависит сбыт.

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

> Вы со свиоим лингвистическим отделом ещё не имели дела, или Вы от него слишком далеко?

У нас не держат ненужные отделы :-)

> Я перевожу документацию, которую корпорации (Микрософт, Новелл, Вольво, Самсунг, Нокия, Филипс и т.п.) выпускают для ПОТРЕБИТЕЛЕЙ своей продукции. Я не занимаюсь переводами ВНУТРЕННЕЙ документации корпораций и сомневаюсь, что её надо переводить.

Ну и какие проблемы? У потребителей в ходу "неправильная" терминология и ваш лингвистический отдел хочет их улучшить?

> И с клиентами на каждом уровне в корпорации общается человек соответствующего уровня на своём, устоявшемся на этом уровне, жаргоне, понятном и привычном обоим сторонам.

Вы не выпускаете массовой продукции, правильно?

> Один и тот же продукт на уровне бизнеса может и документироваться даже по-разному, в терминах бизнеса.

???!!! У вас несколько типов документации для корпоративных клиентов?

> А на уровне индивидуальной продукции - там и вовсе технической терминологии нет.

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

>> Вы со свиоим лингвистическим отделом ещё не имели дела, или Вы от него слишком далеко?

> У нас не держат ненужные отделы :-)

Ваша компания не снабжает продукцию документацией, или для перевода документации достаточно внешних исполнителей без сопровождения вашими специалистами? Это рискованно, даже для совсем простой продукции!

> У потребителей в ходу "неправильная" терминология и ваш лингвистический отдел хочет их улучшить?

У потребителей продукции одних компаний терминология отличается от внутренней терминологии производителей. Для потребителей другой продукции общепонятность терминологии документации определяет объём сбыта, хотя продукция эта не является простой (смартфоны, видео- и фотокамеры, не говоря про ПО).