Добрый день!

Дон Бокс, известный моралист, решил <b>описать Индиго в двух словах</b>.

Indigo connects software together using structural contracts (a.k.a. schemas) and behavioral contracts (a.k.a. message exchange patterns).

Индиго объединяет приложения с использованием структурных контрактов (схемы) и поведенческих контрактов (сценарии обмена сообщениями).

We integrate with the CLR and COM and eviscerate your local types into either data contracts or service contracts, but never both. An especially cool feature of Indigo is that the sender and receiver don't need to share the same CLR types (nor do both sides even need to be Indigo or CLR or COM).

При интеграции Индиго с CLR и COM ваши локальные типы преобразовываются или в контракты данных, или в контракты обслуживания, но не одновременно. Ценная отличительная особенность — для удалённой работы НЕ необходимо наличие тех же сборок и на сервере и на клиенте (нет даже необходимости в таком же Индиго, CLR или COM на другой стороне шнура).

The messages we use in Indigo are based on the SOAP processing/data model but don't use angle brackets unless we are forced to, and when forced to, we do it happily and pretty damn fast.

Индиго основывается на сообщениях SOAP и на модели SOAP, но навязывает разработчку угловые скобки (то есть, знание XML). Впрочем, доступ к XML не закрыт и несложен.

We support a variety of message transports and support both transport-level and SOAP-level security and reliability.
[q]

Для безопасности и надёжности поддерживаются и сервисы транспортного уровня и средства SOAP.

Oh yeah, and we integrate tightly with System.Transactions and a queueing system.
[/q]

Естественно, в Индиго интегрирована поддержка транзакций и очередей сообщений (гарантированая доставка).


Ми.

Здравствуйте, mihailik, Вы писали:

M>

M>The messages we use in Indigo are based on the SOAP processing/data model but don't use angle brackets unless we are forced to, and when forced to, we do it happily and pretty damn fast.

M>Индиго основывается на сообщениях SOAP и на модели SOAP, но не навязывает разработчку угловые скобки (то есть, знание XML). Впрочем, доступ к XML не закрыт и несложен.

Я бы не добавил (смотри оригинал...) и соотв-но 2-я часть меняет смысл.

К>Я бы не добавил (смотри оригинал...)

Ой, вот идиотская опечатка!

Спасибо за подсказку

Здравствуйте, mihailik, Вы писали:

Так и вижу следующее введение в Ххх от донбокса:

Ххх — это все, все, все, ...

Здравствуйте, mihailik, Вы писали:

M>

M>The messages we use in Indigo are based on the SOAP processing/data model but don't use angle brackets unless we are forced to, and when forced to, we do it happily and pretty damn fast.

M>Индиго основывается на сообщениях SOAP и на модели SOAP, но навязывает разработчку угловые скобки (то есть, знание XML). Впрочем, доступ к XML не закрыт и несложен.
Именно про такие переводы негативно отзывался Гоблин. Потому, что на самом деле там написано:

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

S>Именно про такие переводы негативно отзывался Гоблин.

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


S> Потому, что на самом деле там написано:

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

Здравствуйте, mihailik, Вы писали:
Для аннотации это, конечно, неважно. Просто на первый взгляд казалось, что ты переводишь именно подстрочно, и весь текс. При этом ты совершенно изменил живой и интересный стиль Бокса на совершенно ужасную наукообразную сухость. А местами пришлось изменить даже смысл, так как он не вписывался в рамки выбранной "модели изложения".
Вот, для сравнения, то, как перевел бы это я (это полный текст Бокса):

Сегодня некто озадачил меня объяснить Индиго в пять минут.

Приступим.

Индиго соединяет приложения при помощи структурных контрактов (схем) и поведенческих контрактов (сценаривев обмена сообщениями).

Мы интегрируемся с CLR и COM, и разделываем ваши локальные типы на контракты либо данных либо сервисов. Особенно крутая фишка Индиго в том, что получатель и отправитель не обязаны использовать одинаковые CLR типы (и даже использовать на обоих концах Индиго или CLR или COM).

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

Mы поддерживаем множество транспортов сообщений и поддерживаем безопасность и надежность как на транспортном уровне, так и на уровне SOAP.

Aх да, и еще мы тесно интегрируемся с System.Transactions и очередями сообщений.

Вот. Это заняло у меня меньше пяти минут, а печатаю я намного медленнее, чем говорю.

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

Здравствуйте, Sinclair, Вы писали:

Это кстати, тоже перевод далекий от идеала. Ты пытаешся перевести текст Бокса, а не его посыл. Перевод буква в букву обычно плох. Переводить нужно текст, а не смысл.

Именно по этому качественный перевод — это очень сложная задача. Например, вот этот отрывок:

История программных революций от Microsoft, вкратце: Сначала были Windows API и DLL Hell. Революцией №1 было DDE – помните, как ссылки позволили нам создавать статусные строки, отражающие текущую цену акций Microsoft? Примерно тогда же Microsoft создала ресурс VERSION INFO, исключающий DLL Hell. Но другая группа в Microsoft нашла в DDE фатальный недостаток – его писали не они!

Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом. В OLE появились интерфейсы, исключающие DLL Hell. Помните болезнь с названием «по месту», при которой мы мечтали встроить все свои приложения в один (возможно, очень большой) документ Word? Где-то в то же время Microsoft уверовала в религию С++, возникла MFC решившая все наши проблемы еще раз.

Но OLE не собиралась, сложа руки смотреть на это, поэтому оно заново родилось под именем COM, и мы внезапно поняли, что OLE (или это было DDE?) будет всегда – и даже включает тщательно разработанную систему версий компонентов, исключающую DLL Hell. В это время группа отступников внутри Microsoft обнаружила в MFC фатальный недостаток – его писали не они! Они немедленно исправили этот недочет, создав ATL, который как MFC, но другой, и попытались спрятать все замечательные вещи, которым так упорно старалась обучить нас группа COM. Это заставило группу COM (или это было OLE?) переименоваться в ActiveX и выпустить около тонны новых интерфейсов (включая интерфейсы контроля версий, исключающие DLL Hell), а заодно возможность сделать весь код загружаемым через браузеры, прямо вместе с определяемыми пользователем вирусами (назло этим гадам из ATL!).

Группа операционных систем громким криком, как забытый средний ребенок, потребовала внимания, сказав, что нам следует готовиться к Cairo, некой таинственной хреновине, которую никогда не могли даже толком описать, не то, что выпустить. К их чести, следует сказать, что они не представляли концепции «System File Protection», исключающей DLL Hell. Но тут некая группа в Microsoft нашла фатальный недостаток в Java — её писали не они! Это было исправлено созданием то ли J, то ли Jole, а может, и ActiveJ (если честно, я просто не помню), точно такого же как Java, но другого. Это было круто, но Sun засудило Microsoft по какому-то дряхлому закону. Это была явная попытка задушить право Microsoft выпускать такие же продукты, как у других, но другие.

Помните менеджера по J/Jole/ActiveJ, стучащего по столу туфлей и говорящего, что Microsoft никогда не бросит этот продукт? Глупец! Все это означало только одно – недостаток внимания к группе ActiveX (или это был COM?). Эта невероятно жизнерадостная толпа вернулась с COM+ и MTS наперевес (может, это стоило назвать ActiveX+?). Непонятно почему к MTS не приставили «COM» или «Active» или «X» или «+» – они меня просто потрясли этим! Они также грозились добавить + ко всем модным тогда выражениям. Примерно тогда же кое-кто начал вопить про «Windows DNA» (почему не DINA) и «Windows Washboard», и вопил некоторое время, но все это почило раньше, чем все поняли, что это было.

К этому моменту Microsoft уже несколько лет с нарастающей тревогой наблюдала за интернет. Недавно они пришли к пониманию, что у Интернет есть фатальный недостаток: ну, вы поняли. И это приводит нас к текущему моменту и технологии .NET (произносится как «doughnut (пончик по-нашему)», но по-другому), похожей на Интернет, но с большим количеством пресс- релизов. Главное, что нужно очень четко понимать — .NET исключает DLL Hell.

В .NET входит новый язык, C#, (выясняется, что в Active++ Jspresso был фатальный недостаток, от которого он и помер). .NET включает виртуальную машину, которую будут использовать все языки (видимо, из-за фатальных недостатков в процессорах Интел). .NET включает единую систему защиты (есть все-таки фатальный недостаток в хранении паролей не на серверах Microsoft). Реально проще перечислить вещи, которых .NET не включает. .NET наверняка революционно изменит Windows-программирование... примерно на год.

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

Его переводом занимались мы с Викторыче (Купаевым). Вернее он переводил и редактировал, а я только редактировал (гляда на оригинал). Мы сделали примерно 3 итерации до тех пор пока пришли к выводу, что перевод действительно соответствует смыслу и духу. Причем перевод далек от точности. Вот кстати, оригинал http://www.lohnet.org/~hornlo/mutterings/wdjef/ можете сравнить.