Программа умеет следить за изменениями лога. Я могу просто выбрать ссылку или IP из списка и наблюдать за тем, что происходит в данный момент. Для этой задачи можно использовать множество других инструментов, но обычно это занимает у меня гораздо больше времени.
Я когда-то для себя писал консольную утилиту: https://github.com/s00d/logutil Она нужна для парсинга логов nginx (в теории можно настроить на другие логи через регулярку), группирует по запросам и прочее. Иногда помогает.
Если проект не требует сложной интернационализации.
Это утверждение требует уточнения, поскольку уже сейчас создаются очень сложные и масштабные проекты, где часть функционала реализована иначе. Такие проекты могут включать более сложные подходы к интернационализации, которые уже не ограничиваются базовыми решениями.
Единственное, что я не стал реализовывать, — это динамическая загрузка переводов. Я много работал с этим в nuxt-i18n и пришёл к выводу, что она приносит больше проблем, чем пользы. Возможно, в будущем я добавлю какой-то аналог, но пока у меня нет интересной идеи для реализации этого функционала, я не планирую за него браться.
В общем, если вы, как и я, устали от бесконечных проблем с nuxt-i18n, то можете попробовать моё решение.
Спасибо, поправил, но тут не только время сборки, также время запуска в dev режиме тоже значительно лучше.
Закачивать сразу все языки это беда. У нас 32 языка и около 16 тысяч статических переводов. Даже json одного языка со всеми переводами грузится долго. В итоге начал подгружать только нужные.
Это была основная причина, по которой я решил заняться этим проектом. В тестах представлены примеры проектов с моим модулем и с nuxt-i18n, и разница действительно огромная. Вы можете сами убедиться в этом, проведя проверку. Я устал ждать и решил попробовать другой подход — и, похоже, что-то получилось.
Жесткий роутинг на языках создаёт большую таблицу - роутов. Потому бывает проще в больших приложениях префикс убрать. Потому все не однозначно.
Здесь начинается самое интересное. Я выбрал совершенно иной подход к формированию роутов — regexp-ротинг. Вместо создания отдельного роута для каждой локали, добавляется всего один дополнительный роут. Это означает, что если у вас есть 10 страниц и 30 локалей, итоговое количество роутов составит всего 20, а не 300, как это было бы в стандартной реализации.
Но это еще не всё. К сожалению, сам Vue Router не отличается высокой скоростью. По умолчанию мой модуль добавляет каждую локаль в регулярное выражение, что снижает RPS (запросов в секунду). Чтобы решить эту проблему, я добавил настройку customRegexMatcher, которая позволяет полностью контролировать процесс обработки регулярных выражений и избавляться от лишних нагрузок. К сожалению с кастомными роутами проблема осталась, я пытался ее как-то решить, но пока не смог.
Этот подход значительно оптимизирует работу приложения и особенно полезен для крупных проектов.
Не понял в статье - как собрать разметку всех статических переводов в проекте в json?
Не совсем понял, что вы имеете в виду под "разметкой статических переводов". Если речь идет просто о тексте, то такого нет. Мой CLI позволяет искать ссылки на переводы и формировать из них JSON. Также, например, он умеет синхронизировать несколько JSON-файлов на разных локалях между собой. Если я правильно понял, идея с поиском текста на странице действительно интересная, но её реализация довольно сложная.
Очень долго искал что-то похожее. Перерыл половину гитхаба, пытался сам сделать что-то похожее. Жаль что не видел ваш код. Советую в гите, в описании всегда писать что-то такое vue input mask component, сейчас найти ваши компоненты очень сложно. также очень не хватает keywords в package.json, все это упростило бы поиск в несколько раз.
Спасибо за подобную работу, надеюсь хоть у вас все будет работать. Год назад я потратил больше недели из-за большого количества конфликтов у подобных компонентов. К примеру все проверенные мной input mask компоненты, конфликтовали с draggable, браузер просто зависает. Мой ишью висит уже больше года, но видимо все и так хорошо.
Программа умеет следить за изменениями лога. Я могу просто выбрать ссылку или IP из списка и наблюдать за тем, что происходит в данный момент. Для этой задачи можно использовать множество других инструментов, но обычно это занимает у меня гораздо больше времени.
Я когда-то для себя писал консольную утилиту: https://github.com/s00d/logutil Она нужна для парсинга логов nginx (в теории можно настроить на другие логи через регулярку), группирует по запросам и прочее. Иногда помогает.
Добавил поддержку стратегий, теперь по идее можно использовать и no_prefix
Изначально это был мой план, но со временем проект значительно расширился. Автоматическое переключение языка и маршрутизация были реализованы давно. Я активно продолжаю развивать проект: например, вчера добавил инструмент для тестирования через vitest, а также внедрил серверный перевод. Все это уже есть в документации.
Это утверждение требует уточнения, поскольку уже сейчас создаются очень сложные и масштабные проекты, где часть функционала реализована иначе. Такие проекты могут включать более сложные подходы к интернационализации, которые уже не ограничиваются базовыми решениями.
Единственное, что я не стал реализовывать, — это динамическая загрузка переводов. Я много работал с этим в nuxt-i18n и пришёл к выводу, что она приносит больше проблем, чем пользы. Возможно, в будущем я добавлю какой-то аналог, но пока у меня нет интересной идеи для реализации этого функционала, я не планирую за него браться.
В общем, если вы, как и я, устали от бесконечных проблем с nuxt-i18n, то можете попробовать моё решение.
Спасибо, поправил, но тут не только время сборки, также время запуска в dev режиме тоже значительно лучше.
Это была основная причина, по которой я решил заняться этим проектом. В тестах представлены примеры проектов с моим модулем и с nuxt-i18n, и разница действительно огромная. Вы можете сами убедиться в этом, проведя проверку. Я устал ждать и решил попробовать другой подход — и, похоже, что-то получилось.
Здесь начинается самое интересное. Я выбрал совершенно иной подход к формированию роутов — regexp-ротинг. Вместо создания отдельного роута для каждой локали, добавляется всего один дополнительный роут. Это означает, что если у вас есть 10 страниц и 30 локалей, итоговое количество роутов составит всего 20, а не 300, как это было бы в стандартной реализации.
Но это еще не всё. К сожалению, сам Vue Router не отличается высокой скоростью. По умолчанию мой модуль добавляет каждую локаль в регулярное выражение, что снижает RPS (запросов в секунду). Чтобы решить эту проблему, я добавил настройку customRegexMatcher, которая позволяет полностью контролировать процесс обработки регулярных выражений и избавляться от лишних нагрузок. К сожалению с кастомными роутами проблема осталась, я пытался ее как-то решить, но пока не смог.
Этот подход значительно оптимизирует работу приложения и особенно полезен для крупных проектов.
Не совсем понял, что вы имеете в виду под "разметкой статических переводов". Если речь идет просто о тексте, то такого нет. Мой CLI позволяет искать ссылки на переводы и формировать из них JSON. Также, например, он умеет синхронизировать несколько JSON-файлов на разных локалях между собой. Если я правильно понял, идея с поиском текста на странице действительно интересная, но её реализация довольно сложная.
Спасибо за подобную работу, надеюсь хоть у вас все будет работать. Год назад я потратил больше недели из-за большого количества конфликтов у подобных компонентов. К примеру все проверенные мной input mask компоненты, конфликтовали с draggable, браузер просто зависает. Мой ишью висит уже больше года, но видимо все и так хорошо.