Русский
Русский
English
Статистика
Реклама

Переводы

Перевод 5 типичных ошибок при создании React компонентов (с хуками) в 2020 году

01.07.2020 18:14:54 | Автор: admin
image

Всем привет! Из этой статьи вы узнаете о самых распространенных ошибках при создании React компонентов, а также о том, почему они считаются ошибками, как их избежать или исправить.


Оригинальный материал был написан немецким разработчиком Лоренцом Вайсом для личного блога, а позже собрал много позитивных отзывов на dev.to. Переведено командой Quarkly специально для комьюнити на Хабре.



React


React достаточно давно существует в мире веб-разработки, и его позиции как инструмента для гибкой разработки стремительно укрепились за последние годы. А после анонса и релиза нового хука api/concept создание React-компонентов стало ещё проще.


Несмотря на то, что команда, разработавшая React, и огромное сообщество, которое кодит на этом языке, попытались дать внушительное объяснение концепции React'а, я всё же нашел кое-какие недостатки и типичные ошибки во время работы с ним.


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


Дисклеймер


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


Что касается React-кода, как и по любому другому программному фреймворку или библиотеке, по нему существует миллион различных мнений. Всё, что вы видите здесь, мое личное мнение, а не истина в последней инстанции. Если у вас другое мнение, я с удовольствием выслушаю его.


1. Использование useState, когда нет необходимости в повторном рендере


Одна из основных концепций Reactа это работа с состоянием. Вы можете контролировать весь поток данных и рендеринг через состояние. Каждый раз, когда дерево рендерится снова, оно, скорее всего, привязывается к изменению состояния.


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


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


Так делать нехорошо:


function ClickButton(props) {  const [count, setCount] = useState(0);  const onClickCount = () => {    setCount((c) => c + 1);  };  const onClickRequest = () => {    apiCall(count);  };  return (    <div>      <button onClick={onClickCount}>Counter</button>      <button onClick={onClickRequest}>Submit</button>    </div>  );}

Проблема:


На первый взгляд, вы можете спросить: А в чем, собственно, проблема? Разве не для этого было создано это состояние? И будете правы: всё отлично сработает, и проблемы вряд ли возникнут. Однако в Reactе каждое изменение состояния влияет на компонент и, скорее всего, на его дочерние компоненты, то есть заставляет их выполнить повторный рендеринг.


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


Решение:


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


function ClickButton(props) {  const count = useRef(0);  const onClickCount = () => {    count.current++;  };  const onClickRequest = () => {    apiCall(count.current);  };  return (    <div>      <button onClick={onClickCount}>Counter</button>      <button onClick={onClickRequest}>Submit</button>    </div>  );}

2. Использование router.push вместо ссылки


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


Допустим, вы создаете кнопку, и пользователь при нажатии на неё должен быть перенаправлен на другую страницу. Так как это SPA, то это действие будет клиентским механизмом маршрутизации. Так что вам понадобится какая-нибудь библиотека. Самая популярная из них в React это react-router, и в следующем примере будет использована именно эта библиотека.


Значит ли это, что добавление слушателя события по клику правильно перенаправит пользователя на нужную страницу?


Так делать нехорошо:


function ClickButton(props) {  const history = useHistory();  const onClick = () => {    history.push('/next-page');  };  return <button onClick={onClick}>Go to next page</button>;}

Проблема:


Хотя для большинства пользователей это вполне рабочее решение, есть одна большая проблема: она появляется, когда дело касается реализации веб-доступности. Кнопка вообще не будет помечена как ссылка на другую страницу, а это значит, что скринридер не сможет ее идентифицировать. Сможете ли вы открыть ее в новой вкладке или окне? Скорее всего, тоже нет.


Решение:


Ссылки на другие страницы при любом взаимодействии с пользователем должны, насколько это возможно, обрабатываться компонентом <Link> или обычным тегом <a>.


function ClickButton(props) {  return (    <Link to="/next-page">      <span>Go to next page</span>    </Link>  );}

Бонусы: это также делает код более читабельным и лаконичным!


3. Обработка действий с помощью useEffect


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


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


Так делать нехорошо:


function DataList({ onSuccess }) {  const [loading, setLoading] = useState(false);  const [error, setError] = useState(null);  const [data, setData] = useState(null);  const fetchData = useCallback(() => {    setLoading(true);    callApi()      .then((res) => setData(res))      .catch((err) => setError(err))      .finally(() => setLoading(false));  }, []);  useEffect(() => {    fetchData();  }, [fetchData]);  useEffect(() => {    if (!loading && !error && data) {      onSuccess();    }  }, [loading, error, data, onSuccess]);  return <div>Data: {data}</div>;}

Проблема:


Есть два хука useEffect: первый обрабатывает запрос данных к API во время первоначального рендеринга, а второй вызывает функцию onSuccess. То есть, если в состоянии нет загрузки или ошибки, но есть данные, то этот вызов будет успешным. Логично звучит, да?


Конечно, это почти всегда будет срабатывать с первым вызовом. Но вы также потеряете прямую связь между действием и вызываемой функцией. И нет 100% гарантии, что это произойдет только в том случае, если действие fetch будет успешным. А это именно то, что мы, разработчики, так сильно не любим.


Решение:


Самое простое решение установить функцию onSuccess туда, где вызов будет успешным.


function DataList({ onSuccess }) {  const [loading, setLoading] = useState(false);  const [error, setError] = useState(null);  const [data, setData] = useState(null);  const fetchData = useCallback(() => {    setLoading(true);    callApi()      .then((fetchedData) => {        setData(fetchedData);        onSuccess();      })      .catch((err) => setError(err))      .finally(() => setLoading(false));  }, [onSuccess]);  useEffect(() => {    fetchData();  }, [fetchData]);  return <div>{data}</div>;}

Теперь с первого взгляда понятно, что onSuccess вызывается только в случае успешного вызова API.


4. Компоненты с единой ответственностью


Составлять компоненты может быть довольно трудной задачей. Когда делить один компонент на несколько более мелких компонентов? Как структурировать дерево компонентов? Этими вопросами задаются все, кто каждый день работает с компонентным фреймворком. И самой распространенной ошибкой при создании компонентов является объединение двух случаев использования в один компонент.


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


Так делать нехорошо:


function Header(props) {  return (    <header>      <HeaderInner menuItems={menuItems} />    </header>  );}function HeaderInner({ menuItems }) {  return isMobile() ? <BurgerButton menuItems={menuItems} /> : <Tabs tabData={menuItems} />;}

Проблема:


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


Решение:


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


function Header(props) {  return (    <header>{isMobile() ? <BurgerButton menuItems={menuItems} /> : <Tabs tabData={menuItems} />}</header>  );}

5. useEffect с единой ответственностью


Помните времена, когда у нас были только методы componentWillReceiveProps или componentDidUpdate для подключения к процессу рендеринга React-компонента? В голову сразу приходят мрачные воспоминания, а ещё осознаешь всю прелесть использования хука useEffect и особенно то, что его можно использовать без ограничений.


Но иногда, когда используешь useEffect для некоторых вещей, мрачные воспоминания приходят вновь. Представьте, например, что у вас есть компонент, который извлекает некоторые данные из бэкэнда и отображает путь (breadcrumbs) в зависимости от текущего местоположения (снова используется react-router для получения текущего местоположения).


Так делать нехорошо:


function Example(props) {  const location = useLocation();  const fetchData = useCallback(() => {    /*  Calling the api */  }, []);  const updateBreadcrumbs = useCallback(() => {    /* Updating the breadcrumbs*/  }, []);  useEffect(() => {    fetchData();    updateBreadcrumbs();  }, [location.pathname, fetchData, updateBreadcrumbs]);  return (    <div>      <BreadCrumbs />    </div>  );}

Проблема:


Существует два варианта использования хука: сбор данных (data-fetching) и отображение пути (displaying breadcrumbs). Оба обновляются с помощью хука useEffect. Этот самый хук useEffect сработает, когда fetchData и updateBreadcrumbs функционируют или меняется location. Основная проблема в том, что теперь мы также вызываем функцию fetchData при изменении location. Это может стать побочным эффектом, о котором мы и не подумали.


Решение:


Если разделить эффект, станет понятно, что функции используются только для одного эффекта, при этом неожиданные побочные эффекты исчезают.


function Example(props) {  const location = useLocation();  const updateBreadcrumbs = useCallback(() => {    /* Updating the breadcrumbs*/  }, []);  useEffect(() => {    updateBreadcrumbs();  }, [location.pathname, updateBreadcrumbs]);  const fetchData = useCallback(() => {    /*  Calling the api */  }, []);  useEffect(() => {    fetchData();  }, [fetchData]);  return (    <div>      <BreadCrumbs />    </div>  );}

Бонусы: случаи использования теперь также логически распределены внутри компонента.


Заключение


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


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

Подробнее..

Перевод Путешествие не лекарство для ума

17.09.2020 16:18:03 | Автор: admin


Решила перевести эту статью после прочтения "Ни туда, ни обратно" и недавнего цикла статей про работу в Германии и возвращение в Россию.


В этот самый момент вы можете быть здесь:



Или здесь:



Или здесь:



Но скорее всего, вы здесь:



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



Или Париже, где можно наслаждаться французской едой, вином, гулять по освещенным улицам, о которых вы столько слышали:



Или Перу, где вы, наконец, сможете отправиться в Мачу-Пикчу и увидеть архитектурное чудо, которое есть в профилях необъяснимо большого процента ваших друзей в Facebook:



Или Аляска, где вы сможете стать свидетелем северного сияния во всем его великолепии:



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



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



Это "Коробка ежедневного опыта", пространство которое мы занимаем в любой день недели/месяца/года, проживая жизнь. Это то, что мы считаем "нормальным" в контексте поседневного опыта, действия по-умолчанию нашей операционной системы. Границы коробки определяют ситуацию текущего дня, так что, когда мы устремляемся в мечтах в восхитительное будущее, мы смотрим за его границы, чтобы испытать удивление, изумление и вдохновение. С нашей коробкой все в порядке и она подходит для жизни, но мир снаружи ее границ то, где находится наша надежда.



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



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



Вы волнуетесь, когда покупаете машину и уезжаете на ней с парковки. Это то, ради чего вы так много работали! Теперь, когда у вас есть эта машина, структура вашей коробки коренным образом изменилась, и ваша коробка, которую вы знаете, больше не будет прежней!
Вы начинаете ездить на ней на работу и обратно, на встречи с друзьями и обратно.
Но вот в чем дело.
Хотя вы все еще счастливы получить новую машину, вы замечаете, что ваше волнение по поводу ее владения не так сильно, как в тот день, когда вы ее приобрели.



Проходят месяцы, и все меньше людей комментирует новизну вашей машины.



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



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



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



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



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



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



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



В такие времена вы мечтаете вырваться из Коробки ежедневного опыта.
Вы понимаете, что отпуск допамин для культурного опыта, но ограниченные временные рамки не позволяют понять все разнообразие жизни за рубежом.
Однажда вы решаете, что ответ не в той коробке, где вы живете сейчас. Есть место, которое вы посетили и оно вам понравилось.
Но на этот раз вы будете отсутствовать действительно долго. То, что вы ищете должно быть там. Не здесь.



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



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



Вы видите вещи, которые никогда раньше не видели и это фантастика:



Вау. Если кто-нибудь спросит вас "Как жизнь?", вы ответите: "Восхитительно!". Но помните, оставаться на месте какое-то время, тусоваться с друзьями и осматривать достопримечательности не лучший способ достижения финансовой стабильности.
Кроме того, днем ваши друзья работают, и единственное развлечение для вас бродить в полдень в одиночестве. Так что да, пора найти работу.



Суть работы примерно такая же, которая была у вас ранее не идеально, но поддерживает мечту о путешествиях и возможность вырваться из старой коробки, так что все в порядке.
Теперь у вас есть двигатель, производящий ресурсы, который способствует пребыванию в вашем новом доме, и вы можете продолжать получать отличные впечатления от этой страны с течением времени.
Кстати о времени. Не важно где вы находитесь, оно движется в одном направлении. Вперед. Это линейное движение времени естественный способ понять, что для нас важно.
Только время может показать, движет ли определенное стремление мимолетная новизна или оно мотивируется сильным чувством непреходящей цели.
И когда дело касается путешествий, тест времени показывает, что стремление к новизне проходит очень и очень быстро.
Дни в новой стране превращаются в недели, события начинают происходить с привычной регулярностью.
Еда, которой вы наслаждались по прибытии, становится ежедневным обедом:



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



Достопримечательности (чтобы их увидеть вы когда-то платили) становятся просто зданиями по пути на работу.



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



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



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



О нет, чертова коробка снова! Как же так? Возможно пора найти новое место? Еще дальше, возможно другой континент.
С тех пор, как вернулась Коробка ежедневного опыта, вернулось и желание вырваться из нее.
Но вот в чем дело. Даже если сломать коробку, это не сработает.
Вы можете изменять свою внешнюю среду как хотите, но вы продолжите путешествовать с той коробкой, которая всегда будет сопровождать вас.
Эта коробка ваш разум.



Когда мы одержимы путешествиями, мы сосредоточены на изменении и пересмотре нашего внешнего места, игнорируя при этом одну постоянную, с которой все путешествуем: наш разум.
Если ваш ум не спокоен, то та же тревога и беспокойство, которые вы чувствуете сегодня, неизбежно проявятся во время вашего путешествия. Этот момент может быть отложен из-за нового опыта, но независимо от того, где вы находитесь, беспокойный ум всегда в конце концов обнаружит себя.





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



Мы склонны сильно переоценивать удовольствие, которое приносит новый опыт, и недооценивать способность находить смысл в текущем. Хотя путешествие это фантастический способ познакомиться с незнакомыми культурами и изменить образ жизни, это не лекарство от недовольства ума.
То, кем мы являемся внутри коробки, имеет гораздо большее значение, чем сама коробка. Вместо того чтобы искать смысл в путешествиях, мы должны заглянуть внутрь себя и принять единственное, что есть сейчас. Единственное, что реально существует сегодня.
Коробка ежедневного опыта.
Вместо того чтобы рассматривать этот ящик как проблему, от которой нужно сбежать, мы должны понять, что это единственное, за что мы действительно можем держаться.
Когда вы рассматриваете жизнь как непрерывный цикл в этой коробке, можно легко принять ее компоненты как должное и рассматривать все как банальное размытие знакомых событий. Однако, когда вы потратите время на то, чтобы осмотреть коробку с осознанным вниманием к ее содержимому, вы обнаружите истинное изумление, которое живет внутри. И лучший инструмент, который можно использовать для этих великих открытий, это практика благодарности.



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



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



Благодарность за наше существование и его отношение к другим позволяет придать смысл и цель в нашем исследовании жизни. Это отправная точка для бесконечного списка замечательных вещей, которые у нас есть, и нам не нужно ни на йоту менять свое физическое местоположение, чтобы увидеть, как этот список растет.
Если благодарность это инструмент, который мы используем, чтобы подчеркнуть врожденную красоту, существующую в наших коробках, тогда такие практики, как медитация осознанности, позволяют этим мыслям действительно стать частью нашего повседневного мировоззрения. Одна из трудностей рутины, встроенной в наш повседневный опыт, заключается в том, что она имеет тенденцию срастаться в одну гигантскую однородную каплю, которую мы называем жизнью. И эта капля может со временем затвердеть, создав непреодолимый барьер, который мешает нам усвоить полезные советы и открытия.
Медитация помогает смягчить текстуру этой капли, удаляя наши ожесточенные эго и невротические мысли из внутреннего ядра нашего сознания. Что нам остается, так это ясность и открытость, чтобы увидеть Коробку ежедневного опыта такой, какая она есть на самом деле: отражение жизни, которое можно сделать плавным при должном внимании и заботе.



Хотя ясность переживания прямой путь к успокоению ума, есть еще одно прекрасное качество нашего сознания, которое часто упускается из виду.
Умение увлекаться чужим сознанием.
Один из источников постоянного удивления и приключений это книги. Вместо того, чтобы искать вдохновляющие впечатления в далеких местах, эти удивительные вещи доступны нам в любое время.
Мне особенно нравится читать научно-популярные произведения, но любая хорошая литература очень увлекательна. Помните, что всякий раз, когда вы берете хорошую книгу для чтения, вы совершаете большое путешествие в сознание автора. Для меня удивительно, то, что как обычный человек я имею непосредственный доступ к величайшим умам прошлого и настоящего и могу поглотить годы и годы их кропотливых исследований всего за несколько дней или недель.
Я могу представить себя известным философом, размышляющим о тайне сознания, или я могу занять место в сознании историка, подробно описывающего монгольское завоевание при Чингисхане. Я могу узнать все, что захочу, и это приключение, которое всегда можно довести до того места, где я нахожусь сейчас.



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



Хотя путешествия действительно расширяют горизонты наших знаний о мире, это не тот ответ, который мы ищем во времена беспокойства. Чтобы укрепить здоровье ума, место для этого то, в котором мы сейчас находимся.
Оно не зависит от местоположения и всегда будет таковым.
Ключ в том, чтобы не отказываться от "Коробки ежедневного опыта" и искать новую, а в том, чтобы тепло принять ту, которая у нас есть сейчас, с ее радостями, недостатками и всем остальным.



Примечание: этот пост моя адаптация потрясающего письма Сенеки Луцилию о путешествиях. Я настоятельно рекомендую вам прочитать его наряду со всеми другими замечательными письмами Сенеки.


Подробнее..

Гибкая локализация как применить agile к проекту по переводу

24.07.2020 10:04:54 | Автор: admin


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


Как гибкая локализации помогает улучшить качество продукта и оптимизировать бизнес-процессы? Рассказываем о преимуществах применения agile на проектах по локализации продукта.


Что такое гибкая локализация


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


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


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


Как работает гибкая локализация?


При традиционной каскадной разработке продуктов (waterfall model) локализация происходит только после завершения процесса разработки. При этом релиз продукта зависит от перевода, что обычно приводит к отставанию от графика и сорванным срокам. В каскадной модели большая часть работы по переводу выполняется вручную. Это неэффективно с точки зрения использования ресурсов и приводит к большому количеству ошибок.


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


Главное преимущество использования LMS или TMS заключается в том, что с их помощью можно автоматически извлечь строки текста, которые необходимо перевести. Больше никаких ручных операций по извлечению и преобразованию строк!


Пошаговое описание процесса гибкой локализации выглядит примерно так:


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


1. Меньше времени для вывода продукта на рынок


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


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



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


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


2. Меньше затрат


Когда локализация выполняется по agile методологии, специалисты переводят только новые или недавно обновленные строки. Не нужно снова переводить или пересматривать текст, который не менялся и уже был переведен для предыдущей версии. Такие текстовые материалы просто можно использовать повторно. Это приводит к снижению затрат на локализацию и перевод.


3. Легче находить ошибки


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


4. Меньше ручной работы


Гибкая методология позволяет управлять сложными процессами, сводя объем ручных задач к минимуму. Использование специализированных программных средств автоматизации делает процесс локализации еще более легким. Не нужно извлекать переведенные строки вручную передача между репозиториями разработки и системами управления локализацией происходит автоматически при помощи API (application programming interface) или CLI (command-line interface).


5. Более быстрое тестирование локализации


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


А есть ли трудности?


Конечно, ни один подход не идеален на 100%. Гибкая методология не исключение.


1. Контекст определяет всё


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


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


Отличный пример того, как нам удалось справиться с проблемами, связанными с контекстом, это локализация приложения Clue. Команда локализации смогла вовремя получить контекст, так как группа разработчиков Clue предоставила скриншоты приложения непосредственно в системе управления переводом. Это простое в реализации и эффективное решение.


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


2. Командная работа


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


3. Не так быстро, как хотелось бы


Да, гибкая локализация работает быстрее, чем каскадная модель. Однако не стоит переоценивать ее возможности.


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


Как подготовиться к гибкой локализации?


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


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


Нужна помощь с локализацией / переводом? Мы в Alconost всегда рады помочь!


О нас


Alconost профессионально занимается локализацией игр, приложений и сайтов на более 70 языков. Лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджмент проектов 24/7, любые форматы строковых ресурсов.
Мы также делаем видеоролики.


Подробнее

Подробнее..

Перевод Как делать гипер-казуальные игры, популярные во всём мире

16.10.2020 10:22:46 | Автор: admin
Изображение создано компанией AlconostИзображение создано компанией Alconost

Гипер-казуальные игры стали трендом на рынке мобильных приложений. В 2019 году число активных пользователей в день в топовых гипер-казуалках составило 94 тысяч. И это самый высокий показатель среди других мобильных игр. В 2020 году гипер-казуальные игры, судя по всему, не теряют популярность: только в первом квартале число установок по всему миру выросло на 103%. А ещё игроки стали проводить в игре на 72% больше времени, чем раньше.

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

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

Краткое введение в мир гипер-казуальных игр

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

Так что именно отличает гипер-казуальные игры и делает их такими запоминающимися?

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

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

Скриншоты из игры Flappy Bird в App StoreСкриншоты из игры Flappy Bird в App Store

В гипер-казуалках есть и другие игровые механики:

  • тайминговая механика (касание экрана в определенное время);

  • механика укладки блоков (сбор объектов в башню или стену);

  • механика ловкости (делается упор на скорость реакции);

  • механика восхождения/падения (управление движением объекта);

  • механика уклонения (обход препятствий: Flappy Bird отличный пример!).

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

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

Не забудьте о выборе правильной стратегии монетизации. Тут есть несколько вариантов:

  • реклама в приложении (реклама, которая крутится в игре между разными уровнями);

  • покупки в приложении (игроки могут покупать дополнительные инструменты или другие бонусы);

  • оплата премиум-модели (самое большое её преимущество для пользователя полное отсутствие рекламы);

  • кросс-промо или перекрестное продвижение (реклама одной игры появляется в другой игре).

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

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

ASO (Оптимизация мобильных приложений)

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

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

1. Локализация описания приложения

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

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

В общем, локализация приложения действительно важна: она помогает привлечь не только англоязычных пользователей, но и значительно расширяет охват аудитории. Например, исследование, проведенное в 2017 году, показало, что почти 50% всех загрузок приложений в App Store выполняют игроки, которые не говорят по-английски. А теперь представьте, какую часть аудитории вы можете упустить, если решите не локализовывать свой продукт на другие языки.

2. Ключевые слова

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

Apple и Google по-разному подходят к ключевым словам. Apple ограничивает ключевые слова 100 символами, а Google позволяет ввести неограниченное количество ключевиков, если вам это нужно. Но будьте осторожными: если ключей слишком много, рейтинг игры может наоборот значительно снизиться.

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

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

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

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

  • Быстрые переводы: 68% всех запросов готовы в течение 2-х часов, что особенно актуально для срочных задач.

  • Доступны более 70 языков для перевода, поэтому Nitro отлично подходит для локализации продукта для самых разных и даже нишевых аудиторий.

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

3. Локализация скриншотов

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

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

Отличный пример локализации скриншотов игра Magic Jigsaw Puzzles от ZIMAD. Чтобы понравиться японской аудитории, компания специально локализовала скриншоты в сторе под этот регион. В результате количество конверсий выросло на 36%.

Скриншоты игры Magic Jigsaw Puzzles в App StoreСкриншоты игры Magic Jigsaw Puzzles в App Store

Локализация гипер-казуальных игр: полезные советы

Кроме ASO есть и другие лайфхаки, которые помогут с локализацией. Делимся некоторыми из них.

1. Планируйте локализацию заранее

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

  • выбор целевой аудитории и соответствующих языков;

  • создание игрового интерфейса, адаптированного под все языки;

  • выбор сервиса для локализации.

Подробнее о каждом пункте.

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

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

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

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

2. Узнайте как можно больше о своей аудитории

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

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

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

Гипер-казуальные игры в Китае: краткий обзор

Изображение создано компанией AlconostИзображение создано компанией Alconost

На азиатском рынке игр MMO-RPG (массовая многопользовательская онлайн-игра), MOBA (многопользовательская онлайновая боевая арена) и RTS (стратегия в реальном времени) давно стали популярными жанрами. Но кажется, игроки в Китае уже успели полюбить и гипер-казуальные игры. Потому что около 50% всех загрузок игр в Китае это гипер-казуалки. И размер китайского рынка открывает множество перспектив для разработчиков.

Итак, на какие особенности китайского рынка обратить внимание?

  • Локализация ключ к успеху. Если вы уважаете местную культуру и демонстрируете это в игре, игрокам это точно понравится! К примеру, можно ввести новые специальные символы для китайских праздников (скажем, для Китайского Нового года).

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

  • Длинные сессии: по сравнению с западной аудиторией, где игровая сессия длится около 3-х минут, китайские игроки проводят в игре до 5-и минут.

  • Более высокая терпимость к внутриигровой рекламе. Китайская аудитория более терпима к рекламе, и это действительно многообещающая возможность для монетизации игр.

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

3. Создавайте специальные ивенты и промоакции

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

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


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

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

4. Вовлекайте местное сообщество игроков

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

Поэтому советуем комбинировать профессиональный перевод с переводом силами локального сообщества геймеров. Это помогает получить более качественный и быстрый результат.

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

Вместо итогов

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

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

О нас

Alconost профессионально занимаетсялокализацией приложений, игр и сайтовна более 70 языков. Лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджмент проектов 24/7, любые форматы строковых ресурсов. Мы также делаемвидеоролики.

Подробнее..

Юноше, обдумывающему электронику

10.12.2020 12:12:32 | Автор: admin
Люди, начинающие интересоваться электроникой, рано или поздно сталкиваются с проблемой получения ответов на вопросы разной степени наивности. И здесь новообращённый адепт паяльника и вольтметра упирается в проблему технической информации по указанному направлению. Хорошо, если под боком есть терпеливый и грамотный наставник. Но такая удача выпадает не всем. Прямо скажем, мало кому так везёт. Сетевые форумы? Там новичков не жалуют и часто грубо оскорбляют репликами RTFM и почитай, наконец, учебник. Короче, рано или поздно любой человек, влезающий в сложную и хорошо разработанную тему, сталкивается с проблемой поиска достойных печатных источников знаний. Печатные источники имеют массу достоинств, и самые основные из них терпеливость и вежливость. Книга не скажет: Ну что за тупой читатель, или Чем ты занимался в школе?. Книгу можно неторопливо и вдумчиво читать, снова и снова проходя сложный материал, не рискуя исчерпать терпение наставника.

Итак, книга. Но с книгами, как и с людьми, есть проблемы. И проблемы, собственно, те же: точность, корректность, полнота, качество подачи материала. Но перечисленными параметрами сходство книг с людьми не исчерпывается. На их примере очевидной представляется печальная судьба цивилизации. Всё хужает. Этот горький катаклизм виден повсеместно в мельчайших деталях бытия. Стареют девки, выцветает небо, молодёжь не слушает старших и хочет только танцевать, пить вино и писать на Хабр. И у всех, что характерно, лапки! Так вот, сынок. Ты представляешь, у жучков всё то же самое! Ну, то есть у книг. В последнее десятилетие окончательно оформилась неприятная тенденция в современном техническом книгоиздательстве. Полки книжных магазинов забиты руководствами пользователей и устаревшими справочниками, интересных книг по сложным техническим направлениям и в частности по электронике на русском практически не выходит, а те, что печатаются, переведены из рук вон плохо. Читать без слёз и горького сожаления о бездарно потраченных деньгах невозможно. И Хабр слишком часто предлагает под видом переводов ту же низкопробную дрянь, но хоть денег не просит.

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

(*) Хомский это не про электронику, но вы уловили мысль.

На мой взгляд, этот печальный итог (промежуточный, ведь похороны же не завтра?) является закономерным следствием развития средств автоматического перевода до такого состояния, которое делает работу без их использования нерентабельной для издательства: слишком сложно, слишком медленно и слишком дорого. <личный опыт> Узнал, что некая фирма собирается переводить объёмную книгу технической направленности объёмом свыше 500 страниц. И сколько по вашему дают на такую работу времени и денег? Четыре месяца и менее 100 тысяч рублей. Сто страниц в месяц мне лично слабо: для основного места работы мало предлагают, а для подработки много хотят. Правда, понятие страница здесь употребляется некорректно. Правильнее было бы говорить о числе знаков, потому что наполнение страницы сильно зависит от характера вёрстки. Но мы сейчас не об этом. </личный опыт> В выходных данных современных книг перестали писать фамилию переводчика, а о фразе под технической редакцией такого-то не упомнят даже старожилы.

Следует заметить, что технические писатели и так нечасто бывают мастерами слова, а уж после живительного воздействия компьютера воспринимать их произведения без отвращения становится решительно невозможно. Здесь важно понимать, что машинный перевод не означает, что произведение скармливается программе, которая формирует на выходе готовый текст и сама отправляет его в издательство. Современные CAT-системы больше похожи на интерактивный словарь, который вы пополняете готовыми словосочетаниями, фразами и предложениями. Чем длиннее произведение, тем больше вероятность, что новое предложение уже есть в памяти, и тем увереннее можно утверждать, что оно будет переведено в точности так же, как и предыдущее. Но то, что хорошо для распознавания букв, не обязательно подойдёт для осмысленного текста. Из одинаковых слов составляются одинаковые фразы, образующие в итоге серое и скучное занудство. А если исходный текст уже был зануден донельзя? А как он может быть иным при объёме в 500 страниц с гаком? Исключения бывают, конечно, но они редки и в большинстве случаев хорошо известны.

Здесь нужно особо подчеркнуть вторую тенденцию современного книгоиздательства. Книги становятся всё толще. Особенно наглядно это видно по нескольким последовательным изданиям какого-либо популярного произведения. Раз от раза оно прибавляет сотню-другую страниц и за три-четыре редакции превращается из вполне удобной для восприятия книги страниц на триста в совершенно неподъёмный тысячестраничный кирпич, перспектива знакомства с которым приводит в смятение. На мой взгляд, максимальный размер технической книги 250...350 страниц, и для превышения этого значения должны быть очень веские причины.

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

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

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

Контент! Как много в этом слове для уха нашего слилось. Таки всё началось с терпеливого и грамотного наставника. Переходим к грамоте. Как можно оценить качество содержимого? Для неспециалиста есть только один путь рекомендация. Это может быть совет авторитетного человека или принцип вече, когда решение принимается по громкости гвалта сторонников того или иного источника. С авторитетным человеком может случиться заминка. Цитата:
Обыденное сознание это сознание человека, компетентного в своей узкой области повседневной (профессиональной) деятельности, проявляющееся за пределами этой повседневности. Другими словами, именно в момент выхода за пределы повседневного процесса деятельности, за пределы своей обыденности, обыденное сознание начинает проявляться как таковое. Вне сферы своей компетентности обыденное сознание не имеет никакого иного познавательного инструмента кроме собственного повседневного. В том числе оно не может отрефлексировать сам выход в чужую область
(www.warandpeace.ru/ru/reports/view/152266). Пример академик Фоменко (математик-тополог) и его альтернативная датировка истории (обыденность сознания не позволяет ему оценить степень своей некомпетентности в истории). Остаётся только вече. Вообще-то, не самый плохой вариант. Если сторонников какой-то фигни много, то, даже занимаясь фигнёй, будешь частью мэйнстрима. Тут, правда, может выйти как с современной книжной вёрсткой: оно, конечно, мэйнстрим, но, ведь, и препохабно же!

Проблему выбора некорректно сводить исключительно к рациональным соображениям. Частенько какое-нибудь красно-жёлтое оформление и свежий маркетинговый ход, вроде надписей без цензуры или бестселлер, в беспорядке раскиданных на самых видных местах, могут самым неочевидным образом сказаться на решении о покупке. Особенно выигрышно они будут смотреться на обложке произведения какого-нибудь Генриха Бёлля или Лермонтова, но и Кернигана с Ричи украсят по самое нехочу.

Давайте уже порекомендуем отрокам, обдумывающим всё, до чего руки дотянулись, какую-нибудь хорошую книгу по электронике. И в самом деле! Самым лучшим учебником на данный момент, как и 30 лет назад, является Искусство схемотехники за авторством Хоровица и Хилла. (Тем гражданам, которые с данным утверждением не согласны, рекомендую ещё раз перечитать пассаж об ихнем обыденном сознании двумя абзацами выше и устыдиться, пока никто не видит). Возможно, вы не в курсе, но 2015 году вышла третья (как утверждают авторы, последняя) редакция данного труда. На сетевых просторах можно найти исправленный вариант от 2017 года. Для тех, кто не читал, сообщаю, что книга полностью переработана. Часть материала убрана, часть добавлена. Учебник на очень хорошем уровне объясняет базовые понятия и принципы построения схем, содержит массу рабочих примеров. Весь материал книги строго об электронике. Там нет программ и цифровых методов, а микроконтроллеры упоминаются исключительно в контексте использования их периферии. Только хардкор: голое железо и пути подхода к снаряду. Две предыдущих редакции (1983 и 1989 годов, имеются переводы советского издательства Мир) достаточно сильно устарели в части схемных примеров, т.к. многие элементы просто сняты с производства. В новом издании учтён этот опыт: теперешние схемы сильнее концептуализированы и меньше зависят от конкретных компонентов. В тексте даются подробные описания принятых решений и обоснования сделанного выбора. Серьёзно расширена классификационно-справочная часть материала. Скажем, описанию разностных, дифференциальных и инструментальных усилителей и их отличий друг от друга посвящено более 40 страниц. Имеются подробные описания схемных решений лидеров отрасли, например вольтметров Agilent. Общий объём увеличился до 1100+ страниц (да, это то самое исключение). В ASCII коде это 4.5M. Четыре с половиной мегабайта очень хорошо (легко, красиво, понятно и увлекательно) написанного текста. На прекрасном английском языке. Короче, вы поняли: всё плохо, кругом заговор, и надежды нет. Но, смотрите, кто-то уже спешит вам на помощь! Это я, здравствуйте. Перевод мой хорош, да и сам я человек неплохой. Всё бесплатно, то есть даром. Так что, читайте, товарищи дорогие, просвещайтесь, поминайте меня добрым словом. Сайт некоммерческий, куда слать рекламации вы знаете. Всю книгу пока прочитать не получится доступны только 3.8M. Перевод вёлся строго ручкой по бумаге без этих ваших дьявольских компьютерных штучек, крадущих у книг душу (ну, вы в курсе). Терминология сверялась с отечественной литературой по теме. Короче, можете заценить итоги трёх лет труда. the-epic-file.com/bookshelf.htm

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

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

Юноше, обдумывающему электронику. Ключи к материалу для самостоятельного изучения

20.02.2021 10:19:11 | Автор: admin
Перевод учебника Искусство схемотехники пополнился Частью 3, в которой разбираются полевые транзисторы. Книга приобрела целостный, хотя всё ещё не окончательный, вид. На данный момент отсутствуют три части 11 (Программируемая логика), 14 (Компьютеры, контроллеры и шины данных), 15 (Микроконтроллеры) и таблицы. Таблицы отложены до завершения перевода (там почти одни цифры, с которыми можно ознакомиться и в оригинале), а остающиеся темы при всём уважении к авторам лучше изучать по другим источникам. В анонсе перевода среди жалоб на несовершенство мира была высказана мысль о необходимости грамотного руководства освоением нового материала. Здесь предлагается метод изучения, рационализирующий данный процесс и некоторые соображения о повышении КПД знаний, относящиеся к системе Цеттелкастен.

Итак, к основному материалу книги добавилась Часть 3 (Полевые транзисторы), рассказывающая о линейных усилителях, повторителях и ключах на полевых приборах с p-n переходом и с изолированным затвором. Но, если вы новичок, обдумывающий электронику, а равно и не обдумывающий, но соприкасающийся с ней по работе, начинать знакомство с данной темой следует с другого конца и по специфической схеме. Но обо всём по порядку.

Искусство схемотехники учебник по практическому построению электронных схем, выросший из односеместрового лабораторного курса по электронике Гарвардского университета. Он достаточно полон, подробен и самодостаточен (*) для самостоятельного изучения, причём не требует от ученика специальной подготовки. Всем известно, что королевских путей к знанию не существует, но одна уловка всё же есть. Это принцип Паретто, гласящий, что 20% людей выпивает 80% пива. Иначе говоря, 20% знаний и навыков закроют 80% типовых задач. Осталось найти эти 20%. Как раз здесь совершенно случайно из ближайших кустов выхожу я во всём белом. Ниже предлагается путеводный ключ, лучше всего, на мой взгляд, подходящий для изучения учебника неспециалистом. Замечу, что для специалиста книга тоже подойдёт диапазон у неё совершенно удивительный, просто специалист знает, чего хочет, и ключ ему не нужен.

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

После освоения способов передачи сигналов стоит изучить Часть 13 (Аналого-цифровые преобразования). Здесь даются базовые сведения об АЦП и ЦАПах, форматах их данных, ошибках, входных и выходных характеристиках. Эта часть книги позволит понимать процесс перевода аналогового сигнала в цифру на более глубоком уровне и полнее воспринимать аналого-цифровой тракт в целом. В этой же Части 13 есть описание методов синтеза частот, которые дополняют создание аналоговых сигналов с помощью ЦАПов.

Материал Части 12 и 13 закрывает порядка 60% вопросов взаимодействия вычислительных систем с внешним миром. Следующим шагом будет Часть 4 (Операционные усилители). Здесь даются базовые сведения об этом главном строительном элементе аналоговых схем. Углублённое изучение ОУ продолжается в Части 5 (Точные схемы). В Части 5 подробно разбираются источники ошибок и методы их компенсации. Её будет полезно пробежать в ознакомительных целях, потому что здесь описываются возможные варианты операционных усилителей, и такие сведения будут полезны просто для расширения кругозора.

Теперь у вас есть 80%. На этом, наверно, стоит остановиться, а книгу перевести из статуса учебник в статус справочное пособие. Остальные темы, как-то: Часть 6 (Фильтры), Часть 7 (Генераторы и таймеры), Часть 8 (Проектирование малошумящей аппаратуры), Часть 9 (Регуляторы напряжения и преобразователи мощности) и Часть 10 (Цифровая логика), следует изучать, если есть конкретная задача или желание ознакомиться с вопросом.

Пара слов об основах Части 1 (Основы), Части 2 (Биполярные транзисторы) и Части 3 (Полевые транзисторы). Не надо в них лезть ! Несколько парадоксальная рекомендация, ведь обычно изучение электроники начинается именно с этих трёх тем. Дело в том, что чем проще инструмент, тем больше умения требуется, чтобы с ним работать. Современная электроника нечасто требует перехода на уровень отдельных транзисторов. Знакомства с ОУ (Часть 4) и с параметрами внешних выводов ИМС (Часть 12) достаточно для подавляющего большинства задач. Всё остальное будет проникать в голову или вызывать специальный интерес по мере продвижения вперёд. Вся книга пронизана перекрёстными ссылками на сопутствующий, пояснительный или аналогичный материал из других частей. По ним надо ходить и пытаться разобраться, но фанатизм в этом направлении будет скорее вредить.

Надеюсь, этот скромный набор рекомендаций вам поможет.

Теперь пара слов об упоминавшейся на Хабре системе организации персональных знаний Цеттелкастен. Позволю высказать собственное мнение о предмете, которое возникло в момент редактирования перевода. В Части 3 (рис. 3.114 на стр. 212) приводится красивая схема расширения входного диапазона напряжений линейного стабилизатора. Она не вчера придумана, лично мне знакома более 10 лет, но, только проводя последнюю сверку с оригиналом, я понял, что речь идёт об обычном каскоде. Т.е. я перевёл Часть 9, где она встречалась, Часть 3, отредактировал, отформатировал в html, чтобы на самом последнем этапе перед публикацией понять довольно очевидную с самого начала вещь.

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

(*)
Пояснительные выражения объясняют темные мысли, поэтому везде, где мне случается зависнуть над фразой, схемой или формулой, я вставляю собственные пояснения. Исхожу при этом из того, что сам я тему знаю достаточно хорошо, и, если даже я затыкаюсь, то новичку точно требуются чуть более развёрнутые объяснения. Мои комментарии идут на вкусном абрикосовом фоне (и только на нём). ####### Ну, вы поняли ########.

И собственно учебник, а то вдруг кто не знает.
Подробнее..

Переводы малых сумм из Европы в Украину

04.05.2021 14:16:26 | Автор: admin

Привет, ребят.

Недавно я задался вопросом, какой из путей перевода денег из Европы в Украину наиболее оптимальный. В наши дни существует довольно много банков как реальных, так и виртуальных, позволяющих переводить небольшие суммы денег с минимальными потерями. У каждого из них свои комиссии, свой курс обмена и другие нюансы. Я решил собрать некоторые из тех, которыми я пользуюсь (пользовался) на одной картине и по сути построить граф, где вершинами являются эти самые банки.

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

Если вкратце, то у меня получились такие выводы:
Когда нужно быстро, и на любую карточку, то Paysend. Потеря 1.5 на переводе и 25 копеек на каждом евро при конвертации.
* Когда нужны наличные в евро, то Privatbank EUR. Потеря 0.5% при снятии наличных в отделении PrivatBank.
* Когда нужны наличные в гривнах, то через SEPA в Monobank EUR и далее перевод с конвертацией на Monobank UAH. Потеря 0.33% за пользование SEPA и 15 копеек на каждом евро при конвертации.

Участники: Иностранный банк (в моём случае Revolut), Monobank EUR (SEPA), Monobank UAH, PrivatBank EUR, Paysend, TransferWise, MoneyGram, Western Union.

Для начала я построил граф этих участников и направления переводов с указанием комиссии и/или курса обмена:

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

Дальше, построил график потерь от переводов по каждому из путей. Значения по оси Y это потери в грн, значения по оси X это стандартные суммы перевода (10 - 1000 EUR). Чем график ближе к горизонтальной оси, тем меньше потерь. Чем резче растёт график, тем быстрее увеличиваются потери с ростом суммы.

У каждого из переводов есть свои нюансы (преимущества и недостатки).

Например, Paysend идёт в течение минуты и можно переводить на любую карточку. Но там можно получить только гривны. С другой стороны у PrivatBank есть возможность открыть евровый счёт и платить 0.5% за снятие валюты.

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

Подробнее..

Перевод Как e-commerce бизнесу выйти на новые рынки? 6 важных шагов на пути к локализации интернет-магазинов

04.12.2020 12:06:11 | Автор: admin

В 2020 Covid-19 сделал интернет-продажи ещё популярнее и ускорил выход магазинов в онлайн. Мировой объём розничных онлайн-продаж составил 3,53 триллиона долларов США в 2019 году. И планируется, что к 2022 году эта цифра вырастет до 6,54 триллионов долларов США.

Многие владельцы бизнесов осознали, насколько важно присутствие онлайн. В апреле 2020 года число новых интернет-магазинов увеличилось в два раза по сравнению с предыдущим месяцем и в полтора раза по сравнению с апрелем 2019 года.

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

Источник: freepik.comИсточник: freepik.com

Какие рынки лидируют в e-commerce?

Компания Goldman Sach Group в докладе, опубликованном в конце июля 2020 года, заявила, что рост доли онлайн-покупок в объёме всей розничной торговли достигнет 19% в 2020 году по сравнению с ранее прогнозируемыми 16%. Это обусловлено высокими темпами роста e-commerce бизнеса в США, Западной Европе, Бразилии и большинстве стран Азиатско-Тихоокеанского региона, говорится в докладе. Ожидается, что онлайн-продажи займут около 22% рынка розничных продаж к 2023 году.

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

Сегодня 85% мировой покупательской способности находится за пределами США. Китай крупнейший в мире рынок электронной коммерции, где ежегодный оборот от онлайн-покупок оценивается примерно в 672миллиарда долларов США. За Китаем следует США с оборотом в 340миллиардов долларов, и незначительно от них отстают Великобритания, Япония, Германия, Франция, Южная Корея, Канада, Россия и Бразилия.

Что такое рост и расширение бизнеса?

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

Покупатели со всего мира хотят, чтобы процесс покупки был им понятен и знаком. Что же для этого нужно?

Правильный ответ локализация онлайн-магазина.

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

Локализация онлайн-магазина: процесс от А до Я

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

Перевод сайта это лишь самый минимум, который вы должны сделать. Это критически важно, так как около 80% транзакций в Интернете происходят на родном языке пользователя. Согласно статистике, на неанглоязычные страны приходится 20% от общего числа мировых продаж на рынке электронной коммерции. Именно поэтому необходимо предоставлять информацию, хотя бы самую важную, на родном языке пользователя.

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

1. Локализация взаимодействия с пользователем

User experience (UX) это то, как пользователь взаимодействует с продуктом и то, какие эмоции он от этого испытывает. Даже если интерфейс сайта или приложения полностью соответствует культурным нормам страны, он может показаться странным для пользователей. Приведём несколько примеров.

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

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

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

  • Цвета, графика и форматирование. Для американца или европейца сайт в азиатском стиле может быть слишком непривычным из-за пёстрого оформления в виде яркого лоскутного одеяла, сотканного из текста, изображений, GIF-файлов, анимаций и иконок. А азиатский дизайн может показаться перегруженным информацией для западных пользователей, которые больше привыкли к чётко структурированным блокам, в то время как посетителям из Азии вполне комфортно пользоваться таким ярким сайтом.

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

Сайт Amazon (США)Сайт Amazon (США)Сайт Amazon (Япония)Сайт Amazon (Япония)

Вот несколько очевидных отличий:

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

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

  • Названия английских товаров выделены жирным чёрным шрифтом.

  • Японские названия, похоже, ничем не отличаются от остальной части описания товара (используется такой же синий шрифт).

2. Локализация корзины

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

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

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

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

Источник: проект 2Chekout по стратегии адаптации корзины для Visicom MediaИсточник: проект 2Chekout по стратегии адаптации корзины для Visicom Media

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

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

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

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

3. Локализация цен на товары

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

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

4. Локализация способов оплаты

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

Источник: 2CheckoutИсточник: 2Checkout

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

Хотя около 86% мировых онлайн-платежей осуществляются с помощью кредитных карт и PayPal, в Китае 79% онлайн-заказов совершаются с использованием Alipay или WeChatPay. Поэтому при выходе на китайский рынок советуем предложить эти два варианта покупателям, чтобы получить более высокий коэффициент конверсии. В Бразилии очень популярны Boleto и карты с возможностью оплаты в рассрочку: на их долю приходится более 50% онлайн-заказов. В Европе востребован SEPA Direct Debit, а японские покупатели предпочитают Konbini.

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

Такая система даёт ряд преимуществ:

  • Интеллектуальная маршрутизация платежей позволяет перенаправлять платежи между различными платежными шлюзами. Она служит в качестве механизма переключения при сбое и повышает скорость авторизации карт.

  • Система Account Updater, разработанная совместно Visa и MasterCard, которая автоматически обновляет номера и срок действия карт клиентов на основании информации от банка-эмитента.

  • Логика повторных попыток позволяет свести к минимуму сбои и восстановить до 20% неудачных транзакций;

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

5. Локализация в соответствии с нормативно-правовой базой и налоговой системой страны

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

Вы должны взимать правильную сумму налога для каждого рынка, а затем перечислять эти налоги соответствующим налоговым органам. К счастью, этот процесс можно автоматизировать: это легко сделать, если вы пользуетесь системой GeoIP, определяющей автоматически местоположения пользователя. А налоговые калькуляторы помогут немного разобраться в области налогообложения.

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

Нормативно-правовое соответствие это ещё один важный пункт для компаний, которые выходят на мировой уровень.

Генеральный регламент ЕС о защите персональных данных (GDPR), Закон штата Калифорния о защите конфиденциальности потребителей (CCPA), Федеральный закон О персональных данных это лишь примеры законодательной базы, которая регулирует порядок сбора, хранения и использования компаниями личных данных потребителей в различных странах.

Источник: 2CheckoutИсточник: 2Checkout

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

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

6. Локализация службы поддержки пользователей

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

Мы советуем сделать отдельный телефонный номер и завести отдельную почту для каждого региона. Если у вас нет бюджета, чтобы содержать команду техподдержки пользователей, то вы можете использовать простой и удобный вариант страницу F.A.Q. с наиболее популярными вопросами от пользователей. Электронная почта также отличный вариант.

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

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

Заключение

В 2020 году стало очевидно, что потенциал e-commerce рынка невероятно большой. Для предприимчивых бизнесменов сейчас сложились идеальные условия, чтобы вывести продукт или услугу на новые рынки и увеличить свой доход. И качественная локализация это один из ключей к успеху на мировом рынке.

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

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

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

О переводчике

Перевод статьи выполнен в Alconost. Alconost занимаетсялокализацией игр,приложений и сайтовна более 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики, продающие, имиджевые ролики, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее..

Разные типы IT-текстов о чем стоит помнить переводчику

24.02.2021 18:11:35 | Автор: admin

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

Содержание:

Трудности IT-перевода в целом

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

Сначала мне казалось, что переводить IT-тексты будет легко, ведь я владела темой и терминологией на английском, а русский мой родной язык. Что тут может быть сложного? Но довольно скоро я столкнулась с рядом подводных камней:

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

  • Поскольку IT-сфера развивается стремительно, в ней постоянно появляются новые термины и понятия, для которых ещё нет устоявшихся русских названий. И их приходится придумывать.

  • Границы между терминами и сленгом в русскоязычном IT довольно размыты. Если на профессиональных форумах вполне уместно использовать сленг, то в официальной документации для пользователей это чаще всего неприемлемо. Поэтому постоянно приходится искать баланс и подбирать нужные термины: не канцелярские, но и не сленговые, а более человеческие и при этом верно передающие смысл.

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

Коротко о процессе перевода в Plesk

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

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

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

Итак, что же именно мы переводим? И, главное, как?

Перевод UI: "попробуйте еще раз позже"

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

Контекст это важно

Русский язык отличается от английского большим количеством различных форм слова: необходимо учитывать падеж, род, часть речи и так далее. И если, к примеру, сообщение состоит из одного слова Open, мы можем перевести его в зависимости от контекста разными способами: Открыть, Откройте, Открыто, Открыт, Открыта, Открыты. Поэтому необходимо понимать, в каком месте интерфейса и в какой момент оно отображается. Если же переводить в лоб, возможны подобные ситуации:

В момент перевода было неизвестно, что "Open" относится к числу открытых задач. В момент перевода было неизвестно, что "Open" относится к числу открытых задач.

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

Глоссарий нам поможет

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

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

Как быть с числительными?

В русском языке больше форм существительных, зависящих от числительных, чем в английском: 1 элемент, 2 элемента, 5 элементов. Если не учитывать форму слова, то, например, сообщение %%total%% items total (где %%total%% переменная, означающая число) может после перевода выглядеть так:

Слово "элементов" используется с любым числом.Слово "элементов" используется с любым числом.

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

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

То, что не выделено цветом, переводится. В поле "Preview" можно подставить число и проверить.То, что не выделено цветом, переводится. В поле "Preview" можно подставить число и проверить.

Однако если в вашем арсенале пока нет никаких специальных инструментов для работы с числительными (а так было и у нас, пока мы не начали использовать синтаксис ICU), могу порекомендовать воркэраунд: перенести аргумент числа в конец сообщения и использовать общую форму для всех существительных. То есть фразу %%total%% items total при переводе меняем следующим образом: Всего элементов: %%total%%. На мой взгляд, такой вариант вполне работает в большинстве случаев.

О различиях языков

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

Английский язык более эмоционален. В английском интерфейсе нередко можно встретить сообщения с восклицательным знаком. В русском же языке это будет выглядеть слишком эмоционально и ассоциироваться с криком. А ещё в английских сообщениях часто используется слово Please (Пожалуйста), которое в русском языке, как правило, неуместно. Например, фраза Please try again later! в английском интерфейсе выглядит вполне приемлемо и звучит по-дружески. Но переведенная дословно фраза Пожалуйста, попробуйте ещё раз позже! звучит как-то тревожно. Поэтому переводим спокойнее, без пожалуйста и восклицательного знака: Попробуйте ещё раз позже.

Названия разделов меню: капитализация и кавычки. В русском языке не используется капитализация названий разделов меню по первым буквам каждого слова, принятая в английском языке. У нас в названиях заглавная буква используется только в первом слове. То есть, например, название раздела Change Password переводится как Изменить пароль. Кроме того, внутри предложения названия элементов интерфейса используются в английском языке без кавычек, а в русском в кавычках. Например: "Go to Change Password" Перейдите в раздел "Изменить пароль".

Другой порядок слов. В английском языке порядок слов строго фиксирован: подлежащее-сказуемое-второстепенные члены предложения. В русском же языке порядок слов может варьироваться в зависимости от того, на чём вы хотите сделать смысловой акцент. Поэтому, чтобы перевод выглядел естественно, не переводим дословно, а думаем, какая часть фразы самая важная, и помещаем её в конец предложения. Например: The certificate cannot be issued Выпустить сертификат не удалось (при этом дословный перевод Сертификат не может быть выпущен звучит понятно, но не совсем по-русски.)

Больше о стилистических различиях английского и русского языков можно прочитать, например, в Microsoft Russian Style Guide.

Перевод документации для пользователей: "флажок" или "чекбокс"?

Документация для пользователей другая большая и важная часть контента, который мы переводим. Здесь уже с контекстом дело обстоит гораздо лучше, так как на перевод к нам приходят целые осмысленные куски текста: предложения и абзацы. Кроме того, доступ к англоязычной документации у нас есть практически всегда, так что мы можем прочитать всю главу на английском языке и, если что-то непонятно, задать вопрос техническим писателям. Однако и тут есть свои особенности.

Стиль надо быть проще

Техническая документация у многих ассоциируется с сухим канцелярским стилем и ГОСТами. Действительно, в русскоязычной документации долгое время был принят такой стиль (а в некоторых технических областях, например, в описании промышленного оборудования, он принят до сих пор). Что касается стиля документации в IT, в последние годы он, к счастью, становится всё более человеческим. Крупные IT компании в своих руководствах по стилю призывают писать более естественно и менее формально. Например, вот основные принципы Microsoft's brand voice:

  • Warm and relaxed (Дружелюбный и естественный)

  • Crisp and clear (Четкий и понятный)

  • Ready to lend a hand (Предлагающий помощь)

В Plesk мы пишем документацию в таком же дружелюбном и естественном стиле и сохраняем его при переводе. Избегаем канцелярских слов и оборотов, например:

  • Вместо данный лучше этот

  • Вместо выполнить удаление лучше удалить

  • Вместо в данный момент лучше сейчас

  • Такие слова как операция, процедура, действие в большинстве случаев можно опустить

Терминология как в UI

Для перевода документации мы используем тот же глоссарий, что и для перевода UI. Это нужно для того, чтобы одни и те же элементы назывались в UI и в документации одинаково.

Например, у нас в продукте есть тип резервной копии incremental. Раньше в русском UI он был переведён как инкрементный, а в гайде администратора как добавочный. Это могло привести к недопониманию, и сейчас мы занесли этот термин в глоссарий, так что это расхождение исправлено.

В интерфейсе тип резервной копии называется "Инкреметный".В интерфейсе тип резервной копии называется "Инкреметный".А в документации тот же тип был назван "Добавочным". А в документации тот же тип был назван "Добавочным".

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

Как назвать главы

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

  • Getting Started Начало работы

  • About О <название продукта>

  • Appendix Приложение

  • Troubleshooting Решение проблем

  • FAQ Ответы на часто задаваемые вопросы

Лучше всего список типовых названий внести в руководство по стилю (Style guide) для соответствующего языка. Style guide для документации на исходном языке обычно пишут технические писатели, а вот составить аналогичные руководства для других языков задача переводчиков.

Как назвать элементы и действия

Ещё один момент, который стоит отразить в руководстве по стилю стандартный перевод названий самих элементов интерфейса и действий с ними. Вот несколько примеров переводов, которые мы используем:

  • check box флажок (а не чекбокс)

  • icon значок (а не иконка)

  • click нажать (а не кликнуть)

  • select the check box установите флажок (также возможен вариант выберите опцию)

  • go to перейдите в раздел

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

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

Перевод документации для разработчиков: "обработчик" или "хук"?

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

Нужно ли переводить?

Многие считают, что документацию для разработчиков вообще не нужно переводить, ведь она состоит в основном из примеров кода и понятна и так. Отчасти это справедливо, но всё же зависит от документа. Например, это верно для справочников по API или CLI у нас эти документы не переводятся. Но другой документ, Руководство по разработке расширений Plesk, мы всё же перевели на русский язык, и некоторые наши разработчики уже это оценили (хотя и удивились). Это руководство представляет собой по сути учебник по созданию расширений, и читают его как наши разработчики, так и сторонние (написать расширение для Plesk может любой желающий). В этом учебнике есть описания всех шагов работы с расширением, упражнения, примечания в общем, не только код, но и много полезного текста, читать который удобнее на своем родном языке.

Переводить нужно, но не всё

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

  • Примеры кода (в них можно перевести только комментарии)

  • Названия функций, методов, переменных и т.д. в тексте

  • Названия команд и их аргументов

О том, какие части переводить не нужно, мы узнаём по разметке и подсветке, которую нам показывает программа переводов:

Названия метода и аргумента не переводятся.Названия метода и аргумента не переводятся.

Уточняем термины

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

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

Перевод маркетинговых текстов: "well give you peace of mind"

Маркетинговые тексты в чистом виде мы переводим нечасто. Но время от времени они встречаются нам прямо в интерфейсе: это описания наших платных функций и расширений (например, в Каталоге расширений Plesk можно выбрать и купить то или иное расширение). И этот тип контента стоит отметить отдельно, поскольку он заметно отличается по стилю от технического. Ведь его цель не столько объяснять, сколько продавать.

Эмоциональность это хорошо!

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

Маркетинговые тексты эмоциональны.Маркетинговые тексты эмоциональны.

Не переводим дословно

Дословный перевод маркетингового текста может выглядеть неестественно. Нужно настроиться на маркетинговый лад, поймать нужную идею и интонацию и передать её на своем языке своими словами, искренне и убедительно. Некоторые метафоры типа peace of mind вообще почти нереально перевести напрямую, и нужно тщательно выбирать наиболее уместные выражения. Скажу прямо, это достигается не сразу, и тут нужна практика. Могу порекомендовать искать похожие тексты на русском языке и ознакомиться с основами копирайтинга.

Проговариваем текст

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

Выводы

Подводя итог, могу сформулировать такие общие рекомендации, основанные на моем опыте перевода:

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

  • Задаем вопросы специалистам и обращаемся к признанным руководствам по стилю. Например, к Microsoft Russian Style Guide.

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

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

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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru