Ответы в темах

Просмотр 15 ответов — с 1 по 15 (всего 36)
  • email — почта
    to email — отправить почтой/на почту

    Предлагаю, наконец, выработать рекомендацию по переводу «email» на русский язык. Вопрос наболевший, возникал неоднократно. Сейчас консистенности нет совсем, встречаются аж 12 (!) вариантов (рассмотрены ниже).

    Нюансы:
    — «Email» часто используется в лейблах форм и прочих местах, поэтому длина перевода может быть критичной.
    — Изредка слово используется как глагол («Please, email me at hello@example.com»).
    — Встречается в контексте «email address», что создаёт тавтологию для той части вариантов, где уже участвует слово «адрес».

    Тема подразумевает два отдельных самостоятельных вопроса:
    1. Нужно ли вообще переводить слово email.
    2. Если переводить, то как конкретно.

    Нужно ли переводить

    На мой взгляд, нужно. Понятие электронной почты общеизвестно. С ним так или иначе знаком примерно каждый первый пользователь интернета. То есть она уже давно перестала быть узким заимствованием. Слово «email» составлено из двух частей, которые имеют прямое соответствие в русском языке («электронный» и «почта»). То есть с чисто языковой точки зрения я не вижу ни одной причины оставлять английское слово.

    Что касается пользовательских привычек. В ходе одного из прошлых обсуждений мы выяснили, что многие массовые сервисы в последние годы тоже начали это слово переводить. В частности, Майкрософт, Мозилла, Яндекс (в основных экранах авторизации и в саппорте), Гугл (аналогично в авторизации и саппорте), Фейсбук.Понятия «электронная почта» и «электронное письмо» официально входят в словари: пример раз, пример два. Русская «Википедия» перенаправляет запрос «email» на страницу «Электронная почта».

    Что характерно, в непереведённом виде «email» встречается обычно в старых интерфейсах и сервисах, тогда как в более свежих оно уже переведено. Таким образом, с точки зрения UX тоже нет никаких проблем — можно смело переводить.

    Варианты перевода

    Тут могут быть разные мнения. Я за самый простой (и наглый 🙂 вариант:
    существительное email — «почта»;
    глагол to email — «отправить почтой», «отправить на почту», «выслать почтой».

    Главный контраргумент: будут путать с обычной бумажной почтой. Но я считаю, что в подавляющем большинстве случаев (абсолютно подавляющем), разница очевидна из контекста. WordPress — электронный продукт. Бумажная почта фигурирует в переводах крайне редко. И почти всегда в очевидном контексте адресной доставки товаров (в таких формах всегда есть узнаваемые элементы: город, почтовый код, пример адреса с улицей и т.п.). Спутать их невозможно. И даже в экстремальных случаях переводчик конкретного интерфейса всегда может явно прописать, что речь идёт о физической доставке. То есть для основной массы переводов «почта» по умолчанию именно электронная. Уточнять имеет смысл только в конкретных частных случаях, и это происходит чрезвычайно редко. Т.о. слова «почта» вполне достаточно.

    Компромиссный вариант: использовать «электронная почта» в длинных строках и короткую форму «почта» там, где место сильно ограничено.

    Недостатки прочих вариантов:

    «Адрес электронной почты» — избыточно, не везде влезет.
    «Емейл» — калька довольно бессмысленная, «ни вашим, ни нашим»; фонетически неточная, для разговорной тоже не тянет, т.к. люди очень по-разному произносят «имейл», «мейл», «мыло» и т.п.
    «Емайл» — плохая старая калька из 90-х, вряд ли вообще употребляется массово.
    «Электронный адрес» — длинновато, тавтология в «email address», плохо адаптируется в глагол.
    «электронная почта» — хороший вариант, но длинноват; Компромиссный.
    «Эл.почта» — сокращение немножко режет визуально; по нормам языка нужен пробел, а неразрывку мало кто будет ставить — может расползаться в две строки.
    «Эл. адрес» — см. выше и «адрес»

    P.S. Предыстория вопроса в Slack:
    https://ruwp.slack.com/?redir=%2Farchives%2FC21QJU17D%2Fp1577772947339800
    Краткая выжимка:
    В декабре в оригинальных строках email стали везде писать без дефиса.
    Sergey заменил во всех переводах «e-mail» на «email» (большой шаг вперёд).
    Я предложил пойти ещё дальше и начать его переводить, мнения разделились.

    Не нужно учить плохому! Все изменения в оригинальных файлах темы живут только до первого обновления.

    Кстати, да. Подразумевался functions.php дочерней темы, а её в данном случае нет. В идеале хорошо было бы вместе с замечанием сразу набросать решение, но в любом случае спасибо.

    Окей, тогда сделаем ещё проще. Те же скрывающие стили можно применить через меню «Внешний вид» > «Настроить» > «Дополнительные стили»:

    .slb_details {
        display: none;
    }
    .slb_nav {
        display:none;
    }

    Эффект тот же. И хотя я не сторонник стилизации через админ-панель, в данном случае так всем будет проще и удобнее, наверное.

    Пожалуйста. Успехов!

    Добрый день!

    Ваша галерея выводится с помощью плагина Simple Lightbox. У него есть собственные темы оформления (по умолчанию «Светлая» и «Тёмная», у вас выбрана светлая). Чтобы изменить оформление более-менее правильно, понадобится предпринять пару небольших шагов, сделав что-то вроде надстройки над стандартным оформлением. Для этого нужно:

    1. Создать в папке /wp-content/ файл slb-fix.css, с примерно таким содержимым:

    .slb_details {
        display: none;
    }
    .slb_nav {
        display:none;
    }

    2. В functions.php добавить примерно следующее:

    function slb_theme_travel_atlas_init($themes) {
        $themes->add('travelAtlas', array(
            'name' => 'Travel Atlas',
            'parent' => 'slb_default',
            'styles' => array (
                array ( 'fix', content_url( '/slb_fix.css' ) ),
            ),
        ));
    }
    add_action('slb_themes_init', 'slb_theme_travel_atlas_init');
    

    3. В админ-панели перейти в раздел «Внешний вид» > «Лайтбокс». Найти там поле «Тема». Если предыдущий шаг сделан правильно, там в выпадающем списке появится пункт «Travel Atlas». Выбрать его, нажать внизу кнопку сохранить настройки.

    В результате этих действий из нового файлика подгрузится пара дополнительных CSS-правил, которые просто добавляются к стандартной теме и скрывают блок с «деталями» слайда.

    Это решение из разряда «на скорую руку», набросанное под ваш случай (хотя и рабочее — бегло проверил на локальной установке WP).

    По-хорошему, нужно сделать всё это чуть более основательно, создав полноценный отдельный шаблон для плагина Simple Lightbox, в соответствии с его документацией (англ.), удалив все ненужные вам блоки из разметки, дописав любые необходимые стили, положив всё в отдельную папку и т.д.

    Успехов!

    • Ответ изменён 4 года, 9 месяцев назад пользователем Norske.

    тема называется «BAM»

    Хорошо, установил.
    Думаю, самый простой способ для вас поступить следующим образом.
    1. Открыть в администраторской панели меню «Внешний вид» > «Темы» > «Настроить».
    2. Внизу выбрать пункт «Дополнительные стили»
    3. В текстовое поле ввесит следующее:

    /* Переопределение цвета главного заголовка */
    .site-title a {
        color: #000 !important;
    }
    
    /* Переопределение цвета ссылок статей */
    .entry-title a {
        color: #000  !important;
    }

    Цвет #000 — чёрный, его можно заменить на любой другой.
    Ключевое слово !important «насильно» заставляет новый стиль перекрыть остальные. Без этого слова исходный цвет «перевесит» ваши новые стили и никаких изменений не будет. Учитывайте, что это решение несколько топорное, т.к. вы лишаете смысла настройки самой темы.

    Более правильным было бы создать дочернюю тему и переопределить в ней стили. Как справедливо заметил выше @tuxfighter, править файлы самой темы неправильно. Но рецепт дочерней темы я тут не привожу, т.к. это:
    1. Несколько сложнее в реализации.
    2. Мне показалось, что сама тема Bam местами подглючивает и смена некоторых цветов через кастомайзер не отрабатывает как надо. Соответственно, дочерняя тоже может вести себя своеобразно. (Хотя, возможно, я просто не разобрался в спешке — к сожалению, нет возможности вникать в её опции как следуюет).

    Добрый день!

    Уточните, с какой именно темой оформления вы работаете?

    Добрый день!

    Любопытно. Логических объяснений навскидку нет. Есть шальное наблюдение из области нумерологии. ID категории «Тихий океан» = 91 и количество постов в его «сумасшедшей» подрубрике тоже 91. Очень хочется спросить, нет ли там мистических совпадений на этой почве 🙂

    А вообще, я бы начал тестить с depth=-1 и depth=0 в комбинации с hierarchical 1 и 0. Чтобы посмотреть, что там происходит. Крайне желательно проверять непосредственно результат функции (дампом), а не готовый вывод на сайте.

    Ещё хорошо бы взглянуть на вывод, где <select>…</select> формируется. Или вы wp_dropdown_categories() используете?

    Если не прояснилось, но проблема именно в результате функции, можно попробовать вызывать get_terms() c теми же параметрами (плюс &taxonomy=category) и сравнить полученный список.

    Потом искать какие-нибудь плагины или куски кода, которые могут переопределить add_filter(‘get_terms’, …). Ну и всякие редкие случайности: приведение типов, случайное переопределение переменной $list_cat чем-то другим, проблемная условная логика при выводе и т.п.

    и никто не знает как решить проблему

    Добрый день!

    Тут основная проблема, скорее всего, в том, что для устранения настолько мелких частностей нужно погрузиться в ваш сайт довольно глубоко. И сильно заморочиться. FeedValidator, на который вы ссылаетесь, в основном показывает ошибки и замечания, которые:

    • либо связаны с самим валидатором (например, он пишет, что не понимает неймспейс Яндекса, потому что такого пока нет в его базе);
    • либо относятся к вашему контенту (например, ругается на то, что вы в теле поста отдаёте <iframe> — скорее всего, там какие-нибудь ролики с ютюба)
    • либо связаны с генерацией шаблона, но в таких местах, что желательно смотреть непосредственно сайт.
    • То есть «волшебной таблетки» тут, скорее всего, не будет — нужно садиться и педантично разбирать каждую ошибку по отдельности до победы. По опыту, на такие вещи в среднем уходит от 20 минут до пары часов на каждый пункт. Плюс ситуация осложняется тем, что разбираться нужно «наощупь», т.к. и метод генерации фида и контент на вашей стороне.

      Часть «ошибок» — просто предупреждения, которые на практическую эффективность фида вряд ли вообще как-то повлияют.

      «Ошибка» «url must be a full URL», например, вообще результат дедовских стандартов RSS, толком не связанный с вашим сайтом. Грубо говоря, спецификация RSS считает, что агрегаторы не должны передавать данные по защищенному соединению, поэтому ругает все ссылки, которые начинаются с httpS. Это имело смысл 10 лет назад, когда защищенных сайтов были единицы. Сейчас это просто пережиток.

      Словом, с этими мелочами вам придётся довольно много возиться, они специфичны. Готового кусочка кода тут никто не напишет — надо вникать, читать, гуглить, смотреть код, тестить. Если для вас это прямо критически важно, то есть смысл просто нанять недорогого фрилансера, который за 1-2 дня доведёт ваш фид до нужного вам состояния (более-менее).

      Требовать какой-то реакции саппорта в данном случае не стоит, на мой взгляд. По сути это не столько вопрос, сколько рабочая задача на N часов. Это не совсем одно и то же.

    • Ответ изменён 4 года, 9 месяцев назад пользователем Norske. Причина: разметка

    Добрый день!

    Не совсем понятно, весь ли это код или только фрагмент. В общем случае вам нужно делать там несколько проверок, а не одну.

    Во-первых, Отелем может быть сама текущая рубрика. Во-вторых, рубрика может быть дочерней и тогда Отелем может быть родитель текущей рубрики ($term->parent). Нужно проверять оба этих условия. И то же самое с домами.

    То есть в итоге у вас по идее получится что-то наподобие этого:

    // Задаём ID родительских «рубрик» Отель и Дом (замените значения)
    $hotels_root_id = -1;
    $houses_root_id = -1;
    
    // Получаем ID переведённых родительских «рубрик» из PolyLang
    $hotels_id = pll_get_term( $hotels_root_id );
    $houses_id = pll_get_term( $houses_root_id );
    
    // Получаем текущую «рубрику» и её ID
    $taxonomy = get_query_var( 'taxonomy' );
    $the_id = $wp_query->get_queried_object_id();
    $the_term = get_term( $the_id, $taxonomy );
    
    // Проверяем: 
    // а) является ли текущая рубрика Отелем
    // б) является ли родитель текущей рубрики Отелем
    if ( $the_term->term_id === $hotels_id || 
         $the_term->parent  === $hotels_id ) {
    
        // Загружаем шаблон для отелей
        get_template_part('/taxonomy-product_cat-hotel');
    
    // ...иначе проверяем по аналогии: 
    // а) является ли текущая рубрика Домом
    // б) является ли родитель текущей рубрики Домом
    } elseif ( $the_term->term_id === $houses_id || 
         $the_term->parent === $houses_id ) {
    
        // Загружаем шаблон для домов
        get_template_part('/taxonomy-product_cat-house');
    
    // ...иначе, выводим что-то ещё  
    } else {
    
       // ...
    }

    Это пример на коленке, могут быть опечатки. Плюс нужно, конечно, подставить везде правильные значения ID, пути к шаблонам и т.д

    Можно с вами сконтактироваться в телеге, например?

    Давайте ограничимся форумом. Я стараюсь по возможности уделять пару часов в неделю поддержке ClassicPress и WordPress, но вне этих часов вряд ли смогу чем-то помочь.

    Что принято выбирать для гуглновостей в частности?

    С этим лучше обратиться к документации Гугла, т.к. вопрос выходит за пределы темы WordPress. Могу предположить, что Гугл захочет макимум контента: полноразмерные картинки и полные тексты. Но я практически не работаю с фидами, поэтому могу ошибаться.

    По стилям. У вас в качестве параметра в той же функции прописано array('style' => 'float:left; margin:0 15px 15px 0;' ). То есть картинка выравнена по левому краю и обтекается текстом, при этом имея отступы по 15px справа и снизу. Возможно, при изменении формата картинки вы захотите эти значения подогнать. Например, сделать картинку на всю ширину без обтекания. Тогда вместо float:left; margin:0 15px 15px 0; там будет нечто вроде width: auto; margin-bottom: 15px;. Но это уже частности, экспериментируйте.

    как в rss сделать так, чтоб миниатюра не обрезалась?

    Уточните, пожалуйста, что значит «не обрезалась»? Не уверен, что я правильно понял вопрос.

    Насколько я вижу, у вас сами картинки (файлы) миниатюр идут размером 150 на 150 пикселей. Видимо, в меню «Настройки» -> «Медиафайлы» стоит галочка «Обрезать миниатюру точно по размеру». Если вы хотите, чтобы миниатюры (файлы) сохраняли пропорции оригинала, эту галку нужно снять, а затем пройтись по картинкам одним из плагинов, которые регенерируют минатюры (например).

    Если же вы именно в фиде хотите просто выводить картинки большего размера, то замените параметр ‘thumbnail’ в функции get_the_post_thumbnail() на любой другой стандартный размер: ‘medium’, ‘large’ или ‘full’ и отрегулируйте CSS стили в третьем параметре как вам нужно.

    @rupor, ответ временно попал под антиспам из-за ссылки, но его благополучно восстановили. Извините за неудобство.

    Добрый день!

    Если я правильно понял, вы хотите создать произвольный адрес и подгрузить по этому адресу произвольный шаблон. Это возможно, но нужно делать «с другого конца». Не движок подключать к файлу, а файл к движку.

    Сначала нужно зарегистрировать новый адрес URL с помощью функции add_rewrite_endpoint(), чтобы движок его обрабатывал. Вот документация. Для регистрации адреса в файле functions.php (а лучше в отдельном плагине) пишем нечто наподобие этого:

    function add_mypage_endpoint(){
    	add_rewrite_endpoint( 'mypage', EP_ROOT );
    }
    add_action( 'init', 'add_mypage_endpoint' );

    Здесь мы задаём новый ярлык (/mypage/) который будет добавляться к корню сайта (EP_ROOT). Получится site.ru/mypage/. После этого нужно обязательно обновить ЧПУ сайта, чтобы ссылка начала открываться. Обычно это делается просто в админке, но при ваших условиях придётся делать программно, вызывая функцию flush_rewrite_rules.

    В результате движок сможет обрабатывать этот новый адрес, не вываливаясь в ошибку 404. По умолчанию, эта новая ссылка открывает не что иное, как главную страницу. Поэтому открыв её, вы увидите шаблон index.php или front-page.php. Чтобы подтянуть другой шаблон, нужно в начале шаблона главной страницы сделать проверку, что-то типа:

    // Проверяем, содержит ли запрашиваемый адрес «добавочную» часть '/mypage/'
    if( isset($wp_query->query['mypage']) && $wp_query->is_main_query() ) {
    
        // Если содержит, ищем в папке с темой шаблон 'mypage.php' и подгружаем его
        if ( $mypage_custom_template = locate_template('mypage.php') ) {
            load_template( $mypage_custom_template );
        }
    } else {
        // Выводим обычный шаблон главной страницы.
    }

    Таким образом при открытии адреса /mypage/ будет подгружаться шаблон mypage.php. При желании можно сразу вывести стандартный шаблон страницы или любой другой.

    Важно понимать, что все запросы к сайту должны обрабатываться движком. Прямое обращение к php-файлам внутри папок не должно происходить вообще.

    Успехов!

    Исходный файл относится к файлам ядра WordPress. Модифицировать такие файлы не имеет смысла, потому что они перезаписываются при каждом обновлении.

    Кроме того, наличие в ядре изменённых файлов может создать много разных проблем. Некоторые плагины безопасности посчитают сайт взломанным. Могут возникать файловые конфликты при обновлениях и установке плагинов, неправильно определяться версия движка и др.

    Никогда не изменяйте файлы ядра напрямую. Все модификации вносятся посредством хуков (событий и фильтров), которые прописываются в файлах тем или плагинов. Только так.

    • Ответ изменён 4 года, 9 месяцев назад пользователем Norske.
Просмотр 15 ответов — с 1 по 15 (всего 36)