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

Направление письма

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

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



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

Ну, это азиаты.

Заключительную часть описания Red Architecture посвятим многопоточности. Ради справедливости стоит сказать, что начальный вариант класса v нельзя считать оптимальным, так как в нём ничего нет для решения одной из главных проблем к которой неминуемо приходят разработчики real world приложений. Для полного понимания текущей статьи необходимо познакомиться с концепцией Red Architecture здесь.



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

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

Типичные трудности перевода

Классический пример симбиоза знания языка и творческого начала в ходе перевода — деятельность братьев Стругацких. Кроме создания собственных произведений, они оба работали как переводчики с английского и японского под псевдонимами С. Бережков, С. Победин и С. Витин. И если вы читали советские издания Азимова «Как им было весело», Нортон «Саргассы в космосе» или Уиндема «День триффидов» — то это были переводы Стругацких.

Главный редактор популярного сайта для разработчиков и IT-специалистов TProger.ru, выросшего из ВК-паблика «Типичный программист», сделал весьма толковый обзор Lokalise, которым мы с вами с удовольствием делимся. Кто работает с локализацией мобильных и веб-приложений — те особенно оценят.

Lokalise — сервис для автоматизации процесса локализации приложений, который выбрали уже более 1 000 команд, включая MSQRD, Carousell, MEGOGO, Depositphotos. Мы изучили возможности платформы и в этом обзоре расскажем, за счет чего Lokalise помогает провести локализацию быстро и просто.

Первое знакомство

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

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



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

У нас есть клиетское приложение — редактор таблиц, в нём отображается лист таблицы. Экран у пользователя настолько большой, что на нём помещается 1 000 000 000 (один миллиард) табличных ячеек. Всё усложняется тем, что наш табличный редактор подключен к облаку для возможности совместного редактирования таблицы, поэтому изменения в любой из одного миллиарда ячеек “где-то в облаке” должны быть сразу же отображены нашему пользователю.

Паттерн Red Architecture позволяет реализовать данную функцию просто и с высокой производительностью.

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



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

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

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

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

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

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

Медленные сайты раздражают пользователей. Когда основной контент — фоточки, а сайт тормозит — это раздражает вдвойне. И как бы мы ни оптимизировали свой сервис, всегда остаётся такой фактор, как качество связи между пользователем и нашим ЦОДом. В решении этой проблемы нам помогает CDN.

Мы — это компания «Колёса Крыша Маркет», разработчик самых крупных и посещаемых сайтов частных объявлений в Казахстане и фотографии из объявлений — критически важная часть нашего бизнеса.

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

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

Twitter Lite и высокопроизводительные прогрессивные веб-приложения на React

Взгляд на то, как удаляли обычные и необычные узкие места в производительности при создании одного из крупнейших в мире прогрессивных веб-приложений (PWA) на React.js — Twitter Lite

Создание быстрого веб-приложения требует многих циклов измерений, куда тратится время. Нужно понять, почему это происходит, и применить потенциальные исправления. К сожалению, не бывает одного простого решения. Производительность — это бесконечная игра, где мы ищем и измеряем области для улучшения. В Twitter Lite сделано много маленьких улучшений в разных сферах: от первоначального времени загрузки до рендеринга компонентов React (и предотвращения повторного рендеринга), загрузки изображений и много другого. Большинство изменений небольшие, но они складываются, и в конечном результате мы получили одно из самых больших и быстрых прогрессивных веб-приложений.

В JavaScript есть тысячи способов выделить память, но разработчики языка лишили нас права её освобождать. Этим занимается сборщик мусора (Garbage collector, GC), функций управления которым также нет. В большинстве случаев он неплохо справляется со своей работой, однако когда в программе непрерывно освобождаются большие объёмы данных, порядка мегабайта в секунду, сборщик мусора может тупить, из-за чего процесс браузера разрастается в памяти до невменяемых размеров. В этой статье я покажу пару грязных трюков, с помощью которых можно ускорить освобождение памяти.

В июле прошлого года на Altitude 2016 Алекс Рассел (Alex Russell) из Fastly рассказал, как он видит будущее мобильных приложений с учетом PWA и service worker, как обеспечить надежную работу приложения в офлайне и как обойти «зловещую долину» в мобильном интерфейсе.

Сейчас service worker — это программируемое прокси внутри браузера

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

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

1) сильно падает количество обращений к странице;
2) постоянно растет процент отказов.


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

Привет, Хабр. Представляю вам свободный перевод статьи Джеймса Кайла «Introducing React Loadable». В ней Джеймс рассказывает, что такое компонент-ориентированный подход к разделению кода и представляет разработанную им библиотеку Loadable — инструмент, позволяющий реализовать этот подход в React.js приложениях.


Единый файл сборки и сборка из нескольких файлов

От переводчика: я позволил себе не переводить некоторые глаголы и термины, повсеместно использующиеся в непереведенной транслитерованной форме (как, например, «прелоадер» и «рендеринг»), полагаю, они будут понятны даже пользователям, читающим исключительно материалы на русском языке.

Привет, Хабр! Меня зовут Слава Волков, и я фронтенд-разработчик в Badoo. Сегодня я хотел бы немного рассказать про сбор статистики с фронтенда.

Мы знаем, что аналитика позволяет оценить эффективность работы любого веб-сайта, улучшить его работу, а значит, повысить уровень продаж и усовершенствовать взаимодействие пользователей с сайтом. Проще говоря, аналитика – это способ контроля над процессами, происходящими на веб-сайте. В большинстве случаев для обычных сайтов достаточно установить Google Analytics или «Яндекс.Метрику» – их возможностей вполне достаточно.

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

Как формат JPEG произвел в свое время революцию среди форматов изображений, так и новый формат FLIF обещает такого же масштаба событие для дизайнеров и веб-разработчиков.

FLIF (Free Lossless Image Format) – новый формат файлов для изображений, обеспечивающий беспрецедентное сжатие без потерь. Файлы получаются:

• На 14% меньше, чем WebP, без потерь
• На 22% меньше, чем BPG, без потерь
• На 33% меньше, чем сжатый через ZopfliPNG PNG-файл
• На 43% меньше, чем обычные PNG-файлы
• На 46% меньше, чем оптимизированные по Adam7 чересстрочные PNG-файлы
• На 53% меньше, чем JPEG 2000, без потерь
• На 74% меньше, чем JPEG XR, без потерь

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

Дружим Angular с Google

Google ненавидит SPA

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

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

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

Из комментариев к статье стало понятно, что очень многие люди склоняются в сторону экосистемы Create React App (он же React Scripts). Это вполне разумно, т.к. это самый популярный и простой в использовании продукт (благодаря отсутствию конфигурации и поддержке ведущих людей React-сообщества), в котором, к тому же, есть почти все необходимое — сборка, режим разработки, тесты, статистика покрытия. Не хватает только серверного рендеринга.

В качестве одного из способов в официальной документации предлагается либо вбивать начальные данные в шаблон либо воспользоваться статическими слепками. Первый подход не позволит поисковикам нормально индексировать статичный HTML, а второй — не поддерживает проброс никаких начальных данных, кроме HTML (фраза из документации: this doesn't pass down any state except what's contained in the markup). Поэтому если используется Redux, то придется для рендеринга использовать что-то другое.

Я адаптировал пример из статьи для использования с Create React App, теперь он называется Create React Server и умеет запускать серверный рендеринг командой:

create-react-server --createRoutes src/routes.js --createStore src/store.js