Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 88
Я один как дурак сидел ждал, пока прогрузится «progressive 78.3K»? =\\
Очень плохой перевод.
Будьте конкретнее, пожалуйста. Предложите, где перевести лучше — я исправлю.
Тяжелый стиль изложения у Вас. Прочитав первый абзац, сразу становится понятно, что это именно перевод.
Если давать какие-то конкретные советы, то придется разбирать почти каждое предложение.
Лично я, переводя тексты, даю тексту «настояться» пару часов, а потом перечитываю и редактирую. Как-то так.
Если давать какие-то конкретные советы, то придется разбирать почти каждое предложение.
Лично я, переводя тексты, даю тексту «настояться» пару часов, а потом перечитываю и редактирую. Как-то так.
От себя добавлю: нужно очень аккуратно обращаться с идиомами, особенно если они в техническом тексте используются. Подстрочный перевод ни в коем случае нельзя делать.
Что именно вы имеете ввиду в этом тексте?
Помимо знания значения иностранных слов, для перевода важно еще и хорошо знать свой родной язык. Ваш текст выглядит как будто его писал плохо владеющий русским языком человек. Разбирать можно каждое предложение, как уже было сказано. Про идиомы: "… чаще всего являются бутылочным горлом" — это калька с английского bottleneck. В русской речи используется фраза «узкое место/слабое место/слабое звено» в зависимости от контекста. Бутылочное горлышко — это порождение машинного перевода.
Так я сначала и написал. Но «большие изображение — узкое место» как-то не звучало, да и ru.wikipedia.org/wiki/%D0%91%D1%83%D1%82%D1%8B%D0%BB%D0%BE%D1%87%D0%BD%D0%BE%D0%B5_%D0%B3%D0%BE%D1%80%D0%BB%D0%BE вот, собственно. Калька, но даже со своей собственной статьей в википедии.
Статьи в википедии пишут обычные люди. В том числе и безграмотные. IT жаргон пестрит примерами бездумного копирования. «Бутылочное горло» пока не настолько распространенный и общеупотребительный термин, чтобы поощрять его использование. Идиомы не переводятся «в лоб». И их значение не подставляется строго по месту старого. Вся сложность в переводе идиом, это как раз частая необходимость полной перестройки фразы.
По поводу статей, жаргона и идиом все справедливо и понятно. С чем я не согласен, так это с тем, что термин недостаточно распространен. Это субъективно. Мне он показался подходящим. Во всяком случае, он устранял неестественное впечатление от того, что большой размер является узким местом.
Предложите вариант лучше, я исправлю.
Ну и да, дисклеймер: я не профессиональный переводчик. На отличное качество перевода и не претендую. Старался перевести так, чтобы смысл был понятен.
Предложите вариант лучше, я исправлю.
Ну и да, дисклеймер: я не профессиональный переводчик. На отличное качество перевода и не претендую. Старался перевести так, чтобы смысл был понятен.
Вот так, к примеру: "… их передача является узким местом". Ваш вариант звучит искусственно и тоже не имеет смысла. Если и использовать кальку с английского — то не сами изображения являются «бутылочным горлом», а задача их пересылки клиенту.
Добавлю про свиней: надо очень хорошо было над этим подумать. В американском английском слово pig еще является грубоватым названием обжоры. И это значение подходит по тексту. В русском языке свиньей, в первую очередь, называют неряху.
Добавлю про свиней: надо очень хорошо было над этим подумать. В американском английском слово pig еще является грубоватым названием обжоры. И это значение подходит по тексту. В русском языке свиньей, в первую очередь, называют неряху.
Вполне себе общеупотребительный термин, особенно при описывании ситуации на дорогах и причин пробок. Но я согласен, что «узкое место» лучше, ибо короче и проще произносится.
Не слушайте дураков. Оставьте «best practice», верните «bottleneck», и другие англицизмы, давно и прочно вошедшие в жаргон айтишников.
Например, по-русски говорят «узкое место», а не «бутылочное горло».
Поглядел. Предлагаете сменить «best practice» на «лучшая практика»? По-моему общеупотребим и понятен английский вариант, а «лучшая практика» ну очень уж редко употребляется.
Это перевод, но на мой комментарий это замечание не отвечает. Как мне кажется, понятнее текущий вариант. Потому что на русском варианте в данном случае все равно взгляд споткнется. По крайней мере у меня при виде «лучшая практика» было бы что-то вроде «а, так это best practice имеется ввиду». Английский термин этот общеупотребим в ИТ. Как аналогии, на ум сразу приходят Generic'и, Assert'ы, Commit'ы, стартапы и прочее.
Я не согласен. По аналогии, вы хотите сказать, что в приведенных случаях понятнее было бы использовать Обобщения, Утверждения, Фиксации и Запуски? По-моему как раз в таком случае большинство не поймет о чем речь. Знание определенных терминов английского языка — само собой в ИТ, а это как раз ИТ ресурс. Поэтому я и посчитал, что оставить best practice — понятнее.
Все аналоги, которые я привел, точно так же «прекрасно переводимы», только в переведенном варианте объективно менее понятны большинству. Дальше уже субъективно, но по поводу жаргонизма, мне лично приятнее читать в русском тексте commit, assert и т.д., нежели коммит, ассерт. По-моему, в этом вопросе нет единственно правильного ответа. Мне определенно и осознанно больше нравится текущий вариант. И не кажется калькой.
Если хотите, уберите из предыдущего коммента слово «объективно». Исследование я не проводил, но то, что описал, верно для меня и всех моих знакомых в ИТ, с которыми я хоть сколько-нибудь общался употребляя приведенными в пример терминами. Это все звучит понятно. Куда понятнее, чем фиксации и запуски.
По поводу «задвига», разве есть что-то плохое в приоритезировании понятности?
По поводу «задвига», разве есть что-то плохое в приоритезировании понятности?
Так выше же, в следующем комменте, я на это и ответил. Ну не повторять же сейчас весь диалог заново.
По-моему диалог становится бессмысленным. Я же писал по поводу незнания языка уже:
Если вы считаете, что в том примере использование «commit» и «assert» вместо «фиксация» и «утверждение» — мои душевные терзания, а не объективная понятность, то конструктивного диалога дальше точно никакого не выйдет.
Знание определенных терминов английского языка — само собой в ИТ, а это как раз ИТ ресурс.
Если вы считаете, что в том примере использование «commit» и «assert» вместо «фиксация» и «утверждение» — мои душевные терзания, а не объективная понятность, то конструктивного диалога дальше точно никакого не выйдет.
Я не перевожу тему, я привел вам аналогии, в которых абсолютно так же нет проблем с переводом. Именно такие аналогии привели меня к решению оставить «best practice» как есть. Вы не согласны с этим вариантом и аналогии вас не убеждают, это я понял. Но ответных доводов, убеждающих меня в обратном вы тоже не привели. По-моему дальше это обсуждать бессмысленно.
Не понимаю, чем «best practice» не подходит под определение термина. Это же термин, ничуть не меньше чем приведенные аналоги.
Поддерживаю Falco, мне например тоже понятнее «best practice». В it-статьях на французском, немецком языках, этот термин тоже обычно не переводят.
«Понятнее английский быть не может, ибо большинство английского не знает.»
А вы откуда знаете сколько языков знает большинство хабрапользователей?
И да, я не представляю человека который работает в данной области и не знает базового английского.
«Понятнее английский быть не может, ибо большинство английского не знает.»
А вы откуда знаете сколько языков знает большинство хабрапользователей?
И да, я не представляю человека который работает в данной области и не знает базового английского.
«То есть вы бы ни в какую не поняли «лучшая практика»?»
У словосочетания best practice есть своя специфика, которая теряется при переводе. Я бы конечно понял, но в пересчете на мозговые «такты» — для соединения «лучшая практика» с его английским аналогом и спецификой которую оно в себе несет — их бы потребовалось больше.
«Про знание иностранных языков есть статистика. Большинство не знает ни одного. Кто-то учил в школе не английский, а немецкий.»
Я не про всю страну, а про хабр. Думаю здесь совсем другая картина.
«Это неуважение к читателю.»
Всем не угодишь. К тому-же надо делать скидку на айтишный жаргон, можно конечно переводить используя исконно русские слова и выражения, но думаю Мицгол не потерпит конкуренции :)
У словосочетания best practice есть своя специфика, которая теряется при переводе. Я бы конечно понял, но в пересчете на мозговые «такты» — для соединения «лучшая практика» с его английским аналогом и спецификой которую оно в себе несет — их бы потребовалось больше.
«Про знание иностранных языков есть статистика. Большинство не знает ни одного. Кто-то учил в школе не английский, а немецкий.»
Я не про всю страну, а про хабр. Думаю здесь совсем другая картина.
«Это неуважение к читателю.»
Всем не угодишь. К тому-же надо делать скидку на айтишный жаргон, можно конечно переводить используя исконно русские слова и выражения, но думаю Мицгол не потерпит конкуренции :)
Подобной славянофилии место исключительно в провинциальных вузах, где преподы материал адаптируют из англоязычных источников.
Может еще монитор называть «смотрило», а то, глядишь, не поймут деревенские?
Может еще монитор называть «смотрило», а то, глядишь, не поймут деревенские?
Не надо передергивать. Если вы не знаете как переводиться best practice (переведет школьник начальных классов), то у вас славянофилия в крайней форме. Вполне допустимо к месту использовать понятные большинству иноязычные словосочетания для стилизации текста. Sapienti sat.
Боже мой, какая феерическая чушь: автор вот не справился с переводом. У него «славянофилия в крайней форме»?
Мы тут вас обсуждаем, а не автора статьи. Потрудитесь вникнуть в суть, прежде чем писать.
Может быть, но только не в переводе.
Вы тут не устанавливаете правила.
У вас кроме латинских фраз доводов нет? Не надейтесь, на умного вы не смахиваете.
Поясняю для альтернативно одаренных — это был пример употребления иноязычной фразы в контексте.
На этом разговор закончен. Метать бисер перед свиньями не собираюсь.
Специфика в том что данный термин повсеместно используется в англо-говорящих интернетах для обозначения рекомендации для работы с чем-либо. Также он крайне часто используется в неанглийских интернетах — просто так повелось, большая часть разработчиков к нему привыкла. Поэтому обычно разработчику понятнее английское словосочетание, чем аналог из родного языка.
«На хабре процентное соотношение может немного отличается, но не принципиально.»
Повторюсь, хабр это it ресурс, что это за «немного»? И процентное соотношение айтишников тоже немного отличается от среднего по стране? Вы в курсе что без знания английского в it по большему счету искать нечего?
«На хабре процентное соотношение может немного отличается, но не принципиально.»
Повторюсь, хабр это it ресурс, что это за «немного»? И процентное соотношение айтишников тоже немного отличается от среднего по стране? Вы в курсе что без знания английского в it по большему счету искать нечего?
Верно, если переводить на русский получится что-то вроде «наилучший способ, призванный стать единственно верным». Коряво, может можно лучше, но намного короче и лаконичнее вряд ли можно перевести. Так что лучше «best practice».
Я не стал бы заменять «best practice» на «лучшая практика» хотя бы потомý, что «лучшая» может означать и «better» (а не только «best») в зависимости от предубеждённости читателя.
Однако я мог бы, наверное, заменить «best practice» на «наилучшая практика» в этом предложении, чего и Вам советую.
Однако я мог бы, наверное, заменить «best practice» на «наилучшая практика» в этом предложении, чего и Вам советую.
Вы переводите слова. А нужно переводить смысл.
Где плохо? Везде. Я видел много переводов и сам занимаюсь переводами и вижу. Первый признак плохого перевода — слово «это» в начале строки, как следствие перевода предложений, начинающихся с it.
Где плохо? Везде. Я видел много переводов и сам занимаюсь переводами и вижу. Первый признак плохого перевода — слово «это» в начале строки, как следствие перевода предложений, начинающихся с it.
2013-й год, а мы все еще сидим на древнем JPEG-е.
Печально.
Печально.
Для Web'а — это нормально, а вот для фотографии нет. Связано это, скорее всего с устройствами отображения.
Угу. Хочу Jpeg2000. Но прошло 12 лет, а воз и ныне там…
WebP, JPEG XR
Нынче в моде WebP. Jpeg2000 не получил шанса из-за не полностью свободной лицензии. Вот она, жадность.
h265 still images (HEVC) обещает быть на 43-61% эффективнее JPEG, и на десятки процентов эффективнее всяких Jpeg200, XR, WebP. Финальная спецификация всего стандарта h265 будет принята уже в феврале.
en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Main_Still_Picture
Я был бы раз увидеть поддержку именно этого формата в Chrome и других браузерах.
Причём это Main Profile, через несколько лет значит должен быть ещё более лучший High Profile.
en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Main_Still_Picture
Я был бы раз увидеть поддержку именно этого формата в Chrome и других браузерах.
Причём это Main Profile, через несколько лет значит должен быть ещё более лучший High Profile.
Я так понимаю, что речь о сжатии с потерями, раз сравнивается с тем же JPEG. В таком случае интересно, какие настройки сжатия J2K использовали при тестировании (по сути выбор фильтра DWT и были ли применены доп действия, типа отсечения zero-trees или как оно там называется). Это я к тому, что DWT с потерями со всем наворотами позволяет сжимать очень и ОЧЕНЬ сильно, и как-то даже не верится что разница в десятки процентов.
Существует проект JPGCrush (для *nix), который преобразует изображения из последовательного jpeg в прогрессивный, причем с высокой степенью сжатия, при этом он не изменяет качество изображения. Для работы необходим JPEGTran.
Я его реализовал в своем проекте Image Catalyst (для Windows), также он есть в проекте ImageOptim (для OS X).
Такой вопрос, а нет ли готовой версии PageSpeowed Optimization Libraries для windows?
Я его реализовал в своем проекте Image Catalyst (для Windows), также он есть в проекте ImageOptim (для OS X).
Такой вопрос, а нет ли готовой версии PageSpeowed Optimization Libraries для windows?
Да Image Catalyst, вещь хорошая. Я все прогоняю, через нее.
Кстати, не всегда лучше использовать прогрессивные. Самое не целевое использование — это конвертация подобного изображения в base64. Возможно, есть и другие случаи, если кто-то знает, то буду признателен, если озвучите.
Кстати, не всегда лучше использовать прогрессивные. Самое не целевое использование — это конвертация подобного изображения в base64. Возможно, есть и другие случаи, если кто-то знает, то буду признателен, если озвучите.
Фотографии документов или чего-то подобного тоже не имеют плюсов в прогрессивности, так как прогрессивность всё равно не даст прочитать что-либо до загрузки достаточной чёткости, в то время как в линейном варианте их можно уже читать по мере загрузки. Это лишь один из примеров, который пришёл в голову первым.
Я не понял, при чем здесь SPDY.
Ссылка рассказывает также о mod_pagespeed
Ссылка рассказывает также о mod_pagespeed
Opera (v 11.60) / мгновенно после загрузки файла (медленно) / мгновенно после загрузки файла (медленно)
Ложь. В Опере при отображении в теге IMG картинка грузится прогрессивно.
Можете проверить сами: madeira.cc.hokudai.ac.jp/RD/jovi/info96/html/progressive.html (картинка должна грузиться медленно)
Проверил. Действительно, загружается прогрессивно. Значит автор оригинального материала ошиблась.
Поправил пост, спасибо.
Поправил пост, спасибо.
Работает в 12.12/Linux. Может недавно появилось, статья то явно старая судя по представленному соотношению браузеров.
Мне тут мысль пришла после прочтения заголовка (надеялся, что об этом пост).
Мысль следующая: известно, что изображения, уменьшенные через CSS заставляют тупить браузер (через атрибуты, судя по всему, тоже, но их никто не использует сегодня). Часто на сайте используется ряд миниатюр одного изображения, включая само изображение, например:
1. Оригинальное загруженное, скажем, 1500 на 1500 пикс, открывающееся по ссылке
2. Сжатое изображение, используемое на странице (фото товара, например) — 700 на 700
3. Средняя миниатюра (скажем, выводится в списке товаров определенной категории) — 400 на 400
4. Малая миниатюра (допустим, выводится в общем списке товаров и в «похожих» товарах) — 150 на 150
Допустим, при генерации картинки, до загрузки, редактор сохранил оригинальную картинку с четырьмя слоями, примерно соответствующим размерам, описанным выше.
Было бы очень неплохо, вместо серверной конвертации картинок в 4 формата, просто сообщать браузеру: «Дай картинку до третьего слоя» для вывода на странице товара или «дай только первый слой». При этом, если картинка до указанного слоя отсутствует в кеше, браузер запрашивает её, но прерывает загрузку когда будет получен нужный слой.
В итоге получаем экономию трафика (грузить надо одну картинку, а не четыре) и экономию серверных ресурсов (не надо ничего уменьшать, по той же причине)
В идеале, конечно, было бы круто указывать редактору, какими должны быть слои.
Мысль следующая: известно, что изображения, уменьшенные через CSS заставляют тупить браузер (через атрибуты, судя по всему, тоже, но их никто не использует сегодня). Часто на сайте используется ряд миниатюр одного изображения, включая само изображение, например:
1. Оригинальное загруженное, скажем, 1500 на 1500 пикс, открывающееся по ссылке
2. Сжатое изображение, используемое на странице (фото товара, например) — 700 на 700
3. Средняя миниатюра (скажем, выводится в списке товаров определенной категории) — 400 на 400
4. Малая миниатюра (допустим, выводится в общем списке товаров и в «похожих» товарах) — 150 на 150
Допустим, при генерации картинки, до загрузки, редактор сохранил оригинальную картинку с четырьмя слоями, примерно соответствующим размерам, описанным выше.
Было бы очень неплохо, вместо серверной конвертации картинок в 4 формата, просто сообщать браузеру: «Дай картинку до третьего слоя» для вывода на странице товара или «дай только первый слой». При этом, если картинка до указанного слоя отсутствует в кеше, браузер запрашивает её, но прерывает загрузку когда будет получен нужный слой.
В итоге получаем экономию трафика (грузить надо одну картинку, а не четыре) и экономию серверных ресурсов (не надо ничего уменьшать, по той же причине)
В идеале, конечно, было бы круто указывать редактору, какими должны быть слои.
sprites?
Большинство jpg, png и других форматов имеют превью, мини-картинка в картинке, генерируемая графическим редактором. Некотрые форматы, например icns (иконки в маке) состоят из набора картинок разных размеров для соответствующего отображение в разных размерах, и могут весьма отличаться друг от друга.
Чтобы это использовать со стороны клиента, браузеры должны сами вместо ресайза огромной картики считывать маленькую, но на это никто не пойдёт (стандарты, ожидания, прочее). Можно со стороны сервера уменьшить нагрузку, но это тоже такие крохи… Сервер мощный, он сожрёт ) В итоге всё так, как оно есть.
Чтобы это использовать со стороны клиента, браузеры должны сами вместо ресайза огромной картики считывать маленькую, но на это никто не пойдёт (стандарты, ожидания, прочее). Можно со стороны сервера уменьшить нагрузку, но это тоже такие крохи… Сервер мощный, он сожрёт ) В итоге всё так, как оно есть.
Название режет глаз. По-моему, гораздо лучше было бы: «Прогрессивный JPEG: лучшее решение»
Благодарю за перевод этого текста, потому что я убеждён, что его кто-нибудь непременно должен был перевести и выложить на Хабрахабре (я даже сам собирался сделать это, если повезёт, завтра; так что Вы меня разгрузили).
Текст очень полезен как практическое руководство, убеждающее веборазработчиков наконец взяться за ум и начать выкладывать JPEG в прогрессивном виде (для Chrome, для Firefox; как здесь выяснили — и для Opera; а если не в Windows XP — то и для IE). Время пришло.
Сразу скажу, что текст этот начинает постепенно воздействовать и на браузеростроителей.Так, например, создатели Mozilla Firefox начали обдумывать возможность перехода на прогрессивное отображение фоновых иллюстраций, по примеру Chrome.
Текст очень полезен как практическое руководство, убеждающее веборазработчиков наконец взяться за ум и начать выкладывать JPEG в прогрессивном виде (для Chrome, для Firefox; как здесь выяснили — и для Opera; а если не в Windows XP — то и для IE). Время пришло.
Сразу скажу, что текст этот начинает постепенно воздействовать и на браузеростроителей.
«Прогрессивный jpeg обычно на несколько килобайт меньше, чем его же последовательная версия» — странно, но у меня в 90% случаев наоборот — прогрессивный на 5-15% больше. Редактор Corel Paint Shop Pro, хотя вряд ли в нем причина.
Загружаясь, изображения рвут страницу, расталкивая другие элементы вокруг и вызывая неуклюжую перерисовку (прим. перев.: от этого, конечно, можно избавиться определенной версткой
А для чего тогда параметры height и width у тэга img?
И следующие слова:
как раз относятся к явному заданию height и width у img или его контейнера.
но тогда нужно хардкодить или ограничивать размеры картинок
как раз относятся к явному заданию height и width у img или его контейнера.
Я решил. что под словом хардкодить подразумевается жесткое задание размеров каких-нибудь div-ов-контэйнеров. Явное заданию height и width вроде было обязательно по стандарту (хотя, вероятно я путаю с alt), да и хардкодингом я бы это не назвал: вместо задания вручную на этапе вёрстки можно подставлять эти параметры в процессе генерации страницы на сервере. При этом и генерировать-то придётся не так уж много: для подавляющего большинства картинок (как элементов вёрстки так и контэнта) размеры известны уже на этапе вёрстки.
Насколько я понимаю, спецификация не требует обязательного их задания. А установка их на сервере, или на клиенте, даже для статического контента в моем представлении явлется хардкодингом. Если вам придется поменять какую-нибудь картинку, то кроме изменения самого файла нужно будет еще и менять эти захардкоженные значения. А для динамического контента (фото, загружаемые пользователями / персоналом / контент-менеджерами) это и вообще проблема. Нужно будет при аплоаде и сохранении сохранять куда-то отдельно размеры файлов, чтобы потом при формировании страниц их указывать.
В общем, это сделать можно, но это отдельная тема с отдельным геморроем, поэтому я и написал примечание в посте. Намного проще представляется решать эту проблему используя прогрессивный jpeg.
В общем, это сделать можно, но это отдельная тема с отдельным геморроем, поэтому я и написал примечание в посте. Намного проще представляется решать эту проблему используя прогрессивный jpeg.
В PHP юзаю phpThumb для созданий превью — можно ли там задать прогрессивный тип изображения? Используется Image Magic или GD 2
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Прогрессивный JPEG: новый best practice