- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee
Никогда не пользовался разными CMS и не собираюсь. Зачем мне эти тормознутые монстры, да и все равно пришлось бы дорабатывать под свои проекты.
Не зарекайтесь ;) Каждый инструмент служит своим задачам. До и пользоваться надо уметь инструментом. У меня тот же Битрикс не тормозит. Выбор надо делать трезво, нафига делать свои велосипеды если есть некий инструмент, который покрывает задачу в очень заметной степени - это позволяте сконцентрироваться на том функционале, который для проект является дейстивтельно уникальным.
Еще в 2005 определился со своим движком, 2 или 3 раза переделывал только функциональность за все время (логика оставалась).
Ну у меня свой движок просуществовал 15 лет, потом надоело тратить время на то, что понятно как делать, делать не интересно (Есть более интересные задачи).. Я плюнул на него и совершенно не жалею. Есть у меня, например, мой личный проект, там работы оверхдохрена, нафиг мне отвлекаться на типовой функционал? Или, как пример, как появился закон о кассах, - самому пилить интеграцию... да и те же эквайринговые сервисы интегрировать. я в этом году несколько сервисов перепробовал (в связи с трудностями приема оплаты из за рубежа).. сам бы на это кучу времени потратил....
в общем нет.. пока речь идет о блоге или о чем то простом, в конце концов пока создание этого ядра прокачивает скилы, или является интересной задачей - да хороший проект.... а потом надоедает.
Я конечно не агитирую, просто свое мнение высказал :)
Это принципиально не отличается от перевода всего остального. В том числе и меню.
Заблуждение :)
Строго говоря до недавнего времени мне было пофиг, ну принято так (в файлах) и принято. А тут проект один стал требовать периодически принимать свыше 150К активных пользователей в день (при чем не размыто на дню, а с пиком ярким) - и к некоторым вопросам (которые казались мелочами) стал несколько по другому смотреть.
Мне интересен перевод определенного интерфейса, который будет очень редко, практически никогда меняться. Для этого использовать БД нецелесообразно.
Ну если речь идёт о переводе элементов, которые не хранятся в БД, то самое простое - это подключение языкового файла, который содержит варианты фраз на разных языках или подключение языкового файла в зависимости от выбранного языка.
К примеру, на PHP, если есть шаблон template.php, то делаем include 'lang.php', и в этом lang.php лежит массив с разными вариантами. Другой вариант решения - подключаем, в зависимости от языка, файлы /langs/en.php, /langs/pl.php, /langs/ru.php, и т.п.
Второй вариант используется чаще, кмк. Потому что удобнее масштабировать.
Интересует тоже мультиязычность, у меня много бурж разного трафика что можете посоветовать?
Можем посоветовать не влезать в чужие темы с дурацкими вопросами, а создавать свою, с чётким и понятным описанием проблемы.
Интересует тоже мультиязычность, у меня много бурж разного трафика что можете посоветовать?
Тут уже много ответов. Уточняй, какие вопросы возникли