Скорее всего, ты прав, и я прошу прощения за навязчивость
Я действительно делюсь этим, чтобы напомнить о лучших практиках, которые часто игнорируют. Конечно, я также хочу рассказать о своем решении и получить обратную связь. Спасибо за твои замечания, они действительно помогают проекту расти. Я учел все важные моменты
Этот проект появился потому, что я был недоволен тем подходом, который ты описываешь. На мой взгляд, централизация контента является критической проблемой. Она раздувает бандл приложения и провоцирует конфликты при слиянии веток. Управление неймспейсами и поиск неиспользуемых строк в i18next, next-intl или vue-i18n часто превращаются в настоящий ад. Я хотел создать инструмент, который сам мечтал бы иметь под рукой
При этом я понимаю, что это решение подойдет не каждому. У меня нет цели переписывать i18next, ведь он и так отлично справляется со своими задачами.
Буду рад продолжить общение. Пиши мне в любое время, где тебе удобно
Действительно, @intlify/unplugin-vue-i18n позволяет решать ту же проблему. Ограничение в том, что тебе приходится для каждой страницы вручную определять, какие namespaces нужно загружать.
Я попробовал бандлер Bun, и там нет опции bundle: false, из-за чего возникают ошибки с next-intlayer Если указать несколько точек входа, расширения не разрешаются. Я был бы очень рад перейти на их бандлер, но он всё ещё на очень ранней стадии. Поэтому я остаюсь с бандлером на основе esbuild
И я доволен Vitest, не хочу переносить все тесты своего кода
Я не поклонник Husky, но проверки перед коммитом, это действительно большое преимущество при создании open-source проекта с участием других разработчиков.
Твой комментарий вполне уместен. И действительно, если интеграция решения для i18n с Crowdin является для тебя критерием выбора, то думаю, Intlayer не самое подходящее решение.
Целевая аудитория Intlayer, это в основном личные проекты или небольшие проекты / SaaS. Смысл в том, чтобы ускорить разработку, и для таких случаев добавление отдельной платформы локализации часто считается избыточными расходами. Для банков или крупных компаний лучше оставаться на классических решениях.
Но я отметил, что для тебя критичен Crowdin. Я добавил в дорожную карту задачу, предложить такую интеграцию в виде плагина
Для людей без технических навыков, например переводчиков или маркетологов, мы предлагаем CMS, чтобы им не приходилось работать с Git и прочими инструментами разработчиков.С помощью этой системы они могут легко понимать, над каким проектом работают, какие переводы отсутствуют или ещё должны быть сделаны.Также есть возможность автоматически сгенерировать перевод с помощью кнопки, использующей ИИ и учитывающей контекст, чтобы получать более качественные переводы для каждого словаря.Если используется ключ, который должен быть общим, можно создать общий словарь и вызывать этот ключ именно из него.
Ты совершенно прав! Многое ещё нужно оптимизировать. Так как 90% посещений приходится на десктоп, я едва уделил время проверке работы на мобильных устройствах. Добавлю это в дорожную карту
Перевод на русский с исправлениями и улучшением читаемости:
Спасибо за твое сообщение!
И также спасибо за сообщение о проблеме со стилями в Firefox – я скоро постараюсь это исправить.
Редактор и клиентское приложение (встроенное в iframe) взаимодействуют между собой с помощью window.postMessage(). Из соображений безопасности соединение должно устанавливаться в строго определённом порядке. Иногда это может приводить к ошибке: "Failed to execute ‘postMessage’ on ‘DOMWindow’". Я продолжаю совершенствовать систему, чтобы устранить такие проблемы, хотя они порой трудно выявляются.
Что касается сохранения – оно намеренно отключено в playground. Чтобы полноценно воспользоваться функционалом, я рекомендую ознакомиться с этим шаблоном, основанным на Intlayer: 🔗 intlayer-vite-react-template
Установка и запуск
git clone git@github.com:aymericzip/intlayer-vite-react-template.git
cd ./intlayer-vite-react-template
npm i
npm run dev
npx intlayer-editor start
У тебя есть пример реализации, которым ты можешь поделиться? Мне любопытно
Скорее всего, ты прав, и я прошу прощения за навязчивость
Я действительно делюсь этим, чтобы напомнить о лучших практиках, которые часто игнорируют. Конечно, я также хочу рассказать о своем решении и получить обратную связь. Спасибо за твои замечания, они действительно помогают проекту расти. Я учел все важные моменты
Этот проект появился потому, что я был недоволен тем подходом, который ты описываешь. На мой взгляд, централизация контента является критической проблемой. Она раздувает бандл приложения и провоцирует конфликты при слиянии веток. Управление неймспейсами и поиск неиспользуемых строк в i18next, next-intl или vue-i18n часто превращаются в настоящий ад. Я хотел создать инструмент, который сам мечтал бы иметь под рукой
При этом я понимаю, что это решение подойдет не каждому. У меня нет цели переписывать i18next, ведь он и так отлично справляется со своими задачами.
Буду рад продолжить общение. Пиши мне в любое время, где тебе удобно
Загружается с моей стороны, возможно, проблема на вашей стороне? Правила DNS?
Лучше всего попробовать на практике. Обращайтесь, если появятся вопросы
Действительно, @intlify/unplugin-vue-i18n позволяет решать ту же проблему. Ограничение в том, что тебе приходится для каждой страницы вручную определять, какие namespaces нужно загружать.
Забыл подключить компонент -> приложение падает
Забыл удалить неиспользуемый namespace -> засоряешь страницу ненужным контентом
Подход, предлагаемый Intlayer, позволяет автоматизировать очистку, без необходимости вручную перечислять namespaces для импорта или удаления.
Поскольку страницы часто дублируются или компоненты перемещаются, я не считаю unplugin-vue-i18n правильным подходом для использования.
(Поправьте меня, если я ошибаюсь)
Я попробовал бандлер Bun, и там нет опции
bundle: false, из-за чего возникают ошибки с next-intlayerЕсли указать несколько точек входа, расширения не разрешаются.
Я был бы очень рад перейти на их бандлер, но он всё ещё на очень ранней стадии.
Поэтому я остаюсь с бандлером на основе esbuild
И я доволен Vitest, не хочу переносить все тесты своего кода
Спасибо
Спасибо, я посмотрю. Надеюсь, что установить будет проще, чем Bun
Я не поклонник Husky, но проверки перед коммитом, это действительно большое преимущество при создании open-source проекта с участием других разработчиков.
Твой комментарий вполне уместен. И действительно, если интеграция решения для i18n с Crowdin является для тебя критерием выбора, то думаю, Intlayer не самое подходящее решение.
Целевая аудитория Intlayer, это в основном личные проекты или небольшие проекты / SaaS. Смысл в том, чтобы ускорить разработку, и для таких случаев добавление отдельной платформы локализации часто считается избыточными расходами. Для банков или крупных компаний лучше оставаться на классических решениях.
Но я отметил, что для тебя критичен Crowdin. Я добавил в дорожную карту задачу, предложить такую интеграцию в виде плагина
Для людей без технических навыков, например переводчиков или маркетологов, мы предлагаем CMS, чтобы им не приходилось работать с Git и прочими инструментами разработчиков.С помощью этой системы они могут легко понимать, над каким проектом работают, какие переводы отсутствуют или ещё должны быть сделаны.Также есть возможность автоматически сгенерировать перевод с помощью кнопки, использующей ИИ и учитывающей контекст, чтобы получать более качественные переводы для каждого словаря.Если используется ключ, который должен быть общим, можно создать общий словарь и вызывать этот ключ именно из него.
Sorry for the inconvenience. Your remark makes sense. This article has indeed been translated. I will publish my next articles in English 🙏
Ты совершенно прав! Многое ещё нужно оптимизировать. Так как 90% посещений приходится на десктоп, я едва уделил время проверке работы на мобильных устройствах. Добавлю это в дорожную карту
Я буду работать над этим. На что именно ты ссылаешься?
Перевод на русский с исправлениями и улучшением читаемости:
😅😅
Перевод на русский с исправлениями и улучшением читаемости:
Спасибо за твое сообщение!
И также спасибо за сообщение о проблеме со стилями в Firefox – я скоро постараюсь это исправить.
Редактор и клиентское приложение (встроенное в iframe) взаимодействуют между собой с помощью window.postMessage().
Из соображений безопасности соединение должно устанавливаться в строго определённом порядке. Иногда это может приводить к ошибке:
"Failed to execute ‘postMessage’ on ‘DOMWindow’".
Я продолжаю совершенствовать систему, чтобы устранить такие проблемы, хотя они порой трудно выявляются.
Что касается сохранения – оно намеренно отключено в playground.
Чтобы полноценно воспользоваться функционалом, я рекомендую ознакомиться с этим шаблоном, основанным на Intlayer:
🔗 intlayer-vite-react-template
Установка и запуск
Если появятся вопросы, не стесняйся спрашивать!
Спасибо за замечание.
Действительно, одновременно работают два приложения:
Клиентское приложение: http://localhost:3000
Редактор: http://localhost:8000
Эти URL-адреса можно изменить и даже направить на приложение, размещенное на удаленном домене, например: https://example.com
Спасибо большое, что обратили на это внимание. Ссылка только что была исправлена