Да - если тексты хранятся в базе, то они попадут в специальную функцию уже как финальный текст, никакой разницы не будет - как будто сразу из файла было. Насчет git - есть идея сделать фичу, где время от времени автоматически создается pull-request со всеми заменами. Что может быть вариантом работы для тех, кто не доверяет внешней системы - тут перед деплоем все возвращается к себе в репо.
ничего не меняется совершенно - такой же предосмотр, такое же редактирование прямо в контексте рендера. просто тексты в JS коде оборачиваются в функцию/компонент
Этих я уже посмотрел :) У них все намного проще, примитивнее, и много надо делать вручную (допустим закачивать скриншоты). Это скорее просто админка для работы с существующими файлами, обертка вокруг старой технологии
я не нашел - подскажете? все что я нашел, и что мне скидывают другие - это облачные сервисы по работе с файлами переводом (ресурсные файлы с текстами). это как бы хорошо, но просто небольшое улучшение по сравнению со старым обычным i18n. я же предлагаю вообще отказаться от таких ресурсных файлов, и решение полезно не только для переводов - даже для среднего размера проекта с одним языком уже становится проблемой уследить за "что мы там говорим" на сотне разных страниц и в имейлах.
спасибо за ссылку! посмотрел, я про них не знал. действительно, частично похоже - сам редактор, но у них таки традиционный перевод текстов из отдельных файлов (ресурсных), просто они добавили возможность предпросмотра через подмену текстов + JS код. у них для этого требуется целое окружение отдельное поднять, чтобы там работали переводчики - то есть они на реальном сайте (хоть может и не production) работают. у меня - от каждой страницы сохраняется snapshot, рендер, включая все CSS зависимости. как результат, ничего дополнительного делать не надо вообще - с первых же дней страницы появляются в онлайн-редакторе. намного проще и удобнее, мне кажется. другой очень большой минус - навигация ручная у них. так как это настоящий реальный сайт, то чтобы проверить как на странице X пользователь Y что-то видит - надо воссоздать весь сценарий, и так каждый раз. а у меня - все состояния и сценарии поведения заранее определены и по ним можно бесконечно туда-сюда переходить :)
2) да — вызов спец-функции или директивы отслеживает через stack tracing и статический анализ откуда был вызов, какие переменные подставлены и тд
3) пререндер через популярные современные утилиты вроде puppeteer. могу сразу увидеть, что тайская версия текста для кнопки — не влазит в ширину на телефоне
про облачные существующие сервисы — я не знал, я искал, хорошо искал, но не смог найти ни одного. поэтому благодарен за названия — я обязательно посмотрю. если там что-то подобное — то я просто буду пользоваться готовым :)
Всем? :) 1) облачное управление, а не редактирование массы текстовых файлов 2) авто-детект, где используются тексты — контекст 3) предпросмотр/рендеры 4) авто-определение отсутствующих текстов, и многое другое. это так — первое, что в голову пришло. Ваш аргумент можно использовать и про Dropbox и Google Drive — зачем велосипед, когда есть стандартный простой FTP. Закачал свои файлы на FTP и все — тоже самое
Предлагается пойти чуть дальше, чем это сделано в i18n. Имеем скажем текст от программиста: echo "Привет, у меня есть {$apples} яблок"; Наш сервис видит (благодаря статическому анализу), что внутри текста есть переменная $apples. В админке мы берем и выделяем мышкой слово «яблок» и нажимаем кнопку: «привязать к числу», где нам предлагается выбрать переменную. Она тут одна — $apples. Тогда подобно i18n, мы в админке предоставляем варианты написания в зависимости от цифры. Такой способ очень гибкий — не обязательно переводить весь текст, можно менять только фрагмент. Можно иметь несколько цифр внутри текста и тд. Ну и конечно, самый простой вариант — обязывать программиста передавать число вторым параметром в функцию p(), как это сделано сейчас в i18n. Но это не менее гибкий вариант и больше ручной работы
Над этим я еще думаю :) Технически весь необходимый арсенал уже есть — очень легко делается front-end тестирование со скриншотами (тот же puppeteer), надо только придумать как это будет организовано и как это будет управляться
Самое худшее, что может случиться — это юзеры увидят «сырые» сообщения от разработчика. Даже это лучше, чем скажем увидеть «common.salutations.welcome» вместо сообщения (в случае метода #2) :) Можно придумать настройку — хочет ли компания по дефолту автоматический fallback если совпадает исходный параметр или нет. А если программист совсем сильно зарефакторил — то тут уже наверное сервис непричем, это в любом случае может быть проблемой, независимо от подхода
Ну, здесь нагрузки не должно быть никакой — просто обернуть параметры в функцию или директиву и все. На этом работа программиста закончена. А дальше уже коллеги могут смотреть и править. И никто не надоедает программистам с просьбами вроде: «измени текст Х на странице Y» :) Ну и вообще, коммиты в репозиторий, которые просто правят какую-нибудь опечатку — это достаточно скучно
Да — правильно, одна и та же фраза из двух мест будет показана дважды — будут указаны маршруты, имя шаблона или контроллера. Если это один шаблон (partial), то редактируется один раз, и в админке подписано, что это использовано на нескольких страницах. Если действительно просто повторяющийся текст — то заполняется как новый текст, но есть какой-то shortcut, чтобы переиспользовать существующий. Типа: «у Вас используется такое же выражение на страницах Х и Y, скопировать текст оттуда?»
Если код отрефакторили, то делаем попытку определить откуда по параметрам — изменился файл, откуда происходит вызов, но скорее всего исходный параметр остался тем же — вроде "Hello {$name}". Опять же, показываем диалог: «Это, наверное, перенесенный текст отсюда… Подтвердить?»
через debug_backtrace() находим файл и номера строк, откуда произошел вызов функции, а затем делаем статический анализ (PhpParser) этих строк, чтобы отделить куски чистого текста от переменных и запомнить имена переменных (для читаемости). я проверил — работает
Да, в p() обращение к хранилищу. Хранилище — файловая система, и есть консольная команда, которая синхронизирует эти файлы с текстами с внешним API. Редакторы там что-то редактировали, а во время следующего билда скачались их новые тексты все
я накидал на локальной машине простенький прототип, чтобы проверить, что концепция реализуемая :) задумываюсь о том, чтобы создать такой сервис — пока не знаю по какой бизнес-модели.
дело вкуса :) мне просто не хочется каждый раз повторять одни и те же строки. я пишу код, чтобы делать жизнь юзеров лучше, а не чтобы наслаждаться идеальностью абстракций в своем коде
Вопрос принципиальный
Если придерживаться мнения, что разработка — должна происходить быстро и доставлять удовольствие программисту, то тут — перебор. Программист целых 3 строки будет миллион раз повторять в коде, чтобы сохранить запись. Не говоря уже о читаемости — «persist» переводится как «сохранить», но оно не сохраняет. «flush» переводится как «сбросить», «очистить», но оно сохраняет в базу.
Но это, конечно, holy war. Кому-то нравится программировать, кому-то нравится смотреть на абстракции в коде.
// you can fetch the EntityManager via $this->getDoctrine()
// or you can add an argument to the action: createProduct(EntityManagerInterface $entityManager)
$entityManager = $this->getDoctrine()->getManager();
$product = new Product();
$product->setName('Keyboard');
$product->setPrice(1999);
$product->setDescription('Ergonomic and stylish!');
// tell Doctrine you want to (eventually) save the Product (no queries yet)
$entityManager->persist($product);
// actually executes the queries (i.e. the INSERT query)
$entityManager->flush();
Пару лет работал с Symfony, мне кажется производительность труда (программиста) все-таки выше в Laravel, некоторые вещи слишком усложнены искусственно в Symfony. Одно сохранение модели чего стоит
Да - если тексты хранятся в базе, то они попадут в специальную функцию уже как финальный текст, никакой разницы не будет - как будто сразу из файла было. Насчет git - есть идея сделать фичу, где время от времени автоматически создается pull-request со всеми заменами. Что может быть вариантом работы для тех, кто не доверяет внешней системы - тут перед деплоем все возвращается к себе в репо.
ничего не меняется совершенно - такой же предосмотр, такое же редактирование прямо в контексте рендера. просто тексты в JS коде оборачиваются в функцию/компонент
Этих я уже посмотрел :) У них все намного проще, примитивнее, и много надо делать вручную (допустим закачивать скриншоты). Это скорее просто админка для работы с существующими файлами, обертка вокруг старой технологии
я не нашел - подскажете? все что я нашел, и что мне скидывают другие - это облачные сервисы по работе с файлами переводом (ресурсные файлы с текстами). это как бы хорошо, но просто небольшое улучшение по сравнению со старым обычным i18n. я же предлагаю вообще отказаться от таких ресурсных файлов, и решение полезно не только для переводов - даже для среднего размера проекта с одним языком уже становится проблемой уследить за "что мы там говорим" на сотне разных страниц и в имейлах.
спасибо за ссылку! посмотрел, я про них не знал. действительно, частично похоже - сам редактор, но у них таки традиционный перевод текстов из отдельных файлов (ресурсных), просто они добавили возможность предпросмотра через подмену текстов + JS код. у них для этого требуется целое окружение отдельное поднять, чтобы там работали переводчики - то есть они на реальном сайте (хоть может и не production) работают. у меня - от каждой страницы сохраняется snapshot, рендер, включая все CSS зависимости. как результат, ничего дополнительного делать не надо вообще - с первых же дней страницы появляются в онлайн-редакторе. намного проще и удобнее, мне кажется. другой очень большой минус - навигация ручная у них. так как это настоящий реальный сайт, то чтобы проверить как на странице X пользователь Y что-то видит - надо воссоздать весь сценарий, и так каждый раз. а у меня - все состояния и сценарии поведения заранее определены и по ним можно бесконечно туда-сюда переходить :)
3) пререндер через популярные современные утилиты вроде puppeteer. могу сразу увидеть, что тайская версия текста для кнопки — не влазит в ширину на телефоне
про облачные существующие сервисы — я не знал, я искал, хорошо искал, но не смог найти ни одного. поэтому благодарен за названия — я обязательно посмотрю. если там что-то подобное — то я просто буду пользоваться готовым :)
echo "Привет, у меня есть {$apples} яблок";Наш сервис видит (благодаря статическому анализу), что внутри текста есть переменная $apples. В админке мы берем и выделяем мышкой слово «яблок» и нажимаем кнопку: «привязать к числу», где нам предлагается выбрать переменную. Она тут одна — $apples. Тогда подобно i18n, мы в админке предоставляем варианты написания в зависимости от цифры. Такой способ очень гибкий — не обязательно переводить весь текст, можно менять только фрагмент. Можно иметь несколько цифр внутри текста и тд. Ну и конечно, самый простой вариант — обязывать программиста передавать число вторым параметром в функциюp(), как это сделано сейчас в i18n. Но это не менее гибкий вариант и больше ручной работыЕсли код отрефакторили, то делаем попытку определить откуда по параметрам — изменился файл, откуда происходит вызов, но скорее всего исходный параметр остался тем же — вроде
"Hello {$name}". Опять же, показываем диалог: «Это, наверное, перенесенный текст отсюда… Подтвердить?»debug_backtrace()находим файл и номера строк, откуда произошел вызов функции, а затем делаем статический анализ (PhpParser) этих строк, чтобы отделить куски чистого текста от переменных и запомнить имена переменных (для читаемости). я проверил — работаетЕсли придерживаться мнения, что разработка — должна происходить быстро и доставлять удовольствие программисту, то тут — перебор. Программист целых 3 строки будет миллион раз повторять в коде, чтобы сохранить запись. Не говоря уже о читаемости — «persist» переводится как «сохранить», но оно не сохраняет. «flush» переводится как «сбросить», «очистить», но оно сохраняет в базу.
Но это, конечно, holy war. Кому-то нравится программировать, кому-то нравится смотреть на абстракции в коде.
// you can fetch the EntityManager via $this->getDoctrine()
// or you can add an argument to the action: createProduct(EntityManagerInterface $entityManager)
$entityManager = $this->getDoctrine()->getManager();
$product = new Product();
$product->setName('Keyboard');
$product->setPrice(1999);
$product->setDescription('Ergonomic and stylish!');
// tell Doctrine you want to (eventually) save the Product (no queries yet)
$entityManager->persist($product);
// actually executes the queries (i.e. the INSERT query)
$entityManager->flush();