Бюджет: 24140 UAH Термін: 21 день
Здравствуйте, могу выполнить все поставленные задачи в течении 3-х недель. Опыт работы с опенкартом есть. То есть могу реализовать все возможные пожелания, так как есть опыт разработки собственных модулей.
Техническое задание в прикрепленном документе.
Основная задача+
Оглавление
Мультиязычность http://bowtiehouse.ua/
Основная задача
Версии у одной страницы
URLs у разных версий страниц
Шаблон на некоторые HTML-теги у разных версий страниц
Добавление языковых атрибутов
Языковая версия сайта
Валюта
Sitemap.xml
У каждой одной страницы должно быть 3 версии – украинская, английская и русская.
Основная версия должна быть http://domen.ua/ – украинская
Русская версия и английская версии должны предворяться приставкой /ru/ и /en/ соответственно.
Редиректы с tie.com.ua должны идти на /ru/ версию.
При создании новой страницы или при редактировании уже существующей, должна быть возможность ввода данных для каждой версии этой страницы. Т.е. для английской версии, русской и украинской. У каждой страницы должна быть своя вкладка со своими полями для ввода данных (за основу берите уже существующие поля для ввода).
Пример чего мы ожидаем:

Также, необходимо, чтобы при создании новой страницы все заполненные поля или при редактировании существующей страницы отредактированные(ое) поля(е) генерировались автоматически уже переведенными на соответствующем языке на соответствующей версии страницы (т.е. на соответствующей вкладке) через переводчик от Google.
Примечание: поле «SEO URL» должен транслироваться из названия страницы. Для укр. версии он должен сначала перевестись, затем записаться на транслите. Транслит должен работать по национальному стандарту из таблицы, которую можно увидеть тут (где Я я = ya, Ю ю = yu, Й й = i, Ї ї = i, Є є = ie).
Пример для транслита укр. версии:
предположим что на русс. версии название страницы ввелось как «Галстуки», механизм должен сперва обратится к Google переводчику, перевести «Галстуки» на «Краватки», затем транслировать «Краватки» на «kravatki» и затем «kravatki» занести в поле «SEO URL».
В англ. версии страницы слово должно просто переводиться.
Требования к функционалу транслита (к укр. и англ., русс не учитываем т.к. он работает корректно и должен быть перенесен с tie.com.ua):
o После транслитерации все буквы должны иметь нижний регистр;
o Пробелы должны заменяться на дефис;
o Символы . , _ / ( ) : » + * = должны заменяться на дефис;
o Более двух дефисов подряд должны превращаться в один.
Англ. версия и укр. версия должны зависеть от русс. версии (т.е. если русс. корректируем/вводим данные то на англ. и укр. аналогичные поля переводятся/корректируются, если корректируем/вводим данные на укр. или англ. версии страницы – это никак не должно влиять на другие версии страницы). Примечание: если мы вручную указываем новое значение на укр./англ. версии, то при изменении русс. версии – укр./англ. должны остаться без изменений, при условии что размер соответствующего поля > 0.
Например, создаем страницу с категорией «Галстуки»,
На вкладке «Русский» (русс. версия) заполняем поля «Название категории» как «Галстуки», «HTML-тег h1» как «Галстуки в Киеве».
После,
переходим на вкладку «Украинский» (укр. версия)
Поля «Название категории» == «Краватки», «HTML-тег h1» == «Краватки в Києві»
После,
переходим на вкладку English
Поля «Название категории» == «Neckties», «HTML-тег h1» == «Ties in Kiev»
Видим, что переводчик от Google перевел «Галстуки» разными словами, меняем в поле «Название категории» (в котором значение == «Neckties») на «Ties». Сохраняем. Укр. и русс. остались не измененные. Аналогично с укр. версией по отношению к русс. и англ. версиям. Далее, прописали в русс. версии в поле «Название категории» вместо слова «Галстуки» - «Носки», в англ. версии оно осталось со значением «Ties», в укр. версии поменялось на «Шкарпетки». Аналогично, если мы изменим значение и в укр. версии значение поля, то оно не должно измениться (если соблюдено было условие, что длина поля > 0).
Так же у этого функционала должна быть возможность задавать свой личный словарь, т.е. ручной перевод слова. Например, если у нас есть русс. слово «галстуки», и мы указали в словаре, что для укр. версии это «галстуки», то функционал не должен идти в переводчик и вытягивать от туда слово «краватки». Аналогично если мы задали слово и для англ. версии.
У каждой версии одной страницы должен быть разный URL.
1. Укр. версия идет основной и после доменного имени в URL не должна добавляться дополнительная вложенность.
Пример, URL который должен получиться у категории «Метелики» (т.е. бабочек):
домен /категория/ –> http://bowtiehouse.ua/meteliki/
2. У англ. версии после доменного имени в URL должна добавляться дополнительная приставка /en/ после домена.
Пример, URL который должен получиться при входе на главную страницу сайта:
Домен/en/ –> http://bowtiehouse.ua/en/
Пример, URL который должен получиться при входе на страницу «бабочки»:
Домен/en/ –> http://bowtiehouse.ua/en/bowties/
3. У русс. версии после доменного имени в URL должна добавляться дополнительная приставка /ru/ после домена.
Пример, URL который должен получиться при входе на главную страницу сайта:
Домен/ru/ –> http://bowtiehouse.ua/ru/
Пример, URL который должен получиться при входе на страницу «бабочки»:
Домен/ru/ –> http://bowtiehouse.ua/ru/babochki/
На сайте у каждого типа страниц (например: категории, страницы товара, статьи) есть шаблон на теги title, description и h1, который генерирует их автоматически.
Где можно найти шаблон на теги на tie.com.ua:
1. Заходим в админ. панель;
2. Наводим мышью на «Система» и выбираем «Настройки»;
3. Нажимаем на кнопку «Изменить» у «Галстуки и Бабочки - Bow Tie House (По умолчанию)»;
4. Переходим в кладку «Магазин».

Необходимо, что бы у каждой версии группы страниц (например, укр. версия – группа «Категории» или англ. версия – группа «Для товаров») был свой шаблон на теги.
Так как у русс. версии уже есть рабочий шаблон (который должен быть перенесен с tie.com.ua) на все типы страниц, необходимо добавить для укр. версии и для англ. версии.
Возможно, будет удобно данный функционал вынести на отдельную вкладку, где будет возможность выбрать необходимую версию сайта, после, необходимую группу страниц (такие как: категории, страницы товаров, статьи, производителей).
Необходимо вставить в код (в заголовок) каждой версии одной страницы 3 тега link (на каждую версию включая себя) с атрибутами:
· rel="alternate";
· hreflang="тут указываем язык альтернативной страницы" (ru/uk/en);
· href="http://example.com/" – указываем ссылку на альтернативную версию страницы (или на саму себя).
Пример,
есть страница категории бабочек, у нее есть 3 версии:
· http://bowtiehouse.ua/meteliki/ - укр. версия;
· http://bowtiehouse.ua/ru/babochki/ - русс. версия;
· http://bowtiehouse.ua/en/bowties/ - англ. версия.
В коде в разделе <head> у русс., укр. и англ. версиях должно быть:
<link rel="alternate" hreflang="uk" href="http://tie.com.ua/ meteliki/ " />
<link rel="alternate" hreflang="ru" href="http://tie.com.ua/ru/babochki/ " />
<link rel="alternate" hreflang="en" href="http:// tie.com.ua/en/bowties" />
Порядок УРЛов должен быть таков: uk/ru/en.
В интерфейс сайта необходимо добавить 3 кнопки, с помощью которых пользователи смогут переключить языковую версию сайта. Кнопка «нынешней» версии сайта должна быть не кликабельной.
Необходимо чтобы на сайте цены могли отображаться в долларах и в гривнах (на выбор пользователя). По умолчанию должна стоять валюта гривны. Также, нужен функционал, который будет позволять вручную вводить курс доллара и делать автоматический перерасчет цен у всех товаров.
Sitemap.xml для изображений не трогаем. Sitemap.xml для товаров и категорий и статей и для статей блога добавляем следующее из справки Гугл:
Правила для файлов Sitemap:
Указывайте пространство имен xhtml следующим образом:
xmlns:xhtml="http://www.w3.org/1999/xhtml"
Создавайте отдельный элемент <url> для каждого URL.
В каждом элементе <URL> должен быть дочерний элемент <loc>, в котором указывается URL страницы.
В каждом элементе <URL> должен быть дочерний элемент <xhtml:link rel="alternate" hreflang="код языка">, в котором перечисляются все варианты страницы, включая текущую. Справка https://support.google.com/webmasters/answer/189077?hl=ru
Порядок УРЛов должен быть таков: uk/ru/en.
Пример по сайту https://allo.ua :
Бюджет: 24140 UAH Термін: 21 день
Здравствуйте, могу выполнить все поставленные задачи в течении 3-х недель. Опыт работы с опенкартом есть. То есть могу реализовать все возможные пожелания, так как есть опыт разработки собственных модулей.
Є сайт на Wix Studio. На сторінці категорій товарів (динамічна сторінка) на мобільних пристроях з'являються великі білі прогалини між картками товарів коли деякі поля порожні. Картки товарів без даних займають ~1949px висоти на мобільному. Блоки акордеонів ("Склад", "Опис", "Технічні характеристики") резервують великий порожній простір навіть коли даних немає. Блок з галереєю фото також створює великий білий розрив коли фото немає. Що потрібно зробити: Коли поля "Склад", "Опис", "Технічні характеристики" порожні в CMS — заголовки акордеонів повинні залишатися видимими, але порожній простір всередині не повинен резервуватися Коли фото немає - блок галереї не повинен створювати великий білий розрив Виправлення повинно працювати на всіх сторінках категорій, не тільки на одній Важливо: Заголовки розділів ("Склад", "Опис" тощо) повинні залишатися видимими завжди. Прибрати потрібно лише порожній білий простір всередині.
Є сайт на Wix Studio. На сторінці категорій товарів (динамічна сторінка) на мобільних пристроях з'являються великі білі прогалини між картками товарів коли деякі поля порожні. Картки товарів без даних займають ~1949px висоти на мобільному. Блоки акордеонів ("Склад", "Опис", "Технічні характеристики") резервують великий порожній простір навіть коли даних немає. Блок з галереєю фото також створює великий білий розрив коли фото немає. Що потрібно зробити: Коли поля "Склад", "Опис", "Технічні характеристики" порожні в CMS — заголовки акордеонів повинні залишатися видимими, але порожній простір всередині не повинен резервуватися Коли фото немає - блок галереї не повинен створювати великий білий розрив Виправлення повинно працювати на всіх сторінках категорій, не тільки на одній Важливо: Заголовки розділів ("Склад", "Опис" тощо) повинні залишатися видимими завжди. Прибрати потрібно лише порожній білий простір всередині.
Я професійний 3D-дизайнер, створюю високодеталізовані рендери пам'ятників і меморіальних комплексів (вертикальний формат 9:16). Мої клієнти — це власники цехів і майстерень, яким потрібен зручний цифровий каталог моїх макетів для показу своїм роздрібним покупцям. Що мені потрібно: Підібрати оптимальну платформу і зібрати легкий, швидкий веб-додаток (каталог), який буде ідеально виглядати на смартфонах і коректно відкриватися на комп'ютерах. Ключові вимоги до каталогу: Дизайн: Максимальний мінімалізм. Темна тема (чорний фон), велике вертикальне зображення (пропорції 9:16), під ним тільки назва/артикул макета. Жодних довгих описів. Управління базою: Мені потрібна максимально проста система додавання нових макетів (ідеально — через звичні Google Таблиці або дуже зручну внутрішню БД). Я повинен просто завантажити зображення і вписати артикул, не ламаючи верстку. Інтеграція до клієнтів (Найважливіше): Каталог повинен легко впроваджуватися на сайти моїх замовників-цехівників (в когось WordPress, в когось самопис). Потрібно продумати елегантний спосіб вбудовування: через Iframe (щоб каталог працював прямо всередині їхньої сторінки) або через правильну настройку кнопки-посилання. Що я вже пробував: Тестував Glide і Adalo. В Adalo вийшов потрібний візуал (9:16 на чорному фоні), але управління внутрішньою базою даних і возня зі посиланнями на Google Диск виявилися занадто незручними для постійної роботи. Плюс є сумніви щодо правильного вбудовування Iframe в чужі сайти так, щоб він не роз'їжджався на широких моніторах. Від вас чекаю у відповіді: На якій платформі (Adalo, Glide, Bubble, Webflow, Glide + Airtable або щось інше) ви пропонуєте це реалізувати і чому? Як буде вирішено питання з зберіганням важких зображень (рендерів)? Як ви пропонуєте технічно вбудовувати цей каталог на сторонні сайти моїх клієнтів? Шукаю спеціаліста, який закриє цю технічну проблему під ключ, щоб я міг спокійно займатися 3D-моделюванням.
Сайт вже запущений і працює. Основне завдання — розібратися в поточній структурі проєкту, перевірити якість реалізації, виправити знайдені технічні проблеми та допомогти з подальшими змінами.Основний стек Next.js 15 React 19 TypeScript Tailwind CSS Zod Redux Toolkit В проєкті також можуть використовуватися: Prisma JWT-авторизація Stripe Mailgun Google APIs Vercel або Netlify FunctionsОсновні завдання провести ревізію існуючого проєкту; оцінити структуру та якість коду; виправляти помилки та доопрацьовувати поточний функціонал; покращувати серверний рендеринг і швидкість завантаження сторінок; перевіряти коректність відображення сайту на мобільних пристроях; працювати з формами, адміністративною частиною та зовнішніми інтеграціями; вносити технічні SEO-зміни; підтримувати і поступово покращувати існуючий сайт.Що для нас важливо добрий досвід роботи з Next.js, React та TypeScript; уміння розбиратися в чужому коді; розуміння SSR та особливостей Next.js App Router; уважність до продуктивності та якості реалізації; уміння пояснювати знайдені проблеми та пропонувати зрозумілі рішення; самостійність та акуратна робота з діючим сайтом. На першому етапі необхідно ознайомитися з проєктом, провести технічну ревізію та запропонувати список пріоритетних змін. Після цього можлива постійна робота над подальшим розвитком сайту.
Шукаємо досвідченого Embedded-розробника для створення енергоефективної прошивки під носимий пристрій (форм-фактор: нагрудний ремінь) для моніторингу психофізіологічного стану. Проектування схеми завершено, розробка буде вестися на базі налагоджувальної плати (Development Kit) з подальшим перенесенням на кастомну плату.Стек і апаратна база:MCU: Nordic Semiconductor nRF52840 або nRF5340.Середа розробки: nRF Connect SDK / Zephyr RTOS (строго Сі/C++).Периферія:Оптичний датчик пульсу (PPG) — робота по I2C.6-осевий інерційний датчик (IMU акселерометр + гіроскоп) — робота по SPI.Драйвер тактильного мотора (LRA 1030) — управління через PWM/ШИМ.Зовнішня SPI Flash-пам'ять для циклічного логування.Обсяг роботи по етапахЕтап 1: Bring-up, драйвери периферії і BLE-телеметріяМета: Оживити залізо, налаштувати стабільний збір даних і їх передачу на смартфон/ПК.Налаштування роботи шин I2C і SPI з використанням DMA (Direct Memory Access) для розвантаження процесора.Написання/інтеграція драйверів для PPG і IMU (налаштування частоти опитування, FIFO-буферів датчиків).Розгортання кастомного BLE-профілю (GATT-сервіс) для передачі сирих даних з датчиків в реальному часі.Базова ініціалізація ШИМ для управління тактильним LRA-мотором (запуск тестових патернів вібрації).Етап 2: Алгоритмічний шар (DSP і багаторівнева логіка зворотного зв'язку)Мета: Реалізувати математичну обробку сигналів безпосередньо на чипі (Edge Computing) і логіку реакцій пристрою.Реалізація алгоритмів фільтрації артефактів руху: очищення сигналу PPG з використанням даних акселерометра (IMU).Виділення R-R інтервалів (HRV) з очищеного PPG-сигналу.Реалізація 4-рівневої логіки стійкості системи:Рівень Дрейфа: Відстеження плавного зміни HRV і дихання.Рівень Прогнозу: Обчислення математичного тренду на погіршення стану.Рівень Мікро-корекції: Генерація ледь помітних тактильних патернів на LRA-моторі при фіксації цільового патерну даних.Рівень Апаратного скидання: Реалізація логіки безпеки (високоінтенсивний тактильний імпульс при критичних показниках).Етап 3: Енергозбереження, логування і відмовостійкістьМета: Підготовка пристрою до автономної роботи від мініатюрного акумулятора і забезпечення стабільності «24/7».Глибока оптимізація енергоспоживання. Переведення MCU в режим сну (System ON/OFF) між тактами вимірювань. Процесор повинен прокидатися тільки за перериваннями від FIFO-буферів датчиків або таймера.Написання відмовостійкої файлової системи у зовнішній SPI Flash (наприклад, LittleFS) для автономного циклічного збереження логів.Налаштування апаратного сторожового таймера (Watchdog Timer) для запобігання зависанню прошивки.Вимоги до виконавця:Досвід комерційної розробки під чіпи Nordic (nRF52/nRF53) від 3 років.Впевнене володіння Zephyr RTOS і інструментами налагодження (Segger Embedded Studio / VS Code, J-Link).Розуміння принципів роботи цифрової фільтрації сигналів (DSP) і роботи з низьким енергоспоживанням (Low-Power дизайн).Наявність власного налагоджувального комплекту (nRF52840-DK або аналогічного) для старту роботи вітається.Формат роботи:Поетапна оплата (Milestones) з фіксацією результатів на GitHub. Будь ласка, вкажіть вашу погодинну ставку або приблизну оцінку вартості і термінів для кожного з трьох етапів.