[AI CC-CC2022] Имеет смысл перевод документации с английского на русский ?

  • Автор темы Автор темы alexmaj467
  • Дата начала Дата начала
Статус
Закрыто для дальнейших ответов.
Ну если "Твёрдо захотелось изучить JS", то и делайте, в первую очередь для себя.
Я согласен с вами, что раз мы думаем и обсуждаем идеи на русском, то и документация максимально должна быть тоже на русском языке. Я видел подобный документ, как в спойлере, на японском языке. Так что совсем не однозначно, что надо обязательно барахтаться в английском, а не искать нужную информацию на родном языке.
Идея использовать автоматический переводчик для документации - тухлая.
По крайней мере, JavaScript очень недурно переведен на русский вот тут:
Тут можно много почерпнуть и в плане терминов, и знаний, чего не даст никакой google или yandex переводчик.
 
Идея использовать автоматический переводчик для документации - тухлая.
В том виде как он переводит конечно тухлая, я с этим не спорю.
Конечно с правкой, а в некоторых случаях совершенно другими словами описательную часть сделать, ибо те к (моему) пониманию очень странно звучат.

Потом сам JS мне нужен только в плане Адобовских приложений.
Как то странно изучать сам JS где говорится что var устаревшее глобальное от этого уже отказались в вебе и нужно использовать только let работающую только внутри функции и не видимую на глобальном уровне.
Так что для изучения нужно ещё и это осмыслить, и что вообще из JS используется в 90% для сценариев или плагинов, а что очень редко и не заслуживает первоочередного заучивания.
 
Потом сам JS мне нужен только в плане Адобовских приложений.
Как то странно изучать сам JS где говорится что var устаревшее глобальное от этого уже отказались в вебе и нужно использовать только let работающую только внутри функции и не видимую на глобальном уровне.
Если будете писать не только чистый код скриптов на ECMA-262 для выполнения в документах Иллюстратора, но и интерфейс для своих скриптов в виде Extention Panel, то вам очень понадобится современный JS, с let и всем-всем-всем, документации по которому на русском полно.
 
  • Спасибо
Реакции: alexmaj467
Можно я тут у знающих спрошу.

На странице Art item bounds

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

Просто я данный скрин перерисовываю своей фигурой, и position равен geometricBounds.
 
Не имеет смысла тратить время на перевод документации на русский язык. Если хотите сами научиться, то сделайте это любым способом. Если я захочу научиться, я буду читать оригинал.
 
  • Спасибо
Реакции: NatalieRedFox_333
Не имеет смысла тратить время на перевод документации на русский язык. Если хотите сами научиться, то сделайте это любым способом. Если я захочу научиться, я буду читать оригинал.
как горох об стенку.... :D
 
Мне вот интересно.... как вы будете переводить ну допустим слово Appearance на русский...? 'otbline'
 
Каким боком position включает в себя размеры ручек манипуляторов.
Или это так образно показано, что начало координат элемента рисунка это левый верхний угол, даже если он неправильно показан.
position это верхний левый угол controlBounds
Просто я данный скрин перерисовываю своей фигурой, и position равен geometricBounds.
значит у Вас верхний левй угол controlBounds равен таковому в geometricBounds
Appearance на русский...
Сейчас новички предпочитают пользоваться локализованными версиями, мы уже динозавры 'skelet'
Appearance.PNG
 
  • Спасибо
Реакции: Nikle
Сейчас новички предпочитают пользоваться локализованными версиями, мы уже динозавры 'skelet'
Большинство самых ценных источников информации как раз на международном. Да и заказчики в основном самые лучшие те, которые по-русски не говорят (не все, опять же, но статистически лучше).

Поэтому те, кому нравятся локализации с корявыми хоткеями и переведенные на "родной" мануалы, могут и дальше сидеть в этом удобненьком болоте и не выходить на международный рынок, хоспаде. Так же всем будет лучше )
 
Последнее редактирование:
  • Спасибо
Реакции: Nikle и Chiga
position это верхний левый угол controlBounds
Да не бывает такого. От слова совсем.
У controlBounds нет координат [x,y], или я ошибаюсь ?

The width of the page item, calculated from the geometric bounds.
The height of the page item, calculated from the geometric bounds.
как вы будете переводить ну допустим слово Appearance на русский...?
Если это касается JS в виде команды, объекта, свойства или спец. обозначения, то ни как, если это касается интерфейса программы, то писать текущий вариант, а в скобках оригинал.
Поэтому те, кому нравятся локализации с корявыми хоткеями и переведенные на "родной" мануалы, могут и дальше сидеть в этом удобненьком болоте и не выходить на международный рынок, хоспаде. Так же всем будет лучше )
Чтоб они были не корявыми их нужно переводить в согласии с теми кто будет пользоваться.
А не лицезреть то что принял Adobe для официальной локализации Русского.

Вас на международном рынке вагон и маленькая тележка. Не перебить Китай и Индию.


перевод документации на русский язык
Кто вам это вбил в голову ?

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

А вот эти Адобовские документы ни тем ни другим не являются, и вполне могут иметь перевод. Что они и имеют.
C:\Program Files (x86)\Adobe\Adobe ExtendScript Toolkit CC\SDK
Английский
Немецкий
Французский
Японский
 
Последнее редактирование:
Чтоб они были не корявыми их нужно переводить в согласии с теми кто будет пользоваться.
Я о хоткеях, завязанных на меню, через буквы. Которые с зажатым Alt жмакаются.
 
У controlBounds нет координат [x,y], или я ошибаюсь ?
запустите
JavaScript:
controlBounds = app.activeDocument.pageItems[0].controlBounds;
geometricBounds = app.activeDocument.pageItems[0].geometricBounds;

alert ("controlBounds" +  "\n" +
"left x " + controlBounds[0] + "\n" +
"top y " + controlBounds[1] + "\n" +
"right x " + controlBounds[2] + "\n" +
"bottom y " + controlBounds[3] + "\n\n" +
"geometricBounds" +  "\n" +
"left x " + geometricBounds[0] + "\n" +
"top y " + geometricBounds[1] + "\n" +
"bottom x " + geometricBounds[2] + "\n" +
"bottom y " + geometricBounds[3] + "\n"
);
 
Это вы о получении координат уже существующих.

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

А что сделает скрипт с точно указанными X,Y но с ошибочными точками манипуляторов ?
 
Это вы о получении координат уже существующих.

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

А что сделает скрипт с точно указанными X,Y но с ошибочными точками манипуляторов ?
Для рисования примитивов существуют свои методы, для работы с точками свои.
Причем тут Bounds-ы?

PathItems.ellipse()
app.activeDocument.pathItems.ellipse([top][, left][, width][, height][, reversed][, inscribed])
 
Оригинал, делали ХЗ знает когда и на каком аутсорсе не известно.

То что там примеры корявые это ладно.
В примерах скрипты начинаются с
var myDoc = app.activeDocument;

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


А вот это как должно работать в современном CC 2017 ?У меня ошибка на 6 строке.

Combining path point types​

The following script sample creates a path with three points:

var myDoc = app.activeDocument;
var myLine = myDoc.pathItems.add();
myLine.stroked = true;
myLine.setEntirePath( [[220, 475], [375, 300]]);

// Append another point to the line
var newPoint = myDoc.myLine.pathPoints.add();
newPoint.anchor = [220, 300];
newPoint.leftDirection = newPoint.anchor;
newPoint.rightDirection = newPoint.anchor;
newPoint.pointType = PointType.CORNER;

Но если из 6 строки удалить myDoc. прекрасно работает.
Почему так ? старые версии как на это будут отзываться ?
 
в любой версии ошибка будет, вы бы все-таки чуток хоть с языком разобрались сначала, тогда не будет таких вопросов возникать. очевидно же, что объявленная выше переменная myLine не является свойством документа
 
вы бы все-таки чуток хоть с языком разобрались сначала
Если бы те кто создавал Оригинал документации Adobe это делал нормально.
А ребята которые его перепечатывали в Веб. ai-scripting.docsforadobe.dev ----- Combining path point types не повторяли бы как попугаи ошибки оригинала, у меня бы и не было вопросов.

После перевода начну пробовать разбираться.

Пока я разбираюсь в кривости Оригинала, который уже перевёл и почти оформил, осталось поправить примеры, сделать в PDF закладки и всё. И переходить ко второму, хотя он должен был быть первым Введение
 
прежде чем бегать, нужно научиться ходить 'rake'
 
показали бы для примера что у вас там получается с переводами, я нисколько не сомневаюсь что это будет лучшей гайд по люстратовкому скриптингу... 'otbline'
 
Статус
Закрыто для дальнейших ответов.