PHP Intl. Правильная транслитерация кириллицы

PHP Intl. Правильная транслитерация кириллицы

Современные фреймворки предоставляют готовый функционал в составе библиотек или хелперов для работы с библиотекой ICU (http://site.icu-project.org/home) через API Intl.

Такой функционал необходим для поддержки интернационализации разрабатываемого веб-сервиса. На основе указанной локали могут устанавливаться форматы отображения валют, времени и даты, а также подбираться настройки для инициализации транслитераторов (https://www.php.net/class.transliterator).

В разделе «Телеграм-каналы (https://chulakov.ru/notes)» сайта Студии во время автоматического импорта постов из наших каналов производится транслитерация названий заметок для формирования ЧПУ (https://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D0%BC%D0%B0%D0%BD%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_URL).

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

Например, уникальная часть URL заметки (https://chulakov.ru/notes/development/php-8-pocti-novogodnij-podarok) про релиз PHP 8 после транслитерации имела вид php-8-pocti-novogodnij-podarok. Замена некоторых букв произошла некорректно.

Для того чтобы транслитерация кириллицы производилась по традиционным правилам, необходимо произвести конфигурацию объекта-транслитератора (https://www.php.net/manual/ru/transliterator.create.php), передав следующее значение параметра $id:

Russian-Latin/BGN; Any-Latin; Latin-ASCII; NFD; [:Nonspacing Mark:] Remove; NFC;

После такой конфигурации результат преобразования наименования заметки изменится на php-8-pochti-novogodniy-podarok.

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

Сила разговора

Сила разговора

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

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

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

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

Вопрос: есть команда из трёх человек

Вопрос: есть команда из трёх человек: сильный разработчик, который делает быстро, но поверхностно; есть слабый разработчик, который делает медленно, но работающий код (и часто переделывает за сильным) и есть тимлид/пм (я), который не сильно разбирается в коде. Сильный буллит слабого, что тот не разбирается и вообще плохой программист. Что делать?

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

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

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

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

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

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

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

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

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

Продолжение позже…

Насмотренность - Напользованность

Если хочешь делать продукты с хорошим пользовательским опытом — развивай свой личный пользовательский опыт.

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

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

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

В общем, хватит только смотреть — больше пользуйся.

Про eng UX-тексты

Про eng UX-тексты

Про eng UX-тексты — как сделать первый шаг к тому, чтобы писать microcopy нормально, а не с помощью гугол-транслэйта. Блин, ну это такое позорище, что фу — For signature, например.

Мы дизайн-студия, которая разрабатывает дизайн для финтеха: банки и фин.сервисы. И всё. Никаких тревелов, букингов, отелей и блокчейна(боже упаси).

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

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

Итак, первый лайфхак — просто начните гуглить

Не ебите мозг друг другу:
— пустыми разговорами в чатиках с обсуждением грамматики и не/применимости к интерфейсам
— чтением и дрочкой великих и не очень словарей
— статей про microcopy: «а одни пишут так можно, а другие что нельзя»
— задротством с гугл-переводчиком или другими переводчиками получше
И пожалуйста, не надо слать друг-другу переводчики получше, и покачественнее.
Сделаете всё это позже или на досуге.

1.Просто берите и гуглите картинки сервисов в вашей сфере. Современных и клёвых. Конкурентов и партнёров.
bank, finance, fintech, payment, chat, invoice, interface, n26, monzo

2.Просто заходите на Dribbble и ищите те же фин.сервисы не от индийских, СНГ-шных и русских студий а от локальных ребят.

3.Просто разберитесь с тем, что такое Invoice в менталитете и в mind map-е той страны, для которой вы делаете сервис.
А нет, это уже не просто. Но тогда нечего делать то, в чём вы ничего не понимаете — сначала разберитесь.

Два дня изучения картинок референсов с фокусом на тексты — и вы уже шарите.
Не ебите мозг команде и себе.

Потом расскажу про второй шаг, а то сейчас начнётся ))