Budżet: 24140 UAH Termin: 21 dni
Здравствуйте, могу выполнить все поставленные задачи в течении 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 :
Budżet: 24140 UAH Termin: 21 dni
Здравствуйте, могу выполнить все поставленные задачи в течении 3-х недель. Опыт работы с опенкартом есть. То есть могу реализовать все возможные пожелания, так как есть опыт разработки собственных модулей.
Opracowanie aplikacji Power App, wsparcie mnie jako nowicjusza. Canvas App, pomoc w opracowaniu ekranu Pomoc w opracowaniu struktury danych dla aplikacji Programowanie funkcji Pomoc w tworzeniu tabel Date-verse
Szukamy doświadczonego dewelopera Shopify do stworzenia pełnoprawnego sklepu internetowego od podstaw z obowiązkową integracją z Amazon. Co należy zrobić: Integracja z Amazon jako podstawa projektu: synchronizacja produktów, stanów magazynowych i zamówień między Shopify a kontem sprzedawcy na Amazon. Ustawienia sklepu są budowane z uwzględnieniem tej integracji od samego początku. Ustawienia sklepu: dostosowanie motywu, struktura katalogu, karty produktów, koszyk, składanie zamówienia — wszystko jest zgodne z logiką integracji z Amazon. Optymalizacja techniczna dla widoczności AI (GEO): dane strukturalne, plik llms.txt, optymalizacja treści pod odpowiedzi asystentów AI (ChatGPT, Perplexity, AI Overviews itp.), poprawne semantyczne oznaczenie stron. Podstawowe ustawienia SEO: metatagi, mapa strony, szybkość ładowania, responsywność mobilna. Podłączenie systemów płatności. Instalacja niezbędnych aplikacji (opinie, email marketing, analityka itp.). Testowanie sklepu przed uruchomieniem.
Potrzebna pomoc w przemyśleniu i zbudowaniu czystiej schemy relacyjnej dla wewnętrznego systemu operacyjnego w Airtable. Obecna baza jest już używana przez zespół, ale rozwinęła się organicznie: struktura jest częściowo płaska, część tabel/widoków jest używana aktywnie, część prawie nie jest używana, a dokumenty teraz raczej "ciągną" informacje do Airtable, chociaż w idealnym przypadku Airtable powinno stać się źródłem prawdy i generować potrzebne artefakty operacyjne. Potrzebna jest nie tylko pomoc w formularzach czy automatyzacjach, ale przede wszystkim praca strukturalna: analiza obecnej logiki, projektowanie schemy relacyjnej, stworzenie czystej nowej bazy/instancji, dokumentacja oraz rekomendacje dotyczące migracji do nowej schemy. I potencjalnie możliwe nawet wdrożenie Kontekst systemu: Są dwa główne kierunki: System feedbackowy System do zbierania i przetwarzania sygnałów od zewnętrznych doradców, grup fokusowych, wewnętrznych zespołów oraz interesariuszy. Musi wspierać: rejestr sygnałów; śledzenie doradców; przyjmowanie feedbacku; panel syntezujący; statusy / bramki / rekomendacje; logikę zamykania pętli. Katalog produktów W katalogu produktów jest obecnie około 400 wpisów, z czego około 100 jest aktywnych/na żywo. Należy lepiej zorganizować produkty, statusy, powiązania, źródła danych, logikę cyklu życia/bramki oraz raportowanie. Obecny stan: Airtable już istnieje i jest używane przez zespół. Obecna dokładność danych wynosi około 80%. Schemat jest głównie płaski, nie relacyjny. Aktywnie używane są tylko pierwsze kilka tabel/zakładek: Część bramek walidacyjnych, zadań/decyzji i widoków panelu jest na razie prawie nieużywana. Nie ma PII. Jakakolwiek praca z bazą na żywo musi być maksymalnie ostrożna: bez zmian w produkcji bez zgody. Idealne podejście to analiza struktury i budowa nowej czystej bazy osobno w Sandboxie. Co należy zrobić: Faza 1 — Audyt i rekomendacja architektury Przyjrzeć się obecnej strukturze Airtable. Określić, które tabele/pola/widoki są naprawdę potrzebne, które się powtarzają, które można połączyć lub usunąć. Proponować model danych relacyjnych. Opisać główne encje, relacje, klucze główne, powiązane rekordy, logikę wyszukiwania/rolowania. Proponować czystą schemę dla Projektu + Katalogu produktów. Określić, jakie panele/interfejsy są potrzebne dla różnych użytkowników. Przygotować krótką notatkę architektoniczną lub mapę schemy. Faza 2 — Budowa czystej bazy Airtable Stworzyć nową czystą bazę Airtable / instancję. Skonfigurować tabele, pola, powiązane rekordy, widoki, podstawowe interfejsy. Skonfigurować podstawową logikę panelu/raportowania. Przygotować mapę migracji: jak przenosić dane ze starej struktury do nowej. Udokumentować strukturę tak, aby zespół mógł ją wspierać po przekazaniu. W razie potrzeby — zaproponować strategię automatyzacji, ale bez nadmiernej złożoności. Oczekiwane rezultaty: Mapa schemy Airtable. Nowa czysta baza Airtable. Tabele + relacje + kluczowe pola. Widoki/interfejsy dla głównych użytkowników. Rekomendacja migracji. Krótką dokumentację dla zespołu. Rekomendacje dotyczące zarządzania: kto wprowadza dane, kto zatwierdza zmiany, które pola są obowiązkowe, jak unikać duplikacji. Opcjonalnie: 1 krótka rozmowa przekazująca / przejście przez Loom. Ważne zasady dotyczące bezpieczeństwa / dostępu: Bez PII. Bez niebezpiecznych tokenów lub osobistych integracji. Nie można podłączać AI/MCP/ChatGPT/Claude do bazy Airtable na żywo. Jeśli potrzebny jest dostęp do istniejącej bazy, musi być tylko do odczytu lub przez eksport/zrzuty ekranu/opis strukturalny. Jakiekolwiek zapisy/zmiany są dokonywane tylko w nowej testowej/czystej bazie, nie w produkcji na żywo. Kogo szukam: Idealny kandydat ma doświadczenie: w architekturze bazy Airtable; w projektowaniu schem relacyjnych; w interfejsach Airtable, widokach, formularzach, automatyzacjach; w migracji/oczyszczaniu chaotycznych baz Airtable; w operacjach produktowych / CRM / systemach workflow; w dokumentacji i przekazywaniu. W odpowiedzi proszę podać: Przykłady baz Airtable lub systemów, które budowałeś. Czy miałeś doświadczenie w przekształcaniu płaskiej struktury Airtable w schemę relacyjną. Jak podszedłbyś do audytu → projektowania schemy → budowy. Orientacyjną ocenę godzin dla Fazy 1. Twoją stawkę godzinową lub ofertę stałą na pierwszy etap. Czy jesteś gotów pracować na podstawie NDA. Format pracy: Rozpoczęcie najlepiej w najbliższym czasie. Na początku można przeprowadzić niewielkie płatne odkrycie/audyt, po czym przejść do pełnej budowy.